The HOST operand of the ENTER-JOB and ENTER-PROCEDURE commands includes the value HOST=*ANY. Its meaning is described below. For a description of the complete commands, see the "Commands" manual [10 (Related publications)].
Operands
HOST=*ANY
Defines that the job can run on any processor in the XCS network. The job is transferred for processing by the distributor component of the JMS to the processor that has the lowest batch load.
Notes
The operand HOST=*ANY causes the JMS itself to define a destination processor in the XCS network of the job submitter. The selection criterion on which the selection of the job processing processor is based is the batch load of the processors in the XCS network, i.e. the job processing is handed to the processor that has the lowest batch. In this context, the following should be noted:
The processor’s load is in each case determined on the basis of the job class assignment during the job acceptance phase, i.e. the JMS determines the destination processor of a job by comparing the load at the time the job is started.
The job classes are categorized by the amount of system resources they will take up (CPU use, run priority etc.) by means of the job classes of the JMS (see the "Introduction to System Administration" [5 (Related publications)]). The number of active, i.e. simultaneously running, jobs of a job class is restricted by the CLASS-LIMIT attribute. If more jobs of a job class than are permitted by CLASS-LIMIT are sent to the system for processing, the jobs are accepted by the JMS but they are not active and lay no claim to resources. Scheduling, repeat and calendar jobs are also as a rule not active at first because they have not yet reached their start time.In order to determine the destination processor, the job processor (i.e. the processor of the MSCF network which first received the job for acceptance, e.g. from the ENTER-JOB command) sends requests to all the processors in the XCS network with information about the upcoming batch job. A "pre-validation" is carried out on all the processors reached in the XCS network (including the job processor itself). This involves determining the basic acceptability of the job on each processor (the job would not be accepted, for instance, if its job class is not defined on the potential destination processor).
As a result of the pre-validation, the job processor receives responses containing the following information:acceptable/not acceptable
indicators of system overload, category overload
(when this overload situation occurs, JMS does not start any more jobs even if job class assignments would allow it)job class counter and job class status
number of non-active jobs of the job class
From this returned information, the job processor determines the processor with the greatest remaining acceptance capacity from the matrix of possible destination processors whose pre-validation confirmed the basic acceptability. The JMS selects the destination processor according to the following priorities:
Stream/job class status (if, for instance, the stream in question is not active on a processor or the job class in question has been put on hold on the destination processor by the HOLD-JOB-CLASS command or its CLASS-LIMIT is temporarily 0, the job cannot be started on that processor immediately after acceptance)
Processor load (system/category overload)
Job class assignment (CLASS-LIMIT minus the jobs currently active in the job class)
Job class optimum (value for CLASS-OPTIMUM minus the jobs currently active in the job class)
In other words, first the loads involving active jobs (i.e. jobs in progress) are compared as at the time of the job acceptance on the individual processors in the network. Under normal operation (i.e. no overload, streams and job classes active on all the processors, CLASS-OPTIMUM=0), the processor with the highest value for CLASS-LIMIT minus the jobs currently in the job class has the highest acceptance capacity. If the job classes are assigned on all the available processors in the network, the values for CLASS-LIMIT minus the total number of accepted jobs of the relevant job class on the processors becomes negative but the comparison, even in this case, still pinpoints the potentially least loaded processor in the network. If a processor indicates that the job cannot be started due to the current setting (e.g. stream not active, job class in HOLD state) or due to system/category overload, it ceases to be a possible destination processor, even
if it has a lower batch load according to the job class counter. If all of the above criteria prevent a destination processor from being decided on, the job remains on the job processor.
The job class optimum is another parameter with which in some cases the batch job distribution in the XCS network can be controlled/improved. The job class optimum is a number (see CLASS-OPTIMUM operand of the MODIFY-JOB-CLASS command) lower than the maximum number of possible active jobs in a job class (see CLASS-OPTIMUM operand of the DEFINE- and MODIFY-JOB-CLASS commands). It is used to define the optimum assignment of a job class by systems support. Usually this is an empirical value which can only be defined based on the individual situation (e.g. due to the best observed throughput of batch jobs in an application). If CLASS-OPTIMUM is not 0, the distributor component of the JMS first considers all the processors on which the CLASS-OPTIMUM has not yet been reached in the job class concerned. If several processor are available, the one with the highest value for CLASS-OPTIMUM minus the jobs currently in the job class is preferred.
Once the destination processor has been decided on, the job is sent to that processor (in the same way as under the existing function in which a destination processor is explicitly determined by the user with the HOST operand of the ENTER-JOB command). The job then runs through the acceptance phase on that processor and the result is returned to the job submitter (message JPM0500 and other messages, usually JMS0066). The accepted job on the destination processor is transferred to the job scheduler there which releases it for start. Once a job has been accepted on a processor, it stays there.
The result of the pre-validation does not always have to agree with the final acceptance. This applies when JMS settings on the destination processor are modified by systems support between pre-validation and acceptance on the destination processor. CLASS-LIMIT may in the interim, for example, have been set to 0. Such interventions by systems support are not prevented by the JMS (no global lock on JMS data in the XCS network). In situations like this, the JMS attempts to find another processor in the network (after receiving the information from the destination processor as a result of the pre-validation that the job is not accepted).If no processor can be found in the entire network that can accept the job, the reasons are sent in messages from each processor to the job processor (see message JDS0322).
Default response: if no specification is made for the following job attributes in the ENTER-JOB command, the default response is as follows:
PROCESSING-ADMISSION (default value = *SAME):
User ID of the batch job to be generated is the user ID of the job submitter task on the job processor. The attributes of the user ID of the same name of the destination processor are decisive for the authorization checks.JOB-CLASS (default value = *STD):
Job class of the batch jobs to be generated is the default batch job class of the user ID on the destination processor.Job attributes whose default values are taken from the job class; the default value of the job class definition of the destination processor applies.
Specifying the value *ANY in the HOST operand is pointless for scheduling, calendar and repeat jobs, but is not prevented by the JMS. At the time of acceptance when the distribution is made, the JMS cannot forecast the load for scheduling jobs at the time the job is initiated. Although repeat jobs are generated with a new TSN for each type, they still remain on the processor that has been selected. Calendar jobs have only one TSN and must therefore remain on the processor that has been selected. If these jobs are transferred to the system under specification of HOST=*ANY, they are distributed as described above. The JMS makes no plans about the expected loads; here too it determines the acceptance capacity of a processor based on the differences between optimum and actual jobs as described above.
The same applies by analogy to all other jobs that cannot start immediately after acceptance (e.g. CLASS-LIMIT=0, job class or job stream in HOLD status or job stream not started). If, for instance, jobs are transferred during the day to the stream that is to be active during the night, the JMS decides on the distribution on the basis of the available job figures at the time of acceptance. It is up to the user to decide whether the response he requires is feasible.
Restriction:
If a task with the OPERATOR privilege is the job submitter of a batch job, the SET-LOGON-PARAMETERS command in the Enter command file is not evaluated if HOST=*ANY is specified.Recommendations for system settings (JMS parameters, user attributes):We recommend assigning the same JMS parameters (job class definition, default job classes), user attributes and contingents on all participants of the XCS network. The JMS carries out the checks described above (pre-validation) so that the executability of the batch job on the selected processor is guaranteed, but the uniform assignment is not compulsory. Inconsistencies which only become apparent at the runtime of the batch jobs will therefore not be revealed here (e.g. different syntax files, different privilege assignment etc.). If the assignment of uniform system settings is deviated from, this should be done consciously for a specific effect. If, for example, CLASS-LIMITs are differently assigned on the processors for the same job class, this has the effect that processors with the larger value are given priority, even if the number of jobs that such a processor has already accepted in the corresponding job class is greater than that on other processors.