z/OS MVS Using the Subsystem Interface
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Use information

z/OS MVS Using the Subsystem Interface
SA38-0679-00

To use the modify job SSI, a caller must select one action to take. Only one action can be specified per call, but the action can run on an unlimited number of selected jobs.

Next, the caller must decide which filters to use. A filter is an attribute that a job or SYSOUT must possess to be processed by the interface. Filters exist at the job or SYSOUT level, and are independent of the type of action being taken.

A typical filter has some value associated with it, such as JOBNAME with value of TOMW. However, some filters do not have values associated with them, such as filters for jobs that are held. If no filters are applied, the modify job function call is returned with an error. Because the number of jobs and SYSOUT in the system can be large, it is recommended that a filter be specified to limit the jobs that the action runs on.

When an application calls SSI 85, the SSI clears any output areas that are passed in to the SSI. SSI 85 considers it residual data and clears it to avoid any confusion with the jobs that are selected for the current request. Each SSI 85 call results in one set of output areas that must be processed before making another SSI 85 request.

For JES2 subsystems, jobs processed through this SSI can be obtained from a local copy of JES2's work queues. SSI 85 processes job or SYSOUT data to determine whether the job should be selected for the modify request. When JES2 gets the request to modify the job, the job might no longer be in a state where the modify request is allowed, in which case the request is rejected.

The modify job SSI can operate synchronously or asynchronously, as specified by the input processing option flag byte SSJMOPT1. Turn the SSJMPSYN bit ON to indicate that the SSI is to perform the requested job modify action synchronously. For a synchronous request, the job modify SSI does not return control to the caller until the job modify action has been processed for every selected job and results of the request are available to be returned to the caller. A synchronous request provides results of the job modify action for each job so the user can analyze which jobs were modified successfully and which ones were unable to be modified, with the reason why any job could not be modified.

If you do not require feedback on the results of the job modify action, you can use an asynchronous request. For an asynchronous request, the job modify SSI returns control to the caller once all selected jobs are queued to JES2. The caller does not get feedback on the results of the job modify action, but gets control back more quickly using an asynchronous request.

The modify job request does not provide a method to freeze the job status in the system. Other SAPI applications, JES writers, networking writers and operators can change the state of any job that has been selected or updated by the job modify request. The job status might allow the job to be selectable at the time of a job modify request, but by the time the action is performed, the job status might no longer allow the job to be modified. Likewise, after job properties are modified by a job modify request, they might be changed by some other process before the SSI caller processes the job feedback information from SSI 85.

The response to a modify job request includes an output feedback element (SSJF) for each job that is selected to be modified. The elements are chained together and are anchored by the SSJMSJF8/SSJMSJFP field in IAZSSJM(SSJM).

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014