MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

Re: Controlling Job Types



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact