Re: receiving message from QSYSOPR msgq

Arco Simonse wrote:

First I have to say that I am not well experienced with the way the i's messaging system works. But digging around did not shine
the light to me.

I have arranged some CL code for a batch job to bring the system to restricted state and do a SAVSYS. All working well, I can intercept the message which tells that the system has reached
restricted state, and continue to the save procedure.

This code works:

ENDSBS SBS(*ALL) +
OPTION(*IMMED) +
BCHTIMLMT(120)
WAIT:
RCVMSG MSGQ(QSYSOPR) +
MSGTYPE(*INFO) +
RMV(*NO) +
MSGID(&MSGID)
IF COND(&MSGID *NE 'CPF0968') +
THEN(DO)
DLYJOB DLY(20)
GOTO CMDLBL(WAIT)
ENDDO
/* And the SAVSYS goes on*/

But before the ENDSBS I need to send an other message to the MSGQ
of QSYSOPR. When I thus invoke for example:

SNDUSRMSG MSG(&MYMSG) +
MSGTYPE(*INFO) +
TOMSGQ(*SYSOPR)

And then the routine is no longer functioning. The WAIT loop then
keeps running until the BCHTIMLMT has expired. So it seems to be
caused by my sending of that before message to the MSGQ of QSYSOPR. But I don't understand why, and also cannot find a good solution for it.

This is driving me nuts. I must be doing something wrong, but what?

The claim that the original code /works/ is tenuous. That any informational message sent to the message queue prior to the CPF0968 will cause the code to fail, is sufficient proof that the original code could easily fail; any job could send\have sent such a message. Although RMV(*YES) might assist, the code might still wait uselessly in the delay-job, and any such informational messages causing the wait would go missing; albeit a copy remaining in QHST.

However, if a delay loop is acceptable, why not just ask the system if it is in /restricted state/ using the Retrieve System Status (QWCRSSTS) API, rather than trying to find out when the system informed of that?

For RCVMSG, consider: receive the *FIRST or *LAST, and then loop through the *NEXT or *PRV.

Another alternative is to establish a break handling program.

FWiW I seem to recall I had long ago, before [I knew] the API was available, coded a short-delay loop on the ENDSBS request to detect restricted state; i.e. messaging returned by the end subsystem request would change when complete. Of course I had a dedicated system to test. Eventually I had changed the code to have the loop start only after a ALCOBJ ((Qxxx *SBSD *EXCL)) WAIT(600) completed with success; where Qxxx was a subsystem that historically was the last subsystem to end on my systems.

Regards, Chuck