× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 28-Jan-2015 12:08 -0600, Gary Kuznitz wrote:
On 28 Jan 2015 at 10:58, Gqcy wrote:
On 1/28/2015 10:36 AM, Gary Kuznitz wrote:
I have a signon program that includes a
chgmsgq msgq(MyUser) dlvry(*break)
<<SNIP>>

<<SNIP>>
does the msgq object exist in multiple libraries?

Yes it does exist in Qsys and Qusrsys.

Looking on a different machine I see my user msgq is only in
Qusrsys.

That *MSGQ MYUSER in QUSRSYS is presumably the User Message Queue.

I see there is no lock on the one in Qsys.

Workstation message queues allocated for DLVRY are not /locked/ in the typical sense; they will not appear in Work With Object Locks (WRKOBJLCK) when they are allocated merely for non-HOLD delivery mode. Those *MSGQ objects are implicitly created for the device [and like the device, also] in QSYS.

I see there is a lock on the one in Qusrsys.

For non-Hold delivery mode established for a non-workstation message queue, the lock is visible.

The lock is for Workstation Gary3

The visible lock is held to a job [and thread]; that the job is established on any particular workstation is not relevant. I presume the above comment means to suggest that the job *N/MYUSER/GARY3 holds a lock on the message queue object QUSRSYS/MYUSER?

The delivery on Workstation is currently in *Notify mode.

Which workstation name could be quite relevant here. However whether GARY3 or MYUSER is probably moot with regard to the error seen for the following request:

When I run this on Workstation Gary3:
"chgmsgq msgq(MyUser) dlvry(*break)"
I get the error:
Work station message queue MyUser not allocated to job.

I don't understand that.

As explained in my prior more long-winded reply, the msg CPF2450 effect is constant for that scenario whereby the WS Device Name of the job does not match the WS Device Message Queue name. One job can not /allocate/ the WS MSGQ of a WS to which that job is not currently signed-on; only the job that acquires that WS device can allocate the message queue of that device.

Like on the "different machine" where the same problem presumably does not transpire, one possible solution is Delete Device Description (DLTDEVD) of the MYUSER device for which there is an associated Device Message Queue in QSYS. Another [probably more appropriate] solution is to re-code the Initial program to library-qualify the User Message Queue name to avoid accidentally trying to allocate the Work Station Message Queue by the same name [and in a library list entry that appears higher than QUSRSYS in which the desired User MSGQ should be found]: chgmsgq msgq(QUSRSYS/MyUser) dlvry(*break)


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.