Anmelden

View Full Version : wrkrpyle



Seiten : 1 [2]

Pikachu
10-04-21, 16:21
Sieh mal in den Hilfetext des Befehls MONMSG.
Da steht was zu diesen generischen Nachrichten-IDs,
die ganz rechts auf 2 oder 4 Nullen enden.

Fuerchau
11-04-21, 19:17
Automatische Antworten gibt es je nach Vergleichsdaten.
Wenn ich also eine Antwort auf RPGXXXXX mittels DFT beantowrten lassen, kommt anschließend zur Runtime ein CPF0000 mit dem Text "Nachricht MSGxxxx nicht überwacht".
Somit kann ich per CPF0000 alle Nachichten abfangen wenn ich einen entsprechenden CHGJOB INQMSGRPY gemacht habe.

ILEMax
12-04-21, 11:05
@Pikachu
bei MONMSG ist das ja bekannt. Wir finden immer wieder CPF0000 anstatt der spezifischen Meldung, die tatsächlich abgefangen werden soll, in den CL's von Kunden.

Das jedoch die mit einem 'D' ausgestattete, AUSGELIEFERTE Meldung: RPG0000 in der RPYLE dafür sorgt, das alle RPG-Meldungen zu einem Dump führen war mir nicht bekannt. Und hier ist die BedHelp auch nicht sehr aussagekräftig.

BenderD
12-04-21, 12:39
... es gibt weder eine CPF0000, noch eine RPG0000 (deswegen kann es sich hier nur um eine generische Behandlung handeln). Existiert kein Abfang, kommt eine CPF9999 hinterher, wobei es best practice ist, statt CPF0000 die CPF9999 zu fangen, wenn man denn überhaupt einen generischen Abfang macht, dann steht wenigstens im Joblog, was da in den Ofen ging.

D*B

Fuerchau
12-04-21, 14:19
Nun ja, das Schema des Abgfangens MONMSG, Monitor->On-Error, wird schon beschrieben:

XXXNNMM

XXX= Meldungs Gruppe
NN = Meldungsklasse, 00 = Alle
MM = MeldungsId, 00 = Alle

Somit gibts eine Hierarchie:

RPG1218 => wirklich nur diese
RPG1200 => Alle, die mit RPG12 anfangen
RPG0000 => Alle, die mit RPG anfangen.

Statt RPG kann jede beliebige Gruppe verwendet werden, der 4-stellig folgende ist Hex von 0000-FFFF

Die Runtime schmeißt ein CPF9999 wenn eben XXXnnmm nicht überwacht wird.
Hier gilt dann wieder:

CPF9999
CPF9900
CPF0000

Wenn also ein Idiot eine RPG0000 auf D-Antwort eingestellt hat, reklärt sich das von selber.