PDA

View Full Version : CPYSPLF unterschiedliches Verhalten im Batch und interaktiv



Seiten : 1 2 3 [4] 5 6 7 8

BenderD
17-08-17, 08:20
Guten Morgen,

die Programmquelle ist leider zu groß um sie hier zu posten. Aber vielleicht hilft ja eine keine Beschreibung:


... das hilft nix, irgendeine deiner Annahmen ist ja offenkundig falsch, sonst hättest du den Fehler ja bereits gefunden. Wenn das Programm zu groß ist, dann muss man es halt minimalisieren.


Was mich stutzig macht ist, dass es auf einem System funktioniert und auf dem anderen nicht. Identer User auf beiden Systemen.


... auch das spricht für Workmanagement.

nico1964
17-08-17, 08:37
@D*B
Werden das heute auf der Produktivmaschine wieder scharf schalten und dann alles rausholen an Infos was wir nur finden können. Werde am Nachmittag unsere Erkenntnisse hier posten.
Wobei meine Befürchtung(aber auch Hoffnung) ist, dass es heute auf der Produktion funktioniert. Der Fehler ist Donnerstag und Freitag voriger Woche aufgetreten, danach habe ich die Befehle übersprungen. Von Sonntag auf Montag war dann unser wöchentlicher IPL.

BenderD
17-08-17, 08:40
@D*B
Werden das heute auf der Produktivmaschine wieder scharf schalten und dann alles rausholen an Infos was wir nur finden können. Werde am Nachmittag unsere Erkenntnisse hier posten.
Wobei meine Befürchtung(aber auch Hoffnung) ist, dass es heute auf der Produktion funktioniert. Der Fehler ist Donnerstag und Freitag voriger Woche aufgetreten, danach habe ich die Befehle übersprungen. Von Sonntag auf Montag war dann unser wöchentlicher IPL.

... warum übersprungen? Stattdessen auslagern in eigenes CL mit Parameter und das mit MONMSG aufrufen. Dann einen kleinen Treiber bauen, der den Ablauf simuliert und das ausgegliederte Programm aufruft.

D*B

nico1964
17-08-17, 08:51
... warum übersprungen? Stattdessen auslagern in eigenes CL mit Parameter und das mit MONMSG aufrufen. Dann einen kleinen Treiber bauen, der den Ablauf simuliert und das ausgegliederte Programm aufruft.

D*B
Das mit auslagern ist in diesem Fall nicht so einfach.

In dem COBOL-Pgm werden Dateien erstellt, welche je nach Verwendungszweck entweder das CL-PGM für den SEPA-Konverter oder den EDIFACT-Konverter aufrufen. Aus diesen Prorgammen wird dann am Ende jeweils das CL-PGM für den CPYSPLF mit dem PGM-Namen als Herkunft aufgerufen.

Fuerchau
17-08-17, 09:12
Ich sagte ja, dass ein IPL durchaus reinigenden Character haben kann.

nico1964
17-08-17, 09:29
Ich sagte ja, dass ein IPL durchaus reinigenden Character haben kann.
In ca. 1 Stunde weiss ich ganz genau Bescheid

nico1964
17-08-17, 11:16
Leider keine Änderung auf der Produktion der selbe Fehler wie letzten Freitag.

BenderD
17-08-17, 11:34
Das mit auslagern ist in diesem Fall nicht so einfach.


... dann darfst du das nicht doppelt nehmen!

Ich würde zumindest mal ein DMPCLPGM vor den copy spoolfile stellen.

Fuerchau
17-08-17, 11:44
Dann prüfe doch mal bitte folgenden Sachverhalt:
Wenn der MCH-Fehler auftritt (ohne MONMSG im Batch), prüfe mal per F1->F9 an wen die Meldung genau geht.
Und bzgl. der Pferde in der Apotheke...

Prüfe die komplette LIBL des Batchjobs.
Setze deine LIBL genau so, wie im Batchjob.
Schau dir per DSPCMD CPYSPLF die Objektherkunft an (manchmal gibt es so Leute, die sich Kopien in eigenen Libs vor die 1. SYSLIBL (Systemwert) setzen um Defaults anzupassen).
Ebenso wird da dann das ausführende Programm benannt.
Die Libs der beiden Objekte sollte zueinander passen.

Ggf. habt ihr für das Batch-SBS eine andere SYSLIBL als den Steuerwert definiert (macht man schon mal bei Sprachlibs QSYS29xx).
Hier ist ggf. ein OS-/PTF-Update nicht konsequent durch alle Libs gemacht worden (wodurchsich das Testsystem unterscheiden kann) so dass im Batch Kommando zum ausführenden Programm nicht mehr passen und deshalb der MCH ausgelöst wird.

Ändere ggf. den CPYSPLF-Aufruf in explizit QSYS/CPYSPLF ...

nico1964
17-08-17, 12:17
@D*B
werde den Dump für morgen einbauen.

@Fuerchau

bekomme dann die Auswertung vom heutigen Lauf vom Operator, dauert nur a bissl, wie der braucht an Kaffee