Put user job on hold
| Component: | BS2000 | 
| Functional area: | Job processing | 
| Domain: | JOB | 
| Privileges: | TSOS | 
| Routing code: | J | 
Function
This command places a user job that has not yet been started in the wait state HELD-BY-COMMAND. 
The specified job, identified by its TSN or a defined job variable, is skipped by the job scheduler when it selects the jobs to be started. This wait state can only be revoked by the RESUME-JOB command or by changing the start attributes to START=*IMMEDIATE (MODIFY-JOB command). Information on the jobs in wait state can be retrieved using the SHOW-JOB-STATUS command. In this case, the wait state HELD-BY-COMMAND is displayed as TYPE1/HO. 
Successful processing of the HOLD-JOB command is indicated at the console. The command is rejected in the following situations:
- The job scheduler has already released the job for starting; jobs which have already started can be placed in the wait state by means of the HOLD-TASK command. 
- The job to be placed in the wait state is an interactive or transaction job (category DIA or TP). 
- The job to be placed in the wait state has the START=*IMMEDIATE attribute. 
Format
| HOLD-JOB | ||||||||||||||||||||
| 
 | ||||||||||||||||||||
Operands
JOB-IDENTIFICATION =
The batch job can be identified by means of either its TSN or a defined monitoring job variable.
JOB-IDENTIFICATION = *TSN(...)
The job is identified by means of its TSN.
TSN = <alphanum-name 1..4>
TSN of the job to be placed in the wait state.
JOB-IDENTIFICATION = *MONJV(...)
The job to be suspended is addressed by means of a monitoring job variable.
MONJV = <filename 1..54 without-gen-vers>
Defined job variable for the job to be placed in the wait state.
JOB-IDENTIFICATION = <alphanum-name 1..4>
The job number of the job to be suspended.
Return codes
| (SC2) | SC1 | Maincode | Meaning | 
|---|---|---|---|
| 0 | CMD0001 | No error | |
| 1 | CMD0202 | Syntax error | |
| 32 | CMD0221 | system error | |
| 64 | JMS0630 | Semantic error | |
| 64 | JMS0640 | Command cannot be executed | 
Notes
Calendar and repeat jobs should not be placed in the wait state. If it is still unavoidable, note the following:
- In case of calendar jobs, the complete execution is put in the wait state. If further execution dates are reached while in the HOLD state, these will be omitted. 
- In the case of repeat jobs, the command only applies to the directly following repetition. 
- If the start time of the suspended repetition is reached, its successor will still be created. 
- The successor does not adopt the HOLD attribute. It will, however, only be started once the current job is terminated, that is only after the HOLD state is terminated via /RESUME-JOB or /CANCEL-JOB. 
- If the system is started anew, the whole repeat job is reconstructed from its successor. This may cause the HOLD state to be lost.