Re: Lock on msgq for UPS Power handling program

On 30 Aug 2013 12:19, rob@xxxxxxxxx wrote:

<<SNIP>>

23.00 ALCOBJ OBJ((&LIB/&MSGQ *MSGQ *EXCL))
24.00
25.00 A: RCVMSG MSGQ(&LIB/&MSGQ) WAIT(600) RMV(*YES) +
26.00 MSGID(&MSGID)

<<SNIP>> I do not think it can send a message to something with
an exclusive lock on it.<<SNIP>>

A message can be sent by any job to the MSGQ(&LIB/&MSGQ), even after the request on line-23 has executed. That is because the method to add a message to a queue does not depend on the ability of the sender to allocate the *MSGQ object; i.e. no request to allocate by the sender means that there is no conflict. The same lack of conflict is the case for a call method when a called program is allocated exclusively in another job.

The effect can be verified easily by use of SNDMSG [or SNDUSRMSG] issued within one job, to a named message queue (TOMSGQ) that was previously and remains locked exclusively in another job.

The lock on the message queue is simply an indicator in defining the implementation for the uninterruptible power supply handling feature. That feature tests if [to determine that] there is a user-implemented UPS handler, by testing if the *MSGQ object identified by the QUPSMSGQ system value is exclusively allocated; i.e. if that Msg Queue is not allocated, "the system will assume that no power handling program exists." But again, that lock held by the UPS handling program [effected either by ALCOBJ or CHGMSGQ] does not preclude the system [or anyone else] from sending a message to that queue.