Unterfrogramm mir Return verlassen

[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 ...

;-)

[Rincewind]

Hi,

bei grösseren Verarbeitungen (naja 1 MILL. Sätze sind ja eigentlich keine grossen mengen) splitte ich gerne mal meine Programme.

Sprich: Im CL die Satzanzahl der Datei ermitteln, dann z.b. durch 10 teilen und 10 Jobs submitten mit der Beginnsatznummer und der Endesatznummer.

Dann laufen die 10 Parallel und lesen jeweils nur 100.000 Sätze. Dadurch sollte die Gesamtverarbeitung zwar nicht auf 1/10tel der Zeit Reduziert werden (weil die ja alle mehr performance brauchen) aber zumindest würde ich schätzen von 7 Stunden auf 1 müsstest du kommen.


Gruss
Rince