Unterfrogramm mir Return verlassen

[RobertMack]

Hallo Peter,

ich verfahre in solchen Fällen so:

----------------------------

PGM_A:
CALL PGM_B PARM MODUS " "
...
...
SETON LR
CALL PGM_B PARM MODUS "E"

----------------------------

PGM_B:
kein USROPN
*ENTRY PLIST, PARM MODUS
...
...
MODUS IFEQ "E"
SETON LR
ELSE
RETRN
ENDIF

Achtung: *INZSR würde in PGM_B nur einmal ausgeführt,
ansonsten bleibt alles offen, d.h. Sätze MÜSSEN immer durch Update, Setgt oder Unlck freigegeben werden

Gruß,
Robert

[peter.kinne]

Hallo Robert,

erst einmal recht herzliche Grüße aus Köln.

So wie du es schreibst mache ich es normalerweise auch.
Nur in diesem Fall sieht es so aus, als wenn die Files nicht offen bleiben.

Normalerweise ist es mir auch egal. Nur der Batchjob hat unmögliche Laufzeiten (ca. 7 Stunden bei 1.000.000) Datensätze der Primärtabelle.

Und da der Job jede Woche laufen soll, bekommen die Systemer Schmerzen.

Viele liebe Grüße

Peter

[RobertMack]

Hallo Peter,

bin auch schon auf solche Trümmer gestoßen. Oft liegt es daran, daß zu jedem Primärsatz X chains auf andere Tabellen erfolgen (kaum zu glauben, aber wahr).

Sieh dir mal die Leseschleife und Sortierung der Primärdatei/en an, oft ergibt sich die Möglichkeit zusätzliche Chains nur noch bei Wechsel des jeweiligen Schlüsselfeldes vornehmen zu müssen (Gruppenwechsel).

Mit Grüßen aus Rosenheim (und Stuttgart ;-)
Robert

[peter.kinne]

Hallo Robert,

das Programm, dass ich aufrufe (PGM_B) ist neu und auch gut. Es ist ein Modul zur Ermittlung einer Sachbearbeiterzuständigkeit. Es wurde vor Wochen für den Dialogbetrieb erstellt. Bei einem Satz (Mitglied, Aktenzeichen oder Postleitzahl) im Dialog geht es fix. Nun muss ich aber eine Tabelle mit 1 MIO Sätzen verarzten und da kommt die Maschine an ihre Grenzen.

Wenn alles nicht klappt, muessen wir halt damit leben.

Gruß

Peter

[Fuerchau]

Vielleicht liegt es ja auch an dem aufrufenden Programm oder noch darüber (ggf. ist da irgendwo ein RCLRSC o.ä.?).
Wenn dein Upro aktiv bleiben soll, dann verpass ihm doch eine eigene Aktivierungsgruppe:
hACTGRP('MYOWNGRP')
Dann müsste zumindest dieses PGM aktiv bleiben und zwar unabhängig vom Aufrufer.

Ein weiterer Grund ist häufig die PF in die geschrieben/upgedatet wird und nicht das Lesen.
Wenn eine PF mit FRCWRITE(1) definiert ist, muss jeder Write zwingend auf die Platte geschrieben werden. Ein Systemcache wird somit ausgeschlossen. Bestimmte Anwendungen (z.B. Brain) stellen damit eben (weitgehend) Konsistenz sicher.
Bei einem CPYF kann z.B. ein Copy mit FRCWRITE(*NONE) bis zu 100-Mal oder gar mehr schneller erfolgen.

Achte mal im Joblog auf Hinweise wie "Blockung wurde von nnn in 1 geändert".

[RobertMack]

Hallo Peter,

ich dachte da eher an PGM_A ...

;-)