-
Unterfrogramm mir Return verlassen
Hallo zusammen.
ich habe zwei Programme, nennen wir sie mal PGM_A und PGM_B.
In PGM_A werden sequentiell ca. 1.000.000 Sätze gelesen und mit jedem Satz das Programm PGM_B aufgerufen. Die Laufzeiten sind sehr schlecht. Nun habe ich PGM_B modifiziert. Alle Tabellen werden USROPEN geöffnet. Dieses erfolgt in der *INZSR. Mit einem Flag sollte es nur einmalig erfolgen. Das Programm an sich wird nicht mehr mit LR sondern mit Return verlassen. Ich hatte mir vorgestellt, dass durch das Öffnen und Schließen der Tabellen eine Menge Zeit gespart wird.
Wenn ich mir den Job nun anschaue, der im BATCH läuft, sehe ich aber, das die Tabellen mal auf und mal zu sind.
Wie kann ich das Programm im Speicher halten und vor allem, wie kann ich die Tabllen offen halten ?
Danke für Tipps,
Peter Kinne
-
Hallo Peter,
ich glaube, das Problem ist das *USROPN in PGM_B:
Wenn du mit Return in einem Programm zurück gehst, bleiben die Dateien offen.
du hast ihn, glaube ich, mit dem *Usropn ausgetrickst.
Stefan
-
Falls ILE in Frage kommt, kannst du vielleicht aus dem Schreiben in die Tabellen in PGM_B eine Prozedur machen, die du in PGM_A aufrust. Ein CALLP sollte um einiges schneller sein als ein normaler CALL.
Gruß
Sascha
-
Das hat mit Return und USROPN nix zu tun !
Ist LR=*ON werden alle Dateien geschlossen, ist *LR=*OFF bleiben sie offen.
-
@Jonny
Der CALL einer Prozedur mit CALLP oder ein OPM-Call unterscheidet sich in der Laufzeit kaum, da bei Programminit alle Zeiger auf evtl. Call's initialisiert werden und somit nur unwesentlich langsamer als ein EXSR ist.
Wenn dem nicht so wäre, hätte die AS ganz schön Schwierigkeiten, da ALLE DB-Funktionen (SQL und Native) und viele Runtime-Funktionen per OPM-CALL aufgerufen werden !!
-
Laufzeiten
hello,
da muss ich doch auch noch meinen senf dazu geben...
Als Knackpunkt sehe ich die exakte Datei-Positionierung in Programm B und dann das sofortige Ende (sprich nicht bis zum Ende weiterlesen) wenn die Arbeit getan ist.
Man glaubt gar nicht, wieviel man da an Laufzeiten sparen kann....
kuempi
-
 Zitat von Fuerchau
Das hat mit Return und USROPN nix zu tun !
Ist LR=*ON werden alle Dateien geschlossen, ist *LR=*OFF bleiben sie offen.
Alle Tabelle in PGM_B stehen auf USROPN und werden in der *INZSR geöffnet. In dem Programm gibt es kein *INLR sondern nur RETURN.
Trotzdem sehe ich bei WRKJOB nicht immer alle Files. Bin mir deshalb nicht sicher, ob es klappt, was ich mir vorgestellt habe.
Peter
-
Da es denn ILE ist dann mit ACTGRP(*CALLER) erstellen.
-
 Zitat von kuempi von stein
hello,
da muss ich doch auch noch meinen senf dazu geben...
Als Knackpunkt sehe ich die exakte Datei-Positionierung in Programm B und dann das sofortige Ende (sprich nicht bis zum Ende weiterlesen) wenn die Arbeit getan ist.
Man glaubt gar nicht, wieviel man da an Laufzeiten sparen kann....
kuempi
Das ist hier kein Problem, weil PGM_B f gezielte CHAINS macht
-
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
-
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
-
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
Similar Threads
-
By Kaufmann in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 06-10-06, 10:44
-
By Squall in forum IBM i Hauptforum
Antworten: 31
Letzter Beitrag: 28-09-06, 17:53
-
By malzusrex in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 19-09-05, 15:25
-
By neuling_ in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 13-05-04, 07:10
-
By delphix in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 23-01-02, 14:02
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks