The only thing that happens is that the message queue isn't created. The
problem was found by batch jobs that tried to return a message to the
submitting workstation msgq. The error (forgot the MSGID) is that the
workstation had no attached message queue. I looked for the message queue
and it simply isn't there. There are no telnet exit programs (already
looked for that before I asked the question ;) ). I checked the history
logs, audit journal, etc. and no clues there. I ordered the v7.1 PTF just
now and should have it applied today. I've scheduled downtime tomorrow to
remove all workstation devices & the associated message queues. Hopefully
that will rectify the situation. I have (after much digging and posting
on forums) found out that it's possible that the message queues by those
names may have existed on the system but the workstation devd did not and
that the devd might not have been "associated" with that message queue and
it could not be created. We do not revoke authority to the devices so the
RVKOBJAUT should not have been a factor.
Thanks,
Tommy Holden
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 03/31/2011 10:57 PM
Subject: Re: workstation message queue issues
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Has the service provider already helped any or replied with anything
that might clarify.? If not already reported, that might be a good
approach. Regardless, I offer also...
Does "crapped out" have a symptom, perhaps a message that gets
issued, a message that could be searched for a known defect? Does the
device get allocated but the user can not signon, or perhaps no sign-on
screen is presented and some other symptom transpires which might be
described as a hang, wait, loop, or other? Is there a TELNET exit
program that might be involved for device selection? I do not recall,
but I think the auto-config work occurs in the interactive subsystem for
the display device, so review that subsystem monitor job for any
messages as well as the history log, problem log, and audit log.
FWiW there is a v6r1 PTF that was issued for a loop while processing
a *MSGQ object for authority [for which many T-AF entries are logged];
i.e. while processing a request to revoke authority [RVKOBJAUT].
v6r1: R610 SI41165 1000
v7r1: R710 SI41166 1000
Regards, Chuck
On 3/30/11 8:39 AM, Tommy.Holden wrote:
All of the DEVD are 3179 devices and the ones that crapped out this
morning were created in the last 10 days. It's sporadic which is the
real pain. It creates the MSGQ most of the time but ever so often I
get this problem.
Jack Kingsley on 03/30/2011 09:50 AM wrote:
how do the dates on the objects look when they are created, maybe
these are real old objects that don't like the new OS (or) maybe
the device types are different, example 3179 VS 3477 etc.
On Wed, Mar 30, 2011 at 10:30 AM, Tommy.Holden wrote:
I can't for the life of me figure this out. We have auto-create
devices turned on, sometimes when a new virtual workstation
device is created the associated MSGQ is created, sometimes it
isn't. I haven't found anything that could be causing this. Has
anyone else seen this behavior? It happened on v6.1 & on v7.1 of
the OS... we aren't using iASPs so I can rule out anything
regarding that aspect.
midrange.com
