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

[Wayne McAlpine <wmcalpine@xxxxxxxxxxxxxxxxx>]

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.