Arbeitsweise ADDRPYLE

[JanM]

Hallo,

habe ein Problem mit den automatischen Antworten auf unserem System (V5R4M0).
Einige Fehler werden automatisch beantwortet, obwohl diese MSG Id's nicht in RPY Liste definiert sind.
Beispiel.

Nachrichten-ID . . . . : CPA0702 Bewertung . . . . . . : 99
Nachrichtenart . . . . : Anfrage
Sendedatum . . . . . . : 23.10.15 Sendezeit . . . . . . : 14:25:10

Nachricht . . . : (C D I R) CPF2130 von Prozedur SED1010CL empfangen.
Ursache . . . . : Die ILE CL-Prozedur SED1010CL in Modul SED1010CL in
Programm SED1010CL in Bibliothek S2000LIB stellte einen Fehler bei
Anweisungsnummer 0000006700 fest. Der Nachrichtentext für CPF2130 ist: 0
Objekte dupliziert. 1 Objekte nicht dupliziert. Die Taste F10 (falls

Die Anweisung CRTDUPOBJ ist gezielt ohne MONMSG erfasst worden (dies darf normalerweise in dem Programm nie auftreten, und falls Ja, muss sondern behandelt werden).)
Diese Nachricht wurde automatisch mit C beantwortet.
Schlimmer aber, dass das Steuerprogramm auch die CPA0702 empfangen und sich auch automatisch mit Antwort C verabschiedet hat.

Nachrichten-ID . . . . : CPA0702 Bewertung . . . . . . : 99
Nachrichtenart . . . . : Anfrage
Sendedatum . . . . . . : 23.10.15 Sendezeit . . . . . . : 14:25:10

Nachricht . . . : (C D I R) CEE9901 von Prozedur ED0024CL empfangen.
Ursache . . . . : Die ILE CL-Prozedur ED0024CL in Modul ED0024CL in Programm
ED0024CL in Bibliothek S2000LIB stellte einen Fehler bei Anweisungsnummer
0000003400 fest. Der Nachrichtentext für CEE9901 ist: Anwendungsfehler.
CPF2130 nicht überwacht durch SED1010CL bei Anweisung 0000006700,

Niemand hat dies bemerkt und erst 3 tage später ist uns aufgefallen, dass die Daten fehlen, bzw. nicht bearbeitet werden können.

Frage:
In der RPYLE ist die MSGID= CPA0700 definiert. Kann es sein dass diese ID für alle Nachrichten im Bereich CPA0700 bis CPA0799 gilt?. Das würde die Vorgehensweise des Betrieb Systems erklären.....

Gruß
Jan

[Fuerchau]

Das ist korrekt.
Im MONMSG kann man ja auch "gruppieren":
MONMSG CPF0000 = alle Nachrichten mit CPF beginnend
MONMSG CPFXX00 = alle Nachrichten mit CPFXX beginnend
MONMSG CPFXXYY = nur diese eine Nachricht

Entscheidend für die Antwort ist der Jobstatus INQMSGRPY:
*RQD = Batch an QSYSOPR, Dialog an Terminal
*DFT = Default-Antwort aus MSGID, falls es dort eine gibt, sonst wieder *RQD
*SYSRPYL = Antwortliste falls vorhanden, sonst wieder *RQD

Wenn man sichergehen will, dass Fehler nicht beantwortet werden sollen dann einen CHGJOB durchführen.
Man kann sich den Status am Anfang des CLP's ja merken (RTVJOB) und hinterher wieder herstellen.
Somit ist jedes Programm selber verantwortlich.

[JanM]

Danke für die Antwort

In der JobD steht: Antwort auf Anfragenachricht... *RQD.
Im CL Programm ist INQMSGRPY auch nicht geändert worden.
Es dürfte also keine automatische Antwort erstellt werden oder irre ich mich ?.......

Das würde aber bedeuten, dass in tiefen des OS400 noch eine andere Schraube zu drehen geben muss, oder irgend ein PTF fehlt......

[Fuerchau]

Seit ihr sicher, dass nicht irgendein Programm im Job einen CHGJOB durchführt aber nicht aufräumt, also den Urzustand wiederherstellt?

Hierfür empfehle ich mal, den Loglvl des Job's auf 4 00 *seclvl zu stellen, CL-Befehle protokollieren und das Joblog mal nach CHGJOB zu durchsuchen.

Ggf. im Job sämtliche betroffenen Programme nach einem CHGJOB scannen.
Das OS/400 macht diesbezüglich wirklich nichts selbstständig!

[Dschainers]

Wenn am Anfang vom CLP ein MONMSG steht gilt dieser für das ganze Programm

[Fuerchau]

Ein MONMSG kann nur ESC-Nachrichten abfangen.
INQ-Nachrichten haben mit MONMSG nichts zu tun.

Beispiel:

CALL PGMXXX
MONMSG CPF0000 DO
machwas
ENDDO

PGMXXX:
SNDPGMMSG (Abfrage Nachricht an QSYSOPR)
RCVMSG (Warten auf Antwort)

An dieser Stelle bleibt das im PGMXXX.
Die Antwort wird durch den INQMSGRPY festgelegt.

Danach sendet PGMXXX ggf. eine Abbruch-Nachricht, die dann per MONMSG abgefangen werden kann.

[JanM]

Ich habe alle CL und RPG Teildateien durchsucht.
In keinem einzigem Source ändern wir das INQMSGRPY Parameter.
Es wird auch kein CHGJOBD über Programm abgesetzt.

Alle Jobs laufen bei uns mit SECLVL 4 00 *NOLIST. Nur im Falle der Fehler werden Protokolle erzeugt.
Ich werde bei dem problematischen Job das Param: Text von *NOLIST auf *MSG Ändern.
Vielleicht komme ich dann zum Ergebnis.
Problem ist, dass dieses Sachverhalt sehr selten erscheint.
Vorsichthalber habe ich aber die CPA0700 aus RPYLE entfernt.