Az első benyomásokKérdezzen egy Java Newbies Archive - NEWSboard IBMi fórumot

Az első Java-munkám (nem számítva a HelloWord verziókat) 90% -ban elkészült.

Ez az 101. változat az SCS spool fájltól a PDF-ig. Az én változatomnál álljon meg a vállalati írószerrel a háttérben vagy a * STD és A4QUER orsók háttércsíkjaival.

A PDF létrehozásához az itext osztálygyűjteményt, a köztes DB fájl kiolvasásához a JT400.jar osztálygyűjteményt használom.

A PC fejlesztése (DEV: Gel) nagyrészt problémamentesen zajlott. Az AS/400 rajtja is azonnal működött.

A tényleges futásidővel is elégedett vagyok - de az "előfordítás" lényegesen tovább tart, mint a tényleges átalakítás. Jelentősen csökkenteni tudtam ezt az átfutási időt a CRTJVAPGM segítségével.

Ezen a fórumon gyakran nem tanácsolták az AS/400 CRTJVAPGM és RUNJVA parancsokat, mely hátrányaim vannak?

Ezenkívül az AS/400-on a JT400NTVE.JAR (natív meghajtó) programmal kell dolgozni. De akkor regisztrálnom kell egy másik JDBC illesztőprogramot. De akkor a programom már nem fut a PC-n. Szükség van-e konfigurációs fájlra, vagy van-e jobb megoldás?

Továbbá a 3GL és a Java keveréke nem ajánlott itt, a fórumban. A gyenge teljesítményen kívül vannak-e egyéb hátrányaim? Mivel a kimenet létrehozása számomra már "hallgatási munkákban" van, korlátozni kell a hátrányokat.

Apró részletek: ha a köztes DB fájl (a spool adatokkal) rendelkezik a CCSID 273-mal, akkor az adatokat tiszta ASCII-ként tudom kihozni a DB-ből.

ad CRTJVAPGM: csak akkor szükséges, ha a programot sok JVM-ben ritkán hívják meg (általában egyszer). (lásd még Mix). Értelmetlen a legtöbb alkalmazáskiszolgálóval (a felhasználói osztály betöltője miatt). Hátránya a nehezebb telepítés, különösen nagy alkalmazások cseréje esetén (állásidő). Ez nem közvetlenül káros.

ad RUNJAVA: nem rendelkezik minden paraméterrel a híváshoz. Alternatív QSH CMD (java.) Egyszerűbb és elegánsabb, teljes funkcionalitással.

hirdetés-illesztőprogram: Az illesztőprogram beállításai mindig egy tulajdonságfájlba tartoznak, hogy pontosan megakadályozzák ezt a hatást. A natív illesztőprogram önmagában nem gyorsabb, mint az Eszköztár illesztőprogram. Ez utóbbival azonban fontos, hogy CRTJVAPGM-mel kezeljék. Az AS400-on van a jt400.jar statikus fordítással és anélkül is, a megfelelőt kell használnia (ellenőrizheti a DSPJVAPGM-mel).

Az első Java-munkám (nem számítva a HelloWord verziókat) 90% -ban elkészült.

Ez a 101. változat az SCS spool fájltól a PDF-ig. Az én változatomnál álljon meg a vállalati írószerrel a háttérben vagy a * STD és A4QUER orsók háttércsíkjaival.

Az itext osztálygyűjteményt a PDF létrehozásához, a JT400.jar osztálygyűjteményt a köztes DB fájl felolvasásához használom.

A PC fejlesztése (DEV: Gel) nagyrészt problémamentesen zajlott. Az AS/400 rajtja is azonnal működött.

Ezen a fórumon nem ajánlott az AS/400 parancsok, a CRTJVAPGM és a RUNJVA, mely hátrányaim vannak?

Apró részletek: ha a köztes DB fájl (a spool adatokkal) rendelkezik a CCSID 273-mal, akkor az adatokat tiszta ASCII-ként tudom kihozni a DB-ből.

Én jelenleg hasonló úton. Tapasztalataim
Java-ban nem értek el olyan messzire.
De dolgozom rajta.

De van néhány kérdésem az itext-kel kapcsolatban. Tudnánk
mert esetleg e-mailben cserélhetik az időket ?.

Nagyon köszönöm
Michael

@Dieter Bender
Köszönöm a részletes választ.

Ha egyfajta szervert értesz hallgatási munka alatt (soha véget nem érő kötegelt munka), akkor ez a helyes irány.
Így működik velünk. Ügyfélenként két munka indul, amelyek a DataQ-n keresztül várják a munkát, és egész nap futnak.

Miért kéne itt keverni? Ennek legegyszerűbb módja csak a Java!
Ha elhagynám a "keverési tényezőt", akkor most kész lennék.

Ha az SNDSPLF (saját készítésű parancsunk) JAVA részét saját kiszolgálói munkámhoz bontanám ki, ez további problémákat/munkát jelent, mivel várnom kell a PDF további feldolgozására (e-mail/ftp/fax).

Természetesen át tudnám vinni a teljes parancsot egy Java kötegelt feladatra, de 1. Keményen meg kell dolgoznom a 3GL programlogikán (a Java feldolgozás előtti és utáni hívásoknál).
2. Mennyire jól teljesítenek az RPG-hívások (nem túl vékonyak, mivel LANSA-val jöttek létre) a Java-ból?

A 2-vel az az előnyöm kellene, hogy legyen, hogy a szerverfeladatot Linux szerverre helyezhettem át. (RPG hívások?)

Bár el tudtam képzelni, hogy a csere érdekes lehet más Java-kezdők számára is.

@Alles
Tehát most ismét dicséretet mondok a táblának és főleg Dieter Bender-nek, rengeteg információmat (Java bevezető linkek, iText for PDF) kaptam a tábláról.

ez valójában példaértékű példa a keverékre! az e-mail és az ftp legalább könnyebb és megvalósíthatóbb lenne a Java-ban, mint az RPG-ben, faxon nem ismerem a kezelőfelületét.

A Java-ról érkező RPG hívások wg. az inkompatibilis futásidejű környezetek nem olyan könnyűek.
- JNI (Java native Interface) határozottan nem tanácsolom ellene, és aligha teszi valaki!
- Az eszközkészlet-hívás belsőleg aszinkron módon történik a ServerJobon keresztül, de véleményem szerint bonyolult programozni és kiütni minden platform-semlegességet
- a JDBC-n keresztül tárolt eljárás véleményem szerint a legegyszerűbb, sőt sok esetben át is hordozható; Külső tárolási eljárások könnyen (szinte) bármely programból elkészíthetők az AS400-on.

Azt hiszem, már jó úton jársz.

Ami a meglévő információkat illeti, megnyitni készülök valamit, például a GYIK-ot a Java és az AS400 számára a weboldalamon, majd felveszem ezt a részt havi frissítési kampányaimba, hogy az oldalaim érdekesek maradjanak. Aztán lassan épül fel, mert a weboldalam inkább a marketing részleg része - projektekkel, képzésekkel és tanácsokkal keresem a pénzemet.

@Dieter Bender
Köszönöm a részletes választ.

Így működik velünk. Ügyfélenként két munka indul, amelyek a DataQ-n keresztül várják a munkát, és egész nap futnak.

Ha elhagynám a "keverési tényezőt", akkor most kész lennék.

Ha az SNDSPLF (saját készítésű parancsunk) JAVA részét bontanám ki a saját kiszolgálói munkámhoz, ez további problémákat/munkát jelent, mivel várnom kell a PDF további feldolgozására (e-mail/ftp/fax).

Természetesen át tudnám vinni a teljes parancsot egy Java kötegelt feladatra, de 1. Keményen meg kell dolgoznom a 3GL programlogikán (a Java feldolgozás előtti és utáni hívásoknál).
2. Mennyire sikerülnek az RPG-hívások (nem túl vékonyak, mivel LANSA-val jöttek létre) a Java-ból?

A 2-vel az az előnyöm kellene, hogy legyen, hogy a szerverfeladatot Linux szerverre helyezhettem át. (RPG hívások?)

Bár el tudtam képzelni, hogy a csere érdekes lehet más Java-kezdők számára is.

@Alles
Tehát most megint dicséret a fórumnak és főleg Dieter Bendernek. Sok információt kaptam (linkek a Java bevezetéshez, iText for PDF) itt a tábláról.