Automatic system reply in iSeries

Tags:
AS/400
iSeries
New employer. At some point in the recent past, they STOPPED getting messages requiring a response for things like Decimal Data Errors, and Can't add record. File is full. Don't see the messages (s/a MCH1200) in the system reply list. So what changed - globally? User profiles? Job Descriptions?


Software/Hardware used:
iSeries
0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 21  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • pdraebel
    These kind of messages are usually sent to the QSYSOPR message queue. Check the status of that queue first. (Delivery method)
    7,545 pointsBadges:
    report
  • SweigartMark

    Messages either don't get sent to QSYSOPR, or have already been replied to (a default reply).   they do not sit, waiting for a reply as in other shops I've worked at.   I've been on the 400 since the late 80s and this is the first I've seen this.   


    110 pointsBadges:
    report
  • SweigartMark
    I tried duplicating the error I got the other day, so I could be more specific about the error - where it appears, etc., but could not. sorry.
    110 pointsBadges:
    report
  • ToddN2000
    Check to see if the application has a MONMSG and how it's handled.
    135,485 pointsBadges:
    report
  • pdraebel
    Verify that messages are answered through the reply list :
    DSPLOG QHST to *PRINT
    Scan the spoolfile for SYSRPTL : those are replied with the system reply list.

    Have you also checked QSYSMSG message queue ?
    7,545 pointsBadges:
    report
  • SweigartMark
    Was not aware that we'd be able to see SYSRPTL. Unfortunately, nothing in the log. But this gives me something to zero in on the next time I get an "auto-answered" message. Thanks.
    110 pointsBadges:
    report
  • pdraebel
    Sorry, not SYSRPTL but SYSRPYL

    7,545 pointsBadges:
    report
  • SweigartMark
    No problem, still no hit. 

    Does it make a difference that these programs are generated via SYNON? Could that have anything to do with it? A setting there, perhaps?
    110 pointsBadges:
    report
  • pdraebel
    Sorry, have no experience with SYNON. In case no error messages get to the QSYSOPR message queue: do you have job start and end messages?
    7,545 pointsBadges:
    report
  • SweigartMark

    Ok. Called the program again with blank parameters. I get a message at the bottom of my session that says,

    "Message . . . . : Application error. MCH1202 unmonitored by EL1453R at statement 0000009500, instruction X'0000'. So I have a program and a line#. What I DON'T have is any means to obtain a DUMP; it's automatically been answered. I do NOT see the message in QHST or in QSYSOPR. Thanks

    110 pointsBadges:
    report
  • ToddN2000
    If they have auto replies to this error, decimal data error, that is not good. If this is a batch job, the I would look at the program, go to that line and see what field is being used. The I would check the database and look for bad data in that field. If this is an interactive job then there should be data validation before anything is written to the database. If possible, you could run this in debug mode and you could find the invalid data.
    135,485 pointsBadges:
    report
  • SweigartMark

    That's what I'm trying to figure out - why it's being auto-answered. In this particular case, it's a small program and it's easy to figure out what is causing MCH1202. I'm trying to get a brownie point or two with the new employer by figuring out what's going on with OTHER - like maybe the vast majority of - programs that are doing the same thing. It "just started happening" some months ago and they have not taken the time yet to figure out the cause.

    Auto reply list? Doesn't look like it.
    Setting in SYNON? I don't know enough about SYNON to know.
    User Profile? System setting? Aliens? Not sure.

    110 pointsBadges:
    report
  • ToddN2000
    Found this in another post by Martin Gilbert.
    You can use the system reply list for this – command is WRKRPYLE – Work with reply list entries. You may need to change the relevant job to INQMSGRPY(*SYSRPYL).
    135,485 pointsBadges:
    report
  • SweigartMark
    That's been suggested, but there's no entry in the list for MCH1202 or MCH1200 (which I think is the "wildcard" for all MCH12nn messages)
    110 pointsBadges:
    report
  • pdraebel
    Have you tried to use a system command (like CPYF) that you know will trigger a message (Copying to a file that does not exist) and checked what messages you get.
    7,545 pointsBadges:
    report
  • SweigartMark
    That's why I called a program to cause a 1202. To see what I'd get.
    110 pointsBadges:
    report
  • pdraebel
    Is this only happening with MCH1202 (Decimal Data Error)?
    Maybe the Message parameters of the MCH1202 were changed?
    7,545 pointsBadges:
    report
  • SweigartMark
    Has been mentioned (again, I'm the new guy so haven't seen much of what is going on) that it happens also with "Record not added", which is CPA5305?
    110 pointsBadges:
    report
  • ToddN2000
    Why anyone would set up auto replies to those types of messages is beyond me. They indicate a problem that should be looked at. Skipping over them is just crazy. Not having worked with SYNON myself I can't tell if the issue is there. If I can think of something else that has not already been mentioned I'll report back.
    135,485 pointsBadges:
    report
  • SweigartMark
    The fact that it IS crazy to not monitor such messages is why they think it must be a system setting that was accidentally set. Whether in a release of the operating system, or Synon or. They don't think it was malicious. But it is definitely annoying!
    110 pointsBadges:
    report
  • TheRealRaven
    If you look at message ID CPA5305, you'll see that it has a default reply of '0'. Also, it has a couple "special" reply values: 'C' becomes '0' and 'I' becomes '1'. The reply type is DEC(4 0), so in all cases the reply is converted to a numeric value.

    If the QSYSOPR *MSGQ is set to DLVRY(*DFT), then messages that are sent to it requiring a reply will receive the default reply that is defined for the message ID.

    Not seeing a message in QSYSOPR doesn't mean that a message wasn't sent to it nor that a reply wasn't sent. Messages can easily be deleted in many ways. A *MSGQ monitor might be assigned. It might be a filtered severity. It might be a filtered message type. A number of possibilities might mask or simply remove the message.

    I do NOT see the message in QHST or in QSYSOPR.

    When you generated the MCH1202 error, what message were you not seeing in QHST/QSYSOPR? The MCH1202 should only be in the program's message queue. It should never be in QHST nor QSYSOPR. Only a message ID such as CPA0702 would get into one of those.
    36,420 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: