RNX9998 bzw. MCH3402

[MatthiasK]

Hallo,

wir haben Performance-Probleme in unseren Batch-Prozessen. Das kommt von vielen dynamischen Calls, die historisch bedingt so enthalten sind.
Jetzt habe ich mal die Aufrufe von CALL nach CALLB geändert und der Batch-Job ist tatsächlich um ca. 40% schneller. So weit so gut.
Wir haben aber die Möglichkeit, daß der Batchjob in der gleichen Job-Umgebung nochmals anläuft, also kein neuer SBMJOB abgesetzt wird, und jetzt kommt der oben beschriebene Fehler, weil ein CALLB Aufruf nicht mehr funktioniert.
Wahrscheinlich habe ich irgendwo ein Parameter-Längen-Problem bei den Aufrufen, so daß irgendwas zerschossen wird.
Jetzt meine Fragen:
1. Kann ich irgendwie nachvollziehen, welches Programm bzw. Parameter dieses verursacht?
2. Gibt es ein Tool, mit dem man rausfinden kann, ob Parameter zwischen rufendem und gerufenem Programm falsche Längen haben?

Vielen Dank für Eure Hilfe.

Matthias

[Fuerchau]

Es gibt kein Tool mit dem dieses Festgestellt werden kann, da letztendlich immer nur Adressen übergeben werden.
Die Länge und Ausprägung der Parameter wird einzig und allein durch die Quelle des Programmes bestimmt.
Es gib auch im Programm keine Möglichkeit festzustellen, welche Felder tatsächlich übergeben werden.

Kleine Ausnahme: ILE mit Descriptoren. Die Descriptoren können allerdings ignoriert werden.

Der Vorteil von CALL zu CALLB ist sicherlich das Binden der einzelnen Module zu einem Programm.
Allerdings kann es da zu Schwierigkeiten führen, wenn ein ehemaliges OPM-Programm nun als Prozedur aufgerufen wird:
*INLR = *ON beim Verlassen sowie *INZSR funktionieren nicht.
Wenn sich ein Programm also bisher darauf verlassen hat, beim erneuten Aufruf initialisiert zu werden, so erfolgt das beim CALLB nicht mehr und es kommt eben zu obigen Problemen.
Auch ein RCLRSC im aufrufenden CLP läuft so ggf. nicht mehr (das Problem hatten wir schon).
Ggf. ist das Hauptprogramm mit einer eigenen ACTGRP oder *NEW zu erstellen, so dass RCLACTGRP verwendet werden kann.
Dies löst dann auf jeden Fall das Initialisierungsproblem.

Aber Achtung:
Bei bestimmten Dateiformen (O-Bestimmungen) mit Blockung wird dann der letzte Puffer nicht in die Datei ausgegeben.

[MatthiasK]

Hallo Fuerchau,

das mit der eigenen Aktivierungsgruppe war eine gute Idee. Jetzt hats erstmal funktioniert, auch ohne Reclaim der Aktivierungsgruppe. Sollte ich den Befehl trotzdem absetzen?

Vielen Dank.

Matthias

[Fuerchau]

Wenn das 1. Programm der ACTGRP sich beendet, wird normalerweise auch die ACTGRP geschlossen.
Ein RCLACTGRP kann nicht schaden.

[B.Hauser]

Wenn das 1. Programm der ACTGRP sich beendet, wird normalerweise auch die ACTGRP geschlossen.
Ein RCLACTGRP kann nicht schaden.

Nur bei Aktivierungs-Gruppe *NEW wird die Aktivierungs-Gruppe bei Programm-Ende beendet. Ein RCLACTGRP ist in diesem Fall überflüssig, da Aktivierung und Löschung an den Programm-Aufruf gekoppelt sind.

Eine benannte Aktivierungs-Gruppe wird nicht beendet wenn das 1. Programm beendet wird, sondern nur auf inaktiv gesetzt, um bei einem erneuten Aufruf wieder aktiviert zu werden. (Siehe DSPJOB Auswahl 18)

Benannte Aktivierungs-Gruppen können nur über RCLACTGRP oder Job-Ende beendet werden. Ein RCLACTGRP ist also erforderlich, wenn die Aktivierungs-Gruppe gelöscht werden soll.

Birgitta