On 19-Feb-2014 09:08 -0800, Laine, Rogers wrote:
On 19-Feb-2014 07:25 -0800, Laine, Rogers wrote:
I'm running v6.1 and have some questions on how to control what
subsystem Batch and Interactive jobs are processed. What I'm trying
to accomplish is to control access to the system for all
application type users by stopping their subsystem(QINTER).
<<SNIP>>
Now if I changed QCTLSBSD to QCTL it will start the below
subsystems...
<<SNIP>>
So will my Interactive users now run under QINTER and the Batch
jobs run under QBATCH without changes the Job Description?
The Job Description for my application has Job Queue of QBATCH and
Routing Data of QCMDI. So the QBATCH tells the job what queue to
place it on, but the QCMDI tells it what type of job to use? So what
determines the subsystem to use?
With the *JOBD having JOBQ(QBATCH) RTGDTA(QCMDI), and those job
creation attributes not being overridden by whatever method was used to
start the job, then when the system Work Management creates the job, the
job is directed into the Job Queue named QBATCH. The routing data
merely directs what routing program should process the request messages
for that job. If no subsystem has allocated the job queue, the job can
not progress to the processing of the routing data; similarly if the
queue is allocated, but the job [as a queue entry] has not yet been
popped-off the queue by the WM [either because the *JOBQ is held or
there are other jobs prioritized ahead of that job within the queue].
So to be clear, the routing entry does not determine "what type of
job", with regard to the job being either of type=batch or
type=interactive. The type of job in that regard, is determined at job
creation, and is established by the _method_ used to create the job.
For example, a "batch" job typically is started via the Submit Job
(SBMJOB) command or another of the "SBM" mnemonic-prefixed commands. An
"interactive" job is normally created when the user provides credentials
at the signon display, after which the routing data from the job
description to be used [according to the attributes of the Workstation
Entry] is processed by the subsystem monitor job to decide which routing
program will process the requests messages from that newly created job.
An interactive job is one that is associated with a display device.
What determines where that job starts is the subsystem that was able to
allocate that device. In the default setup for which the system value
QCTLSBSD=QCTL, the interactive jobs will enter into either QINTER or
QCTL, because there is a workstation type entry in QINTER to allocate
*ALL devices and an entry for *CONS (console) to prevent that device
from being allocated and a workstation type entry in QCTL to allocate
the *CONS and an entry for *ALL to prevent those other devices from
being allocated. Various device [generic] names and types can be added
to direct the devices to a desired subsystem using the Add Workstation
Entry (ADDWSE) command.
One often conspicuous aspect of the interactive job, is that the
JOBQ() of the Job Description appears to play no role; i.e. although the
job description might have an attribute JOBQ(QBATCH), and Job Queue
QBATCH is allocated to the subsystem QBATCH, the job starts in an
interactive subsystem such as QINTER instead. Again, that is because
QINTER allocated the device, not because QCMDI was the routing data.
Thus the current *JOBD having JOBQ(QBATCH) will not prevent the jobs
from going to QINTER, and thus the Job Description for the User Profiles
need not be changed... if that was the implied concern when asking where
the interactive and batch jobs would run.
However there is nothing preventing a WSE being added, defined such
that a workstation would be allocated by the QBATCH subsystem; i.e. such
that interactive jobs could start in QBATCH. So while the default setup
using QCTL effects the fairly clear separation [inter, bch, comm, spl],
and the default setup for QBASE effects much more an amalgam, either
default setup can be reconfigured or tweaked only slightly to allow the
End Subsystem (ENDSBS) request end various grouped workloads; e.g.
ENDSBS QINTER to end all interactive jobs, except at the console. In
this manner, certain grouped interactive work can remain active while
others are ended; e.g. a set of users might be running a set of
applications within the WAREHOUSE subsystem, and another set of users
running a set of applications within the OFFICEUSER subsystem, allowing
their signon and interactive work to be shutdown separately if\when desired.
midrange.com
