In an MSCF network, users can distribute their batch jobs to any processor in the network provided that there is a MSCF connection between the two processors. The user can therefore use the resources of any processor in the network, especially those that are only available on certain processors. Job distribution is also useful to prevent overloading individual processors.
Jobs can be routed to any processor in the MSCF network with the ENTER-JOB and ENTER-PROCEDURE commands or started with the ENTER macro. The destination processor is always addressed via the HOST operand. If the HOST specification is missing, the job is executed locally. Resource requests from the job to be executed (e.g. for devices, files, catalogs) cannot be controlled by means of these commands.
Addressing the destination processor
The destination processor can be specified as follows via the HOST operand in the ENTER-JOB command:
HOST='<hostname>'
HOST=<jvname>
HOST='<&jvname>'
HOST=*CATALOG(IDENTIFICATION='<catid>'/<jvname>)
HOST=*ANY
If the destination processor is addressed directly via HOST='<hostname>', the job is passed straight to the destination processor where it is placed in the job queue. The destination processor can, however, also be addressed indirectly by depositing the host name in a JV. Under this method, the host name is taken from the JV either by the command server (i.e. by the routines that execute the ENTER-JOB command (HOST=<jvname>)) or by expression substitution (HOST='<&jvname>'), an SDF function which is available generally. Another indirect addressing option is to specify the catalog ID of a pubset that is imported on the destination processor (HOST=*CATALOG(IDENTIFICATION='<catid>')).
Indirect addressing generally offers greater flexibility in the formulation of procedures, as illustrated by the following example:
As agreed with the users, the computer centers that belong to an MSCF network define the names and meanings of certain JVs. Each of these JVs represents a group of resources (e.g. devices, files, jobs) which are assigned to one or more processors in the MSCF network. When a group of resources is then assigned to a specific processor, the value of the JV is set to the assigned processor/catalog name. As a result, jobs which contain the name of that JV in the HOST operand are passed to the relevant processor.
While direct addressing links a job statically to a processor or catalog, indirect addressing permits dynamic job linking to a number of processors/catalogs without changing the original job control statements. Both locally and non-locally imported catalogs can be specified in indirect addressing using a catalog ID. The job is executed on the processor on which the specified catalog was imported when the ENTER-JOB command was input. If the catalog is on a shared pubset (see page 31 (Shared pubset network)) that is accessible from both a local and a remote processor, the job is processed on the local processor.
This type of processor addressing is very convenient for users because they do not need to know which processor in the MSCF network has the specified catalog on it or what the processor’s host name is. Not only that, but this method of addressing the destination processor has the advantage that catalogs can be exported and imported between the individual systems in an MSCF network.
This variant of destination processor addressing can also be applied independently of whether an MSCF network exists or not (because the pubsets are imported locally). Conversion to the MSCF network is possible without having to modify commands.
Notes
The destination processor is defined at the time of acceptance. There can, however, be a considerable lapse of time between the acceptance of a batch job and its execution (e.g. due to a set-deadline job, overload situation etc.). It should be remembered that once a batch job is accepted, it must run on the selected destination processor, a fact that cannot even be influenced by indirect destination processor addressing using a catalog ID. The reconfiguration of a catalog (i.e. export from the selected destination processor, import to another processor in the network) between acceptance and execution does not automatically have the effect that the batch job will run on the new destination processor.
The only exception is a situation where the home pubset of the original destination processor was given the name of the catalog ID and a startup is carried out for the new destination processor with this home pubset.The ENTER-PROCEDURE command does not offer all the options of the HOST operand that the ENTER-JOB permits. This does not mean, however, that the functionality is restricted because generally indirect addressing is possible using the expression substitution (<&jvname>).
Example of indirect addressing via catalog ID
PROCESSOR1, PROCESSOR2 and PROCESSOR3 form an MSCF network in which each processor is connected with the others:
|
|
|
The following commands for job distribution are now input on PROCESOR1:
/ENTER-JOB FROM-FILE=job1,HOST=C'PROCESSOR2' —————————————————————————— (1) /ENTER-JOB FROM-FILE=job2,HOST=*CATALOG(IDENTIFICATION=C'D') —————————— (2) /ENTER-JOB FROM-FILE=job3,HOST=*CATALOG(IDENTIFICATION=C'A') —————————— (3)
(1) | 'job1' is executed on PROCESSOR2. |
(2) | 'job2' is executed on PROCESSOR3 because it manages catalog D. In the MRSCAT of PROCESSOR1, there must be an entry for 'D' with reference toPROCESSOR3. |
(3) | 'job3' is executed on the local processor (PROCESSOR1). |
Catalog D is then transported from PROCESSOR3 to PROCESSOR2 (systems support for PROCESSOR3 specifies the command EXPORT-PUBSET PUBSET=D and systems support of PROCESSOR2 specifies the command IMPORT-PUBSET PUBSET=D).
In an existing MSCF connection the EXPORT-/IMPORT-PUBSET commands ensure that PROCESSOR1 carries out the relevant status change
(ACC, PROCESSOR3 to INACC, PROCESSOR3 and ACC, PROCESSOR2).
If the user then enters command (2) on PROCESSOR1 and 'job2' is executed on PROCESSOR2. Although the catalog is now on a different processor from before (see figure below), the user does not have to change his job control commands.
|
|
|
Example of indirect addressing via catalog ID and JV
JOB-A, JOB-B, JOB-C and JOB-D are to be distributed to certain processors in an MSCF network:
JOB-A is to run on PROCESSOR1.
JOB-B is to run on the processor that manages catalog B.
JOB-C is to run on the processor to which the laser printer is connected via a canal switch. The processor concerned in our example is identified via the 'LASERPRINTER' job variable (systems support must make sure that this job variable contains the name of the processor to which the laser printer is currently connected).
JOB-D is to run on the processor that manages the catalog with the file 'UDS.DATA'. The catalog concerned in our example is identified via the job variable 'UDSDTA' (systems support must make sure that this job variable includes the ID of the catalog that contains the 'UDS.DATA' file).
Figure 9: Job management
The jobs are started with the following commands:
/ENTER-JOB FROM-FILE=JOB-A,HOST=C'PROCESSOR1' /ENTER-JOB FROM-FILE=JOB-B,HOST=*CATALOG(IDENTIFICATION=C'B') /ENTER-JOB FROM-FILE=JOB-C,HOST=:C:LASERPRINTER /ENTER-JOB FROM-FILE=JOB-D,HOST=*CATALOG(IDENTIFICATION=:C:UDSDTA)
JOB-A is passed to PROCESSOR1 and JOB-B to PROCESSOR2 (PROCESSOR2 manages catalog B). The specification of the destination systems for JOB-A and JOB-B is static.
The routing of JOB-C and JOB-D depends on the values of job variables LASERPRINTER and UDSDTA. JOB-C is passed to PROCESSOR2 and JOB-D to PROCESSOR1. By simply changing the value in the job variables, the jobs can be flexibly routed in the MSCF network as appropriate to the load and resource situation. The destination systems for JOB-C and JOB-D are specified dynamically.