Re: Problem with a CL

On 13-Jan-2016 04:15 -0700, Don Brown wrote:

On 13-Jan-2016 04:07 -0700, Richard Reeve wrote:

I've been up too long and am not seeing the problem with this CL:

0013.00 INZTAP DEV(TAP01) NEWVOL(IBMIRD) CHECK(*NO)
0014.00 MONMSG MSGID(CPF6760 CPF6718) EXEC(SNDMSG +
0015.00 MSG('backup did not run') TOUSR(*SYSOPR))
0016.00 MONMSG MSGID(CPF6760 CPF6718) EXEC(GOTO EXIT)
0017.00 ENDSBS SBS(QINTER) OPTION(*IMMED)
0018.00 ENDSBS SBS(PRMSDATAQ) OPTION(*IMMED)
0019.00 /* SAVE LIBRARIES */
0020.00 /* DLYJOB DLY(600) */
0021.00 DLYJOB DLY(120)
0022.00 SAVLIB LIB(RMSGL11) DEV(TAP01) ENDOPT(*LEAVE) +
0023.00 SAVACT(*NO) OMITOBJ((*ALL *JRNRCV)) )

The issue is that the tape drive wasn't ready so a CPF6760 was
issued. (I verified in the log). Given that CPF6760 was issued (and
I also see the 'backup did not run' message, I expected to see the
program go to exit (which is ENDPGM). Unfortunately, that's not
what happened. The QINTER AND PRMSDATAQ were ended and we were
stuck. I had to do an IPL through the HMC to get things going
again.

My questions are;

1. Why didn't the program go to EXIT when the CPF6760 message was
issued
2. Could I have done something other than IPL? I know that if I
had my home PC running in QCTL that I could have recovered, but I
didn't. I'm not an HMC guy so any advice would be much
appreciated.

The second monmsg is monitoring the sndmsg command

What you need is ...

0013.00 INZTAP DEV(TAP01) NEWVOL(IBMIRD) CHECK(*NO)
0014.00 MONMSG MSGID(CPF6760 CPF6718) EXEC(DO)
0015.00 SNDMSG MSG('backup did not run') TOUSR(*SYSOPR))
0016.00 GOTO EXIT
0017.00 ENDDO

What is shown there is a valid means of correction to the original source; my preference would have been to coded a Send Program Message (SNDPGMMSG) to send a Message Type (MSGTYPE) of *ESCAPE to cause the CL program to terminate.

However, to clarify, the issue with the original CL source is *not* that the monitoring was active against the wrong statement. The OP shows there is no MONMSG coded as active for the SNDMSG.

The original CL shown, has duplicate command-level monitors coded, each active against the INZTAP statement request. However during the run-time, only the first of the most-specific of duplicate monitors will be activated as an EXEC() handler for that Monitor Message (MONMSG). That is because the control, per the lack of a GOTO, will have passed to the next /command/, not passed to the next /statement/; in this case, the next /command/ is the first ENDSBS, and the next control command-statement is MONMSG, but that monitor is [compiled into the program as] active only for the prior command: INZTAP.