Re: Work station message queue locked

Thanks for the reply...

On 28 Jan 2015 at 12:16, CRPence (CRPence <midrange-l@xxxxxxxxxxxx>) commented
about Re: Work station message queue locked:

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.

There was a reason I didn't setup DLVRY(*BREAK) on the user profile many years ago
back in the System38 days. I don't remember the reason.

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.

It is a CPF2450 message.
The from program is QMHCHMSQ.
The to program is STRATU (my signon program)
The Log level is LOG(4 0 *SECLVL)

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.

I see in the job log it is a message from the signon program.

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.

It does not relate to the WorkStation. The WorkStation names are totally different
than the user names. I have been using this signon program for many years and it has
been working great until now.

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.

All of my Job completion messages go to my user msgq. Not the Wrkstn msgq.
No matter where I am signed onto I want all my Job completion messages to break on
one Wrkstn.

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."

It is not.

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.?

It is not.

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.?

All Wrkstns are named different than user names.

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.

I noticed when I run:
DSPMSG MYUSER
It displays the msgq in Qsys
When I do a <shft> <esc> 4
It displays the msgq in Qusrsys
When I execute:
CHGMSGQ MSGQ(QUSRSYS/GARYT) DLVRY(*BREAK)
I don't get an error message and the Job completion messages break just fine.

I have not changed the library list on the system, jobd or my signon program.
The only thing I did do last weekend is run a RCLSTG which I have done in the past.
I have not changed the signon program in years.
The only thing I can guess is the msgq in qsys didn't exist before because the chgmsgq
is not qualified with library name.
I noticed on a V5R3 system I don't have the msgq in qsys.
I have no idea how it came to be there.
I will change the signon program to qualify the library name to fix the problem.

Thanks,

Gary

--
Regards, Chuck
--