QSYSOPR Meldungen als Email ausgeben

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

[Fuerchau]

Dann würde ich doch gleich auf REXX umsteigen.
Da kannst du dann CMD's inlc. RTV-CMD's genauso ausführen wie SQL und du hast alles in einem "Programm".

[RobertPic]

@Zur Coboldiskussion

Wie seit denn ihr drauf?

Wenn das aufrufende Programm ein ILE Programm und das ILE-Cobol mit ACTGRP *CALLER compiliert wurde und das Programm mit GOBACK verlassen wird
--> bleibt die Cobol-Umgebung offen

sprich:
- die Variablen behalten ihre Werte
- ungeschlossene Dateipfade bleiben offen und können weiterbenutzt werden
- bringt das deutliche Performancegewinne

Das funktioniert übrigens auch mit SQL stored Procedure die CL(LE) und/oder CBL(LE) aufrufen.

[bettina_martin]

Habe nun mein Programm fertig welche mails verschickt von Meldungen am qsysopr.

Ein Problem habe ich hierbei noch: wie kann ich im 'Loop' über das rcvmsg verhindern das nachrichten vermailt werden, welche bereits einen reply haben ?

Ich versende nur nachrichten welche bei RTNTYPE '05' stehen haben, also Antwortnachrichten.

Nur verschickt er mir aber auch Messages, welches bereits eine Antwort haben. Wie kann ich nur 'offene' messages abchecken ?

lg

[Bodo Roggenkamp]

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 ?

Nur kurz erwähnt: Es ist sehr wohl möglich, in CLP eine Datei mehrfach auszulesen.

Gruß
Bodo

[Fuerchau]

Ich sprach ja auch von CLLE, da sollte es per OPNID im DCLF gehen, wenn man per CLOF die Datei wieder schließt.
Aber auspropiert habe ich das noch nicht, sicherer ist mir da immer noch TFRCTL.