The workstation entries in each interactive subsystem determine how workstations are allocated. Do a DSPSBSD and look at both the workstation name entries and the workstation type entries. The default in QINTER is to allocate *ALL in the workstation types. If you always want particular workstations to run in a certain subsystem, come up with a naming convention that allows you to specify a mutually exclusive generic name for the workstations. For example, $* for QINTER and #* for your other interactive subsystem. Both of your subsystems currently have workstation name or type entries that are not mutually exclusive, so they are both attempting to allocate the workstations. The first subsystem to start would allocate the workstation, but if it ends, the other subsystem will grab the workstation and hold it even if the first subsystem is restarted.

Michael Naughton wrote:

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?

TIA,

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> writes:

We made a separate subsystem for the IT department. Our WSID's are
assigned
there. Each night before our backup runs, QINTER is ended by the IBM job
scheduler. The last job on our nightly processing queue is to start
QINTER.
This keeps users off the system until everything completes sucessfully. If
we are planning an upgrade over the weekend, we simply remove the startup
job from the queue. We can dial or VPN and we still have our subsystem up
and running. HTH,
Cyndi B.



Mike Naughton Senior Programmer/Analyst Judd Wire, Inc. 124 Turnpike Road Turners Falls, MA 01376 413-863-4357 x444 mnaughton@xxxxxxxxxxxx

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.