PDA

View Full Version : CPYSPLF unterschiedliches Verhalten im Batch und interaktiv



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

Robi
10-08-17, 14:55
Und du bist sicher, das die Source des CL und das OBJ zu einander passen?
und das rufende Pgm 200 Byte Emailadresse(n) weggibt.

Fuerchau
10-08-17, 14:59
Manchmal hat der eine Fehler mit dem anderen nichts zu tun.
Ggf. hat das ausführende Programm unter dem User keine Berechtigung an dem IFS-Pfad, so dass die PDF nicht erstellt werden kann.
Manche Programme gehen halt immer davon aus, dass alle Ressourcen verfügbar sind.
Hier ist echtes Raten angesagt.

TheDevil
11-08-17, 06:22
Guten Morgen,

nur mal so eine Idee / Frage ... Wird das Spool interaktiv erstellt und dann soll der Batchjob dieses ins IFS al PDF bringen ? Wenn ja dann hätte das Spool ja eine andere Jobnummer (Terminalsession) als der Batchjob und dann wird das Spool ja nicht gefunden.

Gruß,
Ralf

nico1964
11-08-17, 07:19
Guten Morgen,

nur mal so eine Idee / Frage ... Wird das Spool interaktiv erstellt und dann soll der Batchjob dieses ins IFS al PDF bringen ? Wenn ja dann hätte das Spool ja eine andere Jobnummer (Terminalsession) als der Batchjob und dann wird das Spool ja nicht gefunden.

Gruß,
Ralf
Guten Morgen,

der Ablauf gestaltet sich so:

1. Aufruf eines Auswahlprogramms COBOL-Programm
2. Submit Job COBOL-Programm
Dieses erstellt unter anderem auch das Spoolfile
3. Aufruf eines CL-Programms aus dem COBOL-PGM von Punkt 2
4. Aufruf des CL-PGMS welches den CPYSLPF und anschließen ein Mail machen soll.

TheDevil
11-08-17, 07:28
Hallo.

1. Ist das Spool evtl. noch auf Status "OPN" und somit für das CPYSPLF evtl. nicht greifbar
2. Ist in den CL´s Pukt 3 und 4 ein RCLRSC vorhanden? Wenn nein den bitte mal einfügen. Wir hatten damit auch schon so unsere Phänomene wenn der nicht im CL war ...

Gruß,
Ralf

nico1964
11-08-17, 07:37
Guten Morgen Ralf,

der Spool wird entweder im 2. Cobol oder im 1. CL-Programm geschlossen. Für den 2. Punkt muss ich mich noch mit unserem Opi kurzschließen, da dies ein Produktionsfehler ist. Werde mal mit ihm bei einer Zigarette darüber plaudern.

Gruß
Andreas

nico1964
11-08-17, 08:07
So, mal mit meinem Opi gesprochen, RCLRSC eingebaut und beim CPYSPLF den Parameter OPNSPLF(*YES) gesetzt. Mal schauen ob es heute funktioniert. Falls nicht bin ich mit meinem Latein am Ende.

Ach ja nur der Vollständigkeit halber: V7.1 aktueller PTF-Stand(ca. 14 Tage alt)

Fuerchau
11-08-17, 10:22
Manchmal kann ein RCLRSC inzwischen kontraproduktiv sein, ins besonders wenn man mit Service-Programmen (ACTGRP(*CALLER)) umgeht. Hier werden ggf. Ressourcen zurückgefordert, auf die aber ein Pointer im Service-Programm noch verweist (z.B. offene Dateien), die dann aber nicht neu initialisiert werden.
Auch dies führt dann unweigerlich zu MCH-Folgefehlern.
Bei reinen OPM-Umgebungen war das egal, da inaktive OPM-Programme tatsächlich entfernt werden. Bei Serviceprogrammen ist das nicht mehr unbedingt der Fall.

Um bei Dauer-Batchläufern wieder eine saubere Umgebung zu erhalten, ist ggf. ein TFRJOB eine Alternative für einen Restart.

nico1964
11-08-17, 10:25
Leider wieder nicht geklappt. Jetzt flieg ich schon beim RCLSRC. Jetzt fehlt mir eindeutig der Plan

Fuerchau
11-08-17, 10:31
Da scheint aber was mit deiner Jobumgebung nicht zu passen.
Ein RCLRSC sollte eigentlich nie einen Fehler verursachen (Ausnahme siehe oben).