We have an interactive CL program that uses SNDNETSPLF to send a spool file to a second outq on the same AS400 running V5R4. After the operation has completed the user receives the message and has to press Enter before the job will continue. Is there a way to suppress this message without submitting the job?
ADDRPYLE SEQNBR(nnn) MSGID(CPI8072) RPY(Z)
This will let the system automatically reply with the value of 'Z' to msgid CPI8072. You can also use the CMPDTA parm if needed.
You say that it is a CLP, so place a MONMSG specifically for this error and disregard it.
The System reply will operate for all instances, and if a SNDNETSPLF is used elsewhere, you may need to know if it wants to tell you something. Best to future proof these things whenever possible
A reply-list entry shouldn't be a problem for most jobs since the INQMSGRPY(*SYSRPYL) job attribute is needed before a job will use the system reply list.
But it's not clear why a reply list entry has a relationship to the OP. There's no indication that it's an *INQ message. So far, it's just a message display.
Also, there's no reason to think MONMSG will help. I'd first guess that it's sent as only a *INFO message, so MONMSG won't see it at all.
It seems likely that a message queue monitor (temporarily?) attached to the user's *MSGQ could receive and remove the message if the message isn't wanted at all. Or perhaps the *MSGQ should simply be placed in *HOLD or *NOTIFY mode.
Regardless, without some detail from the OP, there's no good answer.
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
Discuss This Question: 3  Replies
But it's not clear why a reply list entry has a relationship to the OP. There's no indication that it's an *INQ message. So far, it's just a message display.
Also, there's no reason to think MONMSG will help. I'd first guess that it's sent as only a *INFO message, so MONMSG won't see it at all.
It seems likely that a message queue monitor (temporarily?) attached to the user's *MSGQ could receive and remove the message if the message isn't wanted at all. Or perhaps the *MSGQ should simply be placed in *HOLD or *NOTIFY mode.
Regardless, without some detail from the OP, there's no good answer.