[NEWSboard IBMi Forum]

Thema: wrkrpyle

Hybrid View

  1. #1
    Registriert seit
    Feb 2001
    Beiträge
    20.695

  2. #2
    Registriert seit
    Sep 2005
    Beiträge
    425
    In dem Ablauf gibt es weder chgjob noch chgjobd.
    Heute hat einer dieser Läufe, die sich ab und an selbst mit 'D' beantworten, ganz 'normal' angehalten und artig auf sein 'R' gewartet.
    Gibt es irgendweche Grenzen
    - länger als x Minuten
    - mehr als x Jobs wollen den Satz lesen
    - ...
    Kann doch nicht sein, das die Kiste das nach Lust und Laune entscheidet!
    Der ILEMax

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    Vielleicht hat da jemand mit D geantwortet?
    Gibts jemanden, der mit Überwachungssoftware hier Antworten senden kann?
    Steht die Antwort noch in QSYSOPR (wahrscheinlich nicht). Mit F9 auf der Antwort sollte ggf. die Senderinfo sichtbar sein.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Sep 2005
    Beiträge
    425
    Vielleicht hat da jemand mit D geantwortet?
    Das war auch meine erste Vermutung!
    Aber:
    F1 im (noch aktiven) Job auf das 'D' besagt als Nachrichtnart:
    Antwort von der Systemantwortliste

    F1 auf eine der 'üblichen 'R' antworten ist ein anderer Text, der auf die manuelle Eingabe hin deutet.

    Überwachunssoftware
    k.a. das System ist gehostet, der Hoster setzt Nagios (oder so ähnlich) ein.
    Aber die beantworten unsere Meldungen nicht!
    Außerdem läuft GSMTEXT aber das ist, soweit ich es verstanden habe, nur zum benachrichtigen, nicht zum beantworten.

    F9
    da der Job noch dabei war, den DUMP zu schreiben, konnte ich f1 im Joblog drücken (siehe oben)

    Komisch ...

  5. #5
    Registriert seit
    May 2007
    Beiträge
    295
    Im DSPLOG zB kann man mittels F1 auf die Antwort auch den Beantworter sehen. Vielleicht siehst du hier mehr wer das beantwortet hat.
    Greets
    Christian
    Anwendungsentwickler und ein bissal Systemoperator
    https://github.com/prsbrc
    LinkedIn

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    Kann es sein, dass u.U. Programme aufgerufen werden, die für sich einen CHGJOB INQMSGRPY(*SYSRPYL) machen, aber wieder vergessen, dies zurück zu nehmen, wenn z.B. ein Fehler aufgetreten ist?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Sep 2005
    Beiträge
    425
    Ja, es gibt tatsächlich einen Möglichkeit, das der Job ein CL mit dieser Umstellung ruft.

    Das bedeutet dann aber, das der Eintrag
    "RPG0000 mit 'D' beantworten"
    bedeutet das ALLE RPG Meldungen mit D beantwortet werden (es sei denn es gibt andere expliziete RPGxxxx Einträge)
    Für CPF0000 war das bekannt, bei RPG hatte ich bisher keine Berührungspunkte damit ...
    Danke, der ILEMax

  8. #8
    Registriert seit
    Nov 2003
    Beiträge
    2.403
    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.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Sep 2005
    Beiträge
    425
    @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.

  11. #11
    Registriert seit
    Mar 2002
    Beiträge
    5.365
    ... 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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  12. #12
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •