RE: Disabling Qinter... (Follow up question)

Is the *DEVD being locked by QSYSARB??  My recollection (from CPF Vx and xPF
V3 and V4, which may not apply any more) is that unavailable devices get
locked by one or more *SBS when started (by QSYSARB).  When the device
becomes available it will be assigned to that *SBS.  More than one *SBS can
have a lock placed on a DEV, due to the way the WS-name and WS-type entries
are defined in each SBS, and these are (apparently and/or USED ta-be)
queued.  If you stop a SBS, another SBS's lock then gets bumped up in the
queue, so next time you try to signon you'll be assigned to the other SBS.

So, the order the subsystems are started is the key, afaik.  Again, that may
NOT be how it used to work but that's my recollection, and it Certainly may
not even apply any more as the OS sure Has Changed over the decades.

At any rate, I'm pretty sure the fix is to make the WSE mutually exclusive,
so that no more than one *SBSD Can allocate a given terminal ID.



| -----Original Message-----
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Michael Naughton

| We've done the same thing here, and occasionally I've run into a small
| problem. Normally, when I sign on I go to QINTER, which I assumed was
| because the other subsystem was named QXXISD , which is later in the
| alphabet. But sometimes I can't sign on with my regular workstation device
| name, and when I change the name and get on I discover that my regular
| device has been locked by some job in QXXISD, even though there appears to
| be nothing running in QXXISD. If I stop and restart QXXISD, everything is
| fine again. This doesn't happen every time, but it tends to average 2-3
| times a month.
|
| Does anyone have any ideas on what might be causing this, and whether
| there is a fix?