JVAGATE Protokollierung Joblog und auch ifs

[Peet]

Hallo zusammen,
ich verwende JVAGATE im RPG Programmen seit vielen für mittlerweile 4 externe Datenbanken , funktioniert tadellos.
Ich habe im Jobprotokoll eine hohe Protokollierung von der Verarbeitung JVAGATE...
Wenn ich es richtig sehe, werden für jeden gelesen Satz Infos ausgegeben.

...Beispiel

JDBCGATE: SQLCODE: 0 SQLSTATE 00000 GPH_CACHE ActivationGroup: 19
JDBCGATE:
JDBCGATE: SQLCODE: 100 SQLSTATE 02000 GPH_CACHE ActivationGroup:
19
JDBCGATE:
JDBCGATE: CCEXIT fired????19
JDBCGATE: CCEXIT fired????19
JDBCGATE: SQLCODE: 0 SQLSTATE 00000 GPH_CACHE ActivationGroup: 19
JDBCGATE:
JDBCGATE: SQLCODE: 0 SQLSTATE 00000 GPH_CACHE ActivationGroup: 19
JDBCGATE:
JDBCGATE: SQLCODE: 0 SQLSTATE 00000 GPH_CACHE ActivationGroup: 19
JDBCGATE:
JDBCGATE: SQLCODE: 0 SQLSTATE 00000 GPH_CACHE ActivationGroup: 19

Kann ich das minimieren, so dass nur im Fehlerfall weitere Infos im Joblog und auch in der .log Datei im IFS ausgegeben werden ???
Vielen Dank im Voraus!
peet

[RobertPic]

Ohne das Produkt näher zu kennen. Es gibt dort eine log4j.properties. Dort kann man javatypisch die Loglevels konfigurieren.

[Peet]

Ohne das Produkt näher zu kennen. Es gibt dort eine log4j.properties. Dort kann man javatypisch die Loglevels konfigurieren.

Danke !
Diese Protokollierung habe ich jetzt im Griff, das log "ArdGateLog.log" hat jetzt nur noch die gewünschen Einträge !

Und im Joblog sieht es jetzt auch so aus, als ob der Zugriff auf Daten von JVAGATE nur 1x protokolliert wird, unabhängig von de Anzahl der abgerufenden Sätze.
Ich beobachte das weiter.
Nochmals vielen Dank.
Vg.

[BenderD]

... das Javalog wird, wie bereits erwähnt, über log4j.properties gesteuert. Damit ist dort alles regelbar, von selectivem logging für einzelne Programme oder Bereiche, bis hin zum reorg der Logdateien. Dazu gibt es jedwede Anleitung und Unterstützung im Netz.
Das logging im native Bereich ist davon nicht tangiert.
Zum logging gilt generell:
Im Bereich Programm Entwicklung empfehle ich stets mit globalem loglevel DEBUG zu arbeiten. Im Produktionsbetrieb könnte man das runtersetzen, wenn es dafür einen benennbaren Grund gibt. Man sollte dabei aber immer im Blick behalten, dass ein ausreichendes logging unverzichtbar zur Abklärung von Fehlersituationen ist. Von globalem abstellen halte ich überhaupt nichts und das logging in typischen RPG Anwendungen für völlig unzureichend.
Das logging des originären SQLCodes im Joblog ist unverzichtbar, das DB2/400 die Fehlerinformation des remote Servers zuweilen nache eigenem Gutdünken umbiegt und der SQL Code im Programm zuweilen Kaffeesatz Anteile enthält. Wer das verschlimmbessern will und das loggig abschalten will, die Software ist Open Source und eine Änderung in QRPGLESRC.JVAGATE kein Hexenwerk und PROPERTIES liefert das Handwerkszeug, das auch konfigurierbar zu machen. Immer frisch ans Werk. Ich bitte allerdings um Verständnis, dass ich dafür keinen weiteren Support leiste.

D*B

[Peet]

Danke, D*B.
Wichtig war mir die .log Datei im IFS, die war riesengroß.
Joblog stört zwar ein wenig, aber dafür ändere ich nichts, lohnt sich nicht.
Bei Fehlern muss man im Zweifelsfall sowieso das eigene RPG debuggern, also alles
gut.
Vg.
Peet

... das Javalog wird, wie bereits erwähnt, über log4j.properties gesteuert. Damit ist dort alles regelbar, von selectivem logging für einzelne Programme oder Bereiche, bis hin zum reorg der Logdateien. Dazu gibt es jedwede Anleitung und Unterstützung im Netz.
Das logging im native Bereich ist davon nicht tangiert.
Zum logging gilt generell:
Im Bereich Programm Entwicklung empfehle ich stets mit globalem loglevel DEBUG zu arbeiten. Im Produktionsbetrieb könnte man das runtersetzen, wenn es dafür einen benennbaren Grund gibt. Man sollte dabei aber immer im Blick behalten, dass ein ausreichendes logging unverzichtbar zur Abklärung von Fehlersituationen ist. Von globalem abstellen halte ich überhaupt nichts und das logging in typischen RPG Anwendungen für völlig unzureichend.
Das logging des originären SQLCodes im Joblog ist unverzichtbar, das DB2/400 die Fehlerinformation des remote Servers zuweilen nache eigenem Gutdünken umbiegt und der SQL Code im Programm zuweilen Kaffeesatz Anteile enthält. Wer das verschlimmbessern will und das loggig abschalten will, die Software ist Open Source und eine Änderung in QRPGLESRC.JVAGATE kein Hexenwerk und PROPERTIES liefert das Handwerkszeug, das auch konfigurierbar zu machen. Immer frisch ans Werk. Ich bitte allerdings um Verständnis, dass ich dafür keinen weiteren Support leiste.

D*B

[BenderD]

Bei Fehlern muss man im Zweifelsfall sowieso das eigene RPG debuggern,

... das macht bei verteilten und/oder multithreaded Anwendungen weder Sinn noch Spass. Der Platzbedarf für die Java logs lässt sich per Konfiguration von log4j genau einstellen, solange die Antwortzeiten besser als gefordert sind, gibt es keinen Grund das logging runterzufahren.
Würde man in seinen RPGs die SQL Statements, SQLCODES und Fehlerbedingungen in ein log schreiben, würde der Debugger in Rente gehen. Macht man das log konfigurierbar (log4RPG o.ä.), kann man dann flexibel entscheiden, ob man das mitlaufen lässt oder rausnehmen muss.

Für einige Anbieter kommerzieller Software wäre das natürlich eher peinlich, die schalten nicht nur jegliches logging ab, sondern tilgen aktiv Spuren.

D*B