wrkrpyle

[ILEMax]

@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]

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

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.