SQLRPGLE und Printerfile

[Toschie]

Hallo hel400,

danke für den Hinweis.
Das Habe ich jetzt durchgeführt.
Ich habe es interaktiv aufgerufen.
Parallel dazu habe ich noch die Jobprotokollierung hoch geschraubt.

Dabei erhalte ich (gefühlte) millionen mal folgenden Eintrag:

Return Code = 00000000000000000000000000000000 
Return SubCode = 00000                         
Anweisung SET beendet.

Die Konsequenz daraus ist, das ich einen überlauf vom Joblog bekomme.

Überlauf der Jobnachrichtenwarteschlange für 432435/TOSCHIE/QPADEV0009 erlaubt.

Ist das aus der SQL-Funktion?
Kann man das unterdrücken? =)

[Fuerchau]

Im Debugmodus werden diese Meldungen ins Joblog geschrieben und lassen sich auch nicht unterdrücken.
Wenn du dann einen Überlauf des Joblogs bekommst wird normalerweise (Modus *WRAP) halt ein Joblog gedruckt und weitergemacht.
Der Prozess wird allerdings stark verlangsamt.

Das Hochschrauben der Jobprotokollierung hat nur einen Effekt, wenn das Joblog auch tatsächlich ausgegeben wird. Im aktiven Joblog sieht man immer alle Meldungen.

Das Drucken ist sicherlich nicht das Problem sondern der Rest des Programmes.

[Toschie]

Im Debugmodus werden diese Meldungen ins Joblog geschrieben und lassen sich auch nicht unterdrücken.
Wenn du dann einen Überlauf des Joblogs bekommst wird normalerweise (Modus *WRAP) halt ein Joblog gedruckt und weitergemacht.
Der Prozess wird allerdings stark verlangsamt.

Das Hochschrauben der Jobprotokollierung hat nur einen Effekt, wenn das Joblog auch tatsächlich ausgegeben wird. Im aktiven Joblog sieht man immer alle Meldungen.

Das Drucken ist sicherlich nicht das Problem sondern der Rest des Programmes.

Hallo Fuerchau,

danke für dein Kommentar.
Ich hatte leider einen krankheitsbedingten totalausfall

Wollte mich erstmal für alle Hinweise bedanken!
Die API funktioniert schon wunderbar =)

eine Frage noch an dich Fuerchau:
Was genau meinst du mit

Im Debugmodus werden diese Meldungen ins Joblog geschrieben und lassen sich auch nicht unterdrücken.

Danke an alle =)

[andreaspr@aon.at]

eine Frage noch an dich Fuerchau:
Was genau meinst du mit

Im Debugmodus werden diese Meldungen ins Joblog geschrieben und lassen sich auch nicht unterdrücken.

Wenn der der Job unter DEBUG läuft (STRDBG) schreibt SQL eine Fülle an Informationen ins Joblog.
Damit dann das Joblog nicht überläuft, musst du im Job definieren was in solch einem Fall gemacht werden soll (z.B. *WRAP)

lg Andreas

[Fuerchau]

SQL wird im Debug-Modus halt sehr gesprächig, was auch gut so ist.
Ohne Debug-Modus lassen sich SQL-Hinweise per QAQQINI auch aktivieren, könnte aber eben zu den Joblogproblemen führen.
Ich hatte da halt mal einen Fall, dass das Joblog auf 16MB beschränkt war, die SQL-Hinweise per QAQQINI aktiv, was zur Folge hatte, dass in wenigen Sekunden mehr als 1000 Joblogs erstellt wurden (auch die kosten Zeit), da eben SQL äußerst gesprächig war.
Hauptursache war hier, dass für einen Select kein NULL-Anzeiger gesetzt wurde was im Joblog protokolliert wurde, dem Programm aber egal war (die Variable wurde eben vorher initialisiert).
Die Laufzeit war daher mehrere Minuten. Nach einsetzen des NULL-Anzeigers lief das Programm nur noch Sekunden und es wurden auch keine Joblogs produziert.

Das Problem ist doch, dass jede gesendete Nachricht erst mal im Speicher-Joblog aufgezeichnet wird.
Dies gilt unabhängig von der LOGLVL-Einstellung!
Diese zieht erst, wenn denn tatsächlich ein Joblog in den Spool ausgegeben wird und dann ist das der Filter für die Nachrichten.
Wäre dem nicht so, könnte man per Programm z.B. nicht mehr per RCVMSG auf "Complete"-Nachrichten gehen um dort enthaltene Informationen auszulesen.

[Toschie]

Dankeschön =)

Das habe auch ich verstanden =)

Problem wurde damit vollständig gelöst!

Ich bedanke mich bei euch =)

[Toschie]

Hallo ExAzubi,

danke für den Hinweis.
Diese Funktion hatte ich damals schon gefunden, aber nie ans Laufen bekommen.
Wenn ich

 /free                                                                     
   result = %ScanRpl ('NAME' : 'Tom' : string1);                           
 /End-Free

implementiere, dann erhalte ich die Meldung:
Das Token ist ungültig; das Token wird ignoriert.

Und der Cursor springt an das %-Zeichen.
Andere Funktionen wie z.B.

result = %replace ('Toronto': result);

funktionieren.

[Fuerchau]

Das liegt an der fehlenden Unterstützung des Editors.
Ignorieren und Compilieren, solange der Compiler nicht meckert ist das OK.

[Toschie]

Haha Danke
Ich Genie

Also die Funktion ist nun drin und es geht etwas schneller.
Das ist schon mal gut!

Was mir jetzt aufgefallen ist, das ein CL ständig einen OVRDB und einen DLTOVR macht.
Wir drucken hier im Batch und benötigen die OVR.
Kann ich irgendwie prüfen, ob der Job bereits eine Überschreibung auf eine gewisse Datei hat?

[Fuerchau]

Das gibt es schon per API.
Allerdings kostet dieser keine Performance solange die Datei nicht auch ständig auf und zu gemacht wird.
Das CL kann aber andererseits per DTAARA in der QTEMP vermerken dass der OVR schon aktiv ist.
Problematisch wird es dann wenn dann irgendwo ein DLTOVR *ALL läuft.

Die Frage ist wirklich, wo dein Programm die Performance verliert.
Welche Routine ist eben langsam und wird 1000de Male pro Write-Spool ausgeführt.