On 28-Jan-2015 10:36 -0600, Gary Kuznitz wrote:
I have a signon program that includes a
chgmsgq msgq(MyUser) dlvry(*break)
In the past the first work station I would signon to I would get my
messages to break on.
That would often be accomplished instead with the User Profile
(USRPRF) being setup with the attributes MSGQ(usrMsgQ) DLVRY(*BREAK),
such that messages sent to the User Message Queue would break to the
first signed-on job; each job establishes the delivery effects for the
messages sent to that Device Message Queue.
Now all work stations I signon to I get a error saying:
"Work station message queue MyUser not allocated to job."
So we can infer that is likely the msg CPF2450 "Work station message
queue &1 not allocated to job." But without the context of the error,
we do not know what request failed with that message; the from-program
and to-program would be minimally of great importance, and the spooled
joblog [with LOG(4 0 *SECLVL)] would include that information.
Basically what needs to be established is if that error is a side
effect of the aforementioned Change Message Queue (CHGMSGQ) request
[thus context is T/InlPgm aka "sent to the Initial Program"], or is that
error a side effect of the OS establishing the Delivery (DLVRY) for the
Message Queue (MSGQ) of the User Profile (USRPRF) object.
If the MSGQ(MYUSER) actually names a WorkStation Message Queue, then
the aforementioned CHGMSGQ request is, AFaIK, unsupported at any device
other than the device named MYUSER; i.e. that CHGMSGQ request would be
expected to fail on every session except the one at device MYUSER. That
being so, the described effect seems quite normal and to be expected.
Including the first work station.
The WS message queue is specific to, and named the same as the Device
allocated for presentation of the signon display. The token MYUSER
would need to have changed for each of the separate\secondary WS being
signed on to; i.e. the value for the above &1 would need to be unique
for each separate workstation\device session.
Seems more likely that the condition being experienced would be with
the User Message Queue; and the [presumably obfuscated] value MYUSER is
the name of the UsrPrf object, perhaps also [or not] the device name, so
perhaps instead the error was?:
msg CPF2451 "Message queue &1 is allocated to another job."
Or perhaps the use of the obfuscated replacement value for &1 leads
the reader astray; the token MYUSER might instead best be described as
MYUSER# where each # represents effectively, a new session-number.?
If the CHGMSGQ request is failing on the same-named device as the
name specified on the MSGQ() parameter, then the effect at "the first
workstation" is suspect, *unless* the first workstation is perhaps no
longer the same name; e.g. perhaps MYUSER used to be the first session
device name, but now the first session is MYUSER1.?
I ran:
Wrkobjlck obj(MyUser) objtype(*msgq)
and it says there are no locks.
That is /normal/ for a Workstation Message Queue; while /allocated/
with regard to the /Delivery/ mode, there is no actual visible /lock/.
How can I fix my message queue?
If indeed the MSGQ object is a WS Message Queue, then vary-off and
delete the WS Device Description and let the device re-create. If the
Message Queue had previously been deleted (DLTMSGQ) and recreated with
Create Message Queue (CRTMSGQ) rather than via the Create Device Display
(CRTDEVDSP) [or the equivalent via auto-config], then the Technical
Description from the CPF2450 [found on v5r3] would be apropos:
"Work station message queues cannot be allocated. They are associated
with the device of the same name. To determine if there are locks on the
work station message queue, check the locks on the device description of
the same name by using the WRKOBJLCK command. A work station message
queue should not be deleted with the DLTMSGQ command. The work station
device description should be deleted and the work station message queue
will automatically be deleted. The message queue will be automatically
created when the device description is created again."
If instead the message queue is the user message queue [as an
attribute of the User Profile] then first I would issue Display Message
(DSPMSG) against the MSGQ name to see both the Delivery (DLVRY) and
Break Handling Program (PGM) attributes. If the delivery is other than
*HOLD or the program other than *DSPMSG, then I would attempt to use the
Change Message Queue (CHGMSGQ) to establish DLVRY(*HOLD) PGM(*DSPMSG)
and then additionally use the Change Job (CHGJOB) to establish Break
Message Handling (BRKMSG) to Hold as well. If the CHGMSGQ fails, that
may help diagnose the problem. Otherwise, after those two Change
requests, retry the starting of sessions\signons to test if anything
changed; perhaps the issue will no longer transpire.
midrange.com
