Re: Debug

Instead of coding a DLYJOB, I [would recommend to] use a CALL to a program which has the sole purpose of waiting for me to reply to an inquiry. Seems to me, easier to look for my job in MSGW status or find the inquiry [e.g. in QSYSOPR] awaiting my reply. For example:

<code>
Pgm Parm()
Dcl &MK *char 04 VALUE(' ')
Dcl &MR *char 10 VALUE(' ')
Dcl &Continue *char 10 Value('SECRET_RPY')
SuspendJ: /* Suspend job w/ inquiry msg */
sndpgmmsg msgid(CPF9898) msgf(QCPFMSG) keyvar(&MK) tomsgq(*SYSOPR) +
msgdta('Request to hold job by inquiry is made. Do not +
provide a reply value for this message') +
msgtype(*inq) rpymsgq(*pgmq)
rcvmsg pgmq(*same *) msgtype(*rpy) msgkey(&MK) +
msgq(*pgmq) wait(*max) rmv(*no) msg(&mr)
VfyReply: /* Loop until rcv valid reply */
if cond(%sst(&mr 1 2) *eq '*N') then(dlyjob 90) /* *DFT handling? */
if cond(&mr *eq &Continue) then(goto EndSuspend)
dlyjob 30 /* 90+30=120 for *N replies */
goto SuspendJ
EndSuspend:
Return
EndPgm
</code>

That code does not attempt to /resolve/ QSYSOPR being in *DFT handling nor if the job has INQMSGRPY(*DFT) to prevent the *N, nor in some weird case if the job has Inquiry Message Reply handling of *SYSRPYL handling where the CPF9898 had some bogus reply established. That is, in each case it would just drop into a wait, to avoid a /fast-loop/ on re-inquiring in response to some auto-reply. It makes the *N reply a special case; it occurs also for the message being deleted by F11 or F13 from DSPMSG.

Regards, Chuck