QSYSOPR Meldungen als Email ausgeben

[BenderD]

... da kann die Brause aber labberig werden, bis das Programm das sequentiell durchhat, wenn da viele drinstehen.

D*B

Klar,
machste Dir eine PF mit den Nummern drin,
nimmst Dein Cl, rufts ein andres Cl mit der Nummer auf welches die Datei durchliest und Dir als Rückgabewert ja oder nein gibt.
Fettig ist die Brause

GG

[bettina_martin]

... da kann die Brause aber labberig werden, bis das Programm das sequentiell durchhat, wenn da viele drinstehen.

D*B

also wenn ich da alle 3 Minuten drüber loope wird das kein Problem sein denke ich

[Fuerchau]

Das Problem ist doch, dass du je Nachricht alle Einträge durchsuchen musst.
Wenn du also alle 3 Minuten 100 Nachrichten zu prüfen hast, deine "Tabelle" 100 Einträge enthält, benötigst im nagtiven Fall (Eintrag nicht gefunden) 10.000 Zugriffe.

Was den OVRDBF angeht, so ist in CLP immer noch das Problem, dass eine Datei nicht mehrfach gelesen werden kann (CLLE ggf. schon).

Was spricht also gegen ein Mini-RPG, dass nur einen Chain macht ?

[bettina_martin]

Das Problem ist doch, dass du je Nachricht alle Einträge durchsuchen musst.
Wenn du also alle 3 Minuten 100 Nachrichten zu prüfen hast, deine "Tabelle" 100 Einträge enthält, benötigst im nagtiven Fall (Eintrag nicht gefunden) 10.000 Zugriffe.

Was den OVRDBF angeht, so ist in CLP immer noch das Problem, dass eine Datei nicht mehrfach gelesen werden kann (CLLE ggf. schon).

Was spricht also gegen ein Mini-RPG, dass nur einen Chain macht ?

Spricht eigentlich nur dagegen das ich COBOL-Spezialist bin und kein RPG'ler........

[KingofKning]

Da wird mir jemand sympathisch ;-). Ich als alter Cobol Programmierer konnte noch nie nachvollziehen warum man in RPG programmiert. (Wobei historisch betrachtet waren RPG Programme damals wohl schneller als Cobol Programme)

Aber ich könnte dieses Problem auch nicht in RPG lösen.

GG

[bettina_martin]

Da wird mir jemand sympathisch ;-). Ich als alter Cobol Programmierer konnte noch nie nachvollziehen warum man in RPG programmiert. (Wobei historisch betrachtet waren RPG Programme damals wohl schneller als Cobol Programme)

Aber ich könnte dieses Problem auch nicht in RPG lösen.

GG

Ich 'musste' RPG zwangsweise kurz lernen vor ca. 20 Jahren am Beginn meiner Laufbahn. Da kommt einem nur das Kotzen mit der ganzen Bezugszahlen-Kacke aber das ist jetzt off-topic !

ich werds wohl in Cobol machen ;-)

[Pikachu]

Anstelle einem separaten RPG- oder COBOL-Programm ginge auch ein separates CL-Programm mit einem OVRDBF POSITION(*KEY ...) und einem RCVF drin.

Ich als alter Cobol Programmierer konnte noch nie nachvollziehen warum man in RPG programmiert.

RPG ist gut wenn man was mit Zeichenketten machen will, zum Beispiel diese aneinanderhängen ohne oder mit genau einem Leerzeichen dazwischen usw. Das geht in COBOL nur sehr umständlich oder ich hab den Trick übersehen.

Nachtrag: Und auch das Lesen mit Teilschlüsseln (READE, READPE) ist einfacher als in COBOL (da gibt's sowas nicht soweit ich weiß).

[Fuerchau]

OK, dann schreib ein Mini-COBOL, das nichts anderes als einen "READ ... INVALID KEY" dürchführt.
Das dürfte doch auch kein Problem sein.
Da COBOL durch seine Rununit die Aktivität selber steuert (*INLR gibts da nicht), kannst du aus Performancgründen einen OVRDBF ... SHARE(*YES) machen, damit der Open/Close dann schneller geht.

Ein "exit program and continue run unit" geht nur, wenn das programm von einem anderen COBOL-Programm aufgerufen wurde.

Was den OVRDBF POSITION angeht, so benötigst du für jeden Zugriff einen
OVRDBF
CALL
OPEN (Implizit)
RECVF
CLOSE (Implizit bei RETURN/ENDPGM)
und das dauert.

[bettina_martin]

OK, dann schreib ein Mini-COBOL, das nichts anderes als einen "READ ... INVALID KEY" dürchführt.
Das dürfte doch auch kein Problem sein.
Da COBOL durch seine Rununit die Aktivität selber steuert (*INLR gibts da nicht), kannst du aus Performancgründen einen OVRDBF ... SHARE(*YES) machen, damit der Open/Close dann schneller geht.

Ein "exit program and continue run unit" geht nur, wenn das programm von einem anderen COBOL-Programm aufgerufen wurde.

Was den OVRDBF POSITION angeht, so benötigst du für jeden Zugriff einen
OVRDBF
CALL
OPEN (Implizit)
RECVF
CLOSE (Implizit bei RETURN/ENDPGM)
und das dauert.

alle wege führen nach rom....ich kann auch im cobol-pgm ein sql-statment einbauen welches die datei mit den ausnahmen liest.....gibt wohl viele Möglichkeiten.

[Fuerchau]

Stimmt schon, aber brauchst du den SQL-Overhead ?

[bettina_martin]

Stimmt schon, aber brauchst du den SQL-Overhead ?

nein, natürlich nicht. aber ich bin sql einfach gewohnt, da ich die letzten 10 jahre nichts anderes gemacht habe als SAP......und davor 10 Jahre AS/400-Programmierung.

ich muss da wieder reinkommen

[BenderD]

... man kann natürlich auch als NEP ein COBOL aufrufen, das ein CL aufruft, das den Loop mit dem DLYJOB macht und dann RCVMSG und per MSG ein weiteres COBOL aufruft, das dann die Datei liest ... - dann bleibt die COBOL Runtime im Job aktiv.
Naja, bei Lichte betrachtet geben sich die Schwafel- und die Stammelprogrammierung nicht viel...

D*B

OK, dann schreib ein Mini-COBOL, das nichts anderes als einen "READ ... INVALID KEY" dürchführt.
Das dürfte doch auch kein Problem sein.
Da COBOL durch seine Rununit die Aktivität selber steuert (*INLR gibts da nicht), kannst du aus Performancgründen einen OVRDBF ... SHARE(*YES) machen, damit der Open/Close dann schneller geht.

Ein "exit program and continue run unit" geht nur, wenn das programm von einem anderen COBOL-Programm aufgerufen wurde.

Was den OVRDBF POSITION angeht, so benötigst du für jeden Zugriff einen
OVRDBF
CALL
OPEN (Implizit)
RECVF
CLOSE (Implizit bei RETURN/ENDPGM)
und das dauert.