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?
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.