This topic provides information about the JECL syntax convention.

/*AFTER

Request to run after a named job

This statement allows you to indicate that a job is to run after a particular job. Note that the job in question must be in the system at the time the determination is made. If the named job is not in the system, it is assumed that it has already run.

This statement is intended to ease the conversion for those installations that used the Mellon modifications. If your installation did not use these mods, code the /*JCS AFTER statement.

Represents the name of the job that must run prior to this job. If a job with that name is not found, it is assumed that it has run.

Note that the scope of the AFTER applies only to jobs with the same Batch Name. The Batch Name could have been given either with a /*JCS BATCH statement or in JAL.

Allows you to be specific about a job. This is only applicable in situations where the named job has already been submitted, therefore you know its JES2 number.

The JES2 job ID. See also: JECL Syntax Conventions /*JCS AFTER and JECL Syntax Conventions /*JCS BATCH.

Notes:

You can have multiple AFTER statements in a job. They must all be satisfied before the job is selected for execution.

For a job to be able to use this statement, it must be associated with a Batch Name. This can be done automatically in JAL, or the job submitter can do it with a /*JCS BATCH statement.

Do not include this statement in a job that uses the SEQ keyword of the /*JCS BATCH statement. Doing so requests conflicting processing sequences with unpredictable results.

/*BEFORE

Request to run before a named job

This statement allows you to indicate that a job is to run before a particular job. That is, if the named job is in the system, it is held until the job with the BEFORE statement completes execution. If no job is found, no action is taken.

This statement is intended to ease the conversion for those installations that used the Mellon modifications. If your installation did not use these mods, code the /*JCS BEFORE statement.

Represents the name of the job that is to be held until this job runs. If a job with that name is not found, no action is taken.

Note that the scope of the BEFORE applies only to jobs with the same Batch Name. The Batch Name could have been given either with a /*JCS BATCH statement or in JAL.

Allows you to be specific about a job. This is only applicable in situations where the job you want to execute before has already been submitted, therefore you know its JES2 number.

The JES2 job ID.

See also: JECL Syntax Conventions /*JCS BATCH and JECL Syntax Conventions /*JCS BEFORE.

Notes:

You can have multiple BEFORE statements in a job. All the named jobs that are found in the system are held until this job completes execution.

For a job to be able to use this statement, it must be associated with a Batch Name. This can be done automatically in JAL, or the job submitter can do it with a /*JCS BATCH statement.

Do not include this statement in a job that uses the SEQ keyword of the /*JCS BATCH statement. Doing so requests conflicting processing sequences with unpredictable results.

/*CNTL

Allows you to serialize jobs

This JECL statement allows you to serialize jobs. This mechanism is analogous to the standard MVS facilities for data set SHR versus OLD.

This statement is intended to ease the conversion for those installations that used the Mellon modifications. If your installation did not use these mods, code the /*JLS ENQ statement.

Represents a valid resource.

Self-explanatory. It is the default value. This keyword is mutually exclusive with EXCLUSIVE.

Must be the only job running. This keyword is mutually exclusive with SHARED.

See also: JECL Syntax Conventions /*JLS ENQ.

Notes:

An aggregate total of 24 statements of the following types can be included per job:

• /*CNTL
• /*JLS ENQ
• /*JLS LIMIT

All of them must be satisfied before the job is allowed to execute.

/*DAL TRACE

Activate DAL tracing

This statement is used to activate DAL tracing for a job. Output is sent to the JOBLOG data set.

Is one or more of the following DAL types, delimited by commas:

DCS
SOS
TM

If you do not specify any operands, all invocations of DAL for all steps in the job are traced.

Specifies that tracing is limited to a specific step.

Represents the step number to trace, relative to the start of the job and beginning at step 1.

Specifies that tracing is limited to a specific step.

Is the 1-8 character name of the step to trace.

Is the optional 1-8 character name of the procedure containing the requesting step.

Examples:

This requests tracing for all DCS and RSS activity for the entire job.

This requests tracing for SOS activity for step 3 only.

Notes:

Tracing is activated only for the job containing the statement.

/*DBS RESERVE

DBS ONLY

Reserve DBS-managed Devices

This statement specifies the Drive Pool and number of devices requested through dynamic allocation.

For STCs, you can also specify devices requested through static allocation. Although this is not mandatory it is recommended, since STCs do not go through Job Analysis and would otherwise be treated as poachers.

Requests that devices be reserved in the specified DBS Drive Pool.

Is one of the DBS Drive Pools defined in the ACTIVE Configuration. See the Notes below for a description of how you can obtain a list of the defined Drive Pools.

You can use an asterisk (*) wildcard character after any ‘->’ separator to group together the modes, device types, or models for a particular Drive Pool.

Is a number from 0-255, representing the highwater mark for dynamically allocated devices that will be requested. If this is the only count specified, the parentheses can be omitted.

Is a number from 1-255, representing the highwater mark for statically allocated devices that will be requested. This count applies only to STCs, and is ignored for batch jobs.

Specifies the step in which the dynamically allocated drives will be requested. If this keyword is omitted, the reserve request applies to the first step in the job or started task.

Is the 1-8 character name of the step that will request the dynamic allocation.

Is the optional 1-8 character name of the procedure containing the requesting step.

If multiple //*+DBS RESERVE statements for the same Device Pool are included in the same step, the last one encountered takes effect.

Multiple //*+DBS RESERVE statements for different Device Pools in the same step are cumulative. A request to reserve two devices with one statement and two devices with another results in reserving a total of four devices.

Examples:

To inform DBS that the job needs two dynamically allocated IBM automated 3490E devices in STEP2:

To inform DBS that an STC needs one statically allocated 3480 device:

The asterisk (*) wildcard can be used after any ‘->’ separator in the Drive Pool name. It groups together all modes, device types, and models that follow. For example, to request any IBM tape device:

To request any automated IBM tape device:

To request any IBM automated tape device in the library ATLDS1:

/*DBS SET

DBS ONLY

Specify DBS Work Group and Priority

This statement indicates the DBS requirements for the job or started task. For STCs, it also serves to identify that DBS is managing the STC.

Indicates that you want to assign the job or STC to a specific DBS Work Group. This name must be one of the six subgroup names specified in the current DBS Policy.

WG is the short form for this keyword.

Identifies a subgroup of a Work Group.

Indicates that you want to set the DBS Priority for the job or STC. When drive contention occurs, DBS Priority is used to determine which job gets the device.

The DBS Priority does not apply if the job is managed by SLM.

PR is the short form for this keyword.

Set a low priority.

Set a medium priority. This is the default.

Set a high priority.

If the job or STC contains multiple //*+DBS SET statements, the last one encountered takes effect.

If the specified Work Group is not defined, the keyword is ignored. The default Work Group is assigned.

If jobs in different DBS Work Groups are assigned the same DBS Priority, jobs in the lower numbered Work Group (as shown in the DBS Configuration dialog) are selected first.

/*DCS ALERT

ALERT Request Statement

This JECL statement allows you to request an ALERT bulletin for the job. The time interval and the destination for the ALERT can also be specified.

A JECL ALERT request overrides a JAL ALERT request.

This keyword indicates that you want to specify the time interval that is to elapse before the ALERT is generated.

This keyword is optional. If you do not code it, the default value is the one coded in the TMSS initialization statement DCS SET for the keyword ALERTTIME. If no ALERTTIME was coded, the default is 10 minutes.

A value from 0 to 999 indicating the number of minutes that are to elapse before an ALERT is generated.

If you code a value of 0, the ALERT is generated immediately.

This keyword indicates that you want to specify the name of a destination for the ALERT.

This keyword is optional. If you do not code it, the default value is the one coded in the TMSS initialization statement DCS SET for the keyword ALERTDEST. If no ALERTDEST was coded, the default is DCSALERT.

A string of 1 to 8 alphabetic, national, or numeric characters.

Examples:

This example shows a JECL request for an ALERT to be produced after 20 minutes have elapsed from the first occurrence of a data set contention. The ALERT is to be sent to a destination served by a Writer with PRODCONT assigned as its destination.

See also: /*DCS ALERTFn and JECL Syntax Conventions /*DCS ALERTHn.

You can test the DAL/JAL logic Descriptor $DCJECL to determine whether a JECL ALERT statement is present in the job. This allows you to control the use of this JECL statement.

To print an ALERT Bulletin, you must assign a destination to be used by CPS or SPS.

/*DCS ALERTFn

Provide Footer Text for an ALERT

This facility allows you to provide text for an ALERT footer. Two footers can be provided. They are represented by ALERTF1 and ALERTF2. These statements are normally associated with a DCS ALERT statement. If one is not provided then they are ignored and a warning message is generated.

Represents a character string from 1 to 61 characters long that is printed as an ALERT footer.

Examples:

The above two lines of text are printed as footers if an ALERT is generated for the job.

See also: /*DCS ALERT and JECL Syntax Conventions /*DCS ALERTHn.

*DCS ALERTHn

Provide Header Text for an ALERT

This facility allows you to provide text for an ALERT header. Two headers can be provided. They are represented by ALERTH1 and ALERTH2. These statements are normally associated with a DCS ALERT statement. If one is not provided then the statements are ignored and a warning message is generated.

Represents a character string from 1 to 61 characters long that is printed as an ALERT header.

Examples:

The above two lines of text are printed as headers if an ALERT is generated for the job.

See also: /*DCS ALERT.

/*DCS FORDSN

Identify Dataset Statement

This statement allows you to identify a data set (or group of data sets) to be associated with a DCS SERVICE statement, a DCS REPO statement, or a DCS NAG statement. The linkage is done with a numerical identification.

A data set name or data set name pattern to identify the particular data set or group of data sets that you want to associate with one of the following JECL statements:

• DCS SERVICE
• DCS NAG
• DCS REPO

For valid data set name patterns, refer to Dataset Contention Services: System Programming Guide in the chapter “Dataset Name Pattern Matching Rules.”

NID

Indicates that the data set is to be associated with a DCS NAG statement.

A two digit identification value used to link this statement with a DCS NAG statement. The same value is coded in the related DCS NAG statement.

Indicates that the data set is to be associated with a DCS REPO statement.

A two digit identification value used to link this statement with a DCS REPO statement. The same value is coded in the related DCS REPO statement.

Indicates that the data set is to be associated with a DCS SERVICE statement.

A two digit identification value used to link this statement with a DCS SERVICE statement. The same value is coded in the related DCS SERVICE statement.

Examples:

This example shows the link, via the SID, of a FORDSN and a SERVICE statement. The data set name pattern covers any data set with the first two qualifiers equal to AP9005.PAYROLL.

See also: JECL Syntax Conventions /*DCS NAG, JECL Syntax Conventions /*DCS REPO, and JECL Syntax Conventions /*DCS SERVICE.

/*DCS NAG

Nagging Request Statement

This JECL statement allows you to request that the standard nagging provided by DCS be modified. You can alter part of the standard nagging text (the second line), the time interval between nags,   and the number of times a user, or group of users, are nagged. You can also request that nagging be suppressed.

A JECL nagging request overrides DAL/JAL nagging requests.

Indicates that this NAG request statement is associated with a DCS FORDSN statement. The FORDSN statement has a NID coded with the same ‘nn’ value.

This parameter is mutually exclusive with the JOB keyword.

More than one DCS NAG statement with the same NID number can be specified.

Indicates that this NAG request statement is associated with all the data sets in the job.

This keyword is the default, and is mutually exclusive with the ‘nn’ parameter.

This keyword is mandatory. It specifies which TSO users are to be nagged. If you want all users to be nagged then you code ‘*’.

A 1 to 7 character userid pattern. You can specify from 1 to 5 patterns in one statement.

If you need more than 5 patterns, you can code an additional DCS NAG statement with the same NID value.

The pattern matching rules are as follows:

• 
  
  • If a list of patterns is provided the matching analysis always proceeds from left to right.
  • If more than one DCS NAG statement is present with the same id value, the matching analysis handles the statements in the same order in which they were submitted.
  • The first specific userid match is honored. That is, if any of the specified patterns represents a complete userid (7 characters), an attempt is made to match it with the TSO user holding the data set. A soon as a specific userid match occurs, the search is stopped. This process includes all the elements in a list for a DCS NAG statement and all the DCS NAG statements with the same id value.
  • If there is no specific match, then a pattern match is attempted. As soon as a match occurs, the search is stopped.

This keyword indicates that you want to specify the nagging frequency and number of nags.

This keyword is optional. If you do not code it, the default value is the one coded in the TMSS initialization statement DCS SET for the keyword NAG. If no NAG was coded, the default is 3 times, 5 minutes apart.

This keyword is mutually exclusive with SUPPRESS.

A numeric value from 1 to 99, representing the number of times a TSO user is to be nagged.

A numeric value from 1 to 99, representing the number of minutes to elapse between nags.

This optional keyword indicates that you want to modify the NAG text. It provides the linkage to the DCS NAGTEXT statement.

If this keyword is not provided then the standard NAG message is generated.

This keyword is mutually exclusive with SUPPRESS.

A numeric value from 1 to 99 that is also specified in the DCS NAGTEXT statement.

Indicates that the userids matching the specified pattern are not to be nagged.

This keyword is mutually exclusive with REPEAT and TID.

Examples:

This example shows the link, using the NID of 10, of a FORDSN and two NAG statements. The first NAG statement covers any TSO user with a userid that starts with Z5, PAY, or PAY9. The second NAG

statement represents a specific user for whom we want to have a particular “nagging” text. The NAG statement is then linked to the NAGTEXT statement with the TID of 11.

See also: /*DCS FORDSN and JECL Syntax Conventions /*DCS NAGTEXT.

You can test the DAL/JAL logic Descriptor $DCJECL to determine whether a JECL NAG statement is present in the job. This allows you to control the use of this JECL statement.

/*DCS NAGTEXT

NAG TEXT Statement

This JECL statement allows you to specify the second line of a NAG. It can be either associated with all the data sets in a job or with a particular data set.

nn

Indicates that this NAGTEXT statement is associated with any DCS NAG statements containing the same value in the TID keyword.

This parameter is mutually exclusive with the JOB keyword.

More than one DCS NAG statement with the same TID value can be specified.

A string of 1 to 57 characters that replaces the second line of the standard nagging text.

Indicates that this NAGTEXT statement is associated with all the data sets in the job.

This keyword is the default, and is mutually exclusive with the nn parameter.

This keyword indicates that the default text is to be used. This keyword is mutually exclusive with the JOB keyword.

Examples:

This example shows the link, via the NID of 10, of a FORDSN and a NAG statement. The NAG statement is then linked to the NAGTEXT statement with the TID of 11.

See also: JECL Syntax Conventions /*DCS NAG.

/*DCS REPO

Dataset Repossessing Statement

This JECL statement allows you to request the repossession of data sets opened for input. You can specify the TSO user, or users, to repossess from. You can also request that a particular user, or users, be excluded from any repossessing.

For repossessing to take place, there must be a SERVICE statement with a request for CLAIM(R). Repossession will not take effect for either relative GDG’s (for example BASE(-1)) or GDG BASE data sets.

Indicates that this REPO statement is associated with all DCS FORDSN statements containing the same value in the RID keyword.

This parameter is mutually exclusive with the JOB keyword.

More than one DCS FORDSN statement with the same RID value can be specified.

Indicates that this REPO statement is associated with all the data sets in the job.

This keyword is the default, and is mutually exclusive with the ‘nn’ parameter.

This keyword is mandatory. It specifies which TSO users are to be affected by the repossessing statement.

If you want all users to be included then you code ‘*’.

A 1 to 7 character userid pattern. You can specify from 1 to 5 patterns in one statement.

If you need more than 5 patterns you can code an additional DCS REPO statement with the same RID value.

The pattern matching rules are as follows:

• If a list of patterns is provided the matching analysis always proceeds from left to right.
• If more than one DCS REPO statement is present with the same id value, the matching analysis handles the statements in the same order as they are submitted.
• The first specific userid match is honored, that is, if any of the specified patterns represents a complete userid (7 characters), an attempt is made to match it with the TSO user holding the data set. As soon as a specific userid match occurs the search is stopped. This process includes all the elements in a list for a DCS REPO statement and all the DCS REPO statements with the same id value.
• If there is no specific match, then a pattern match is attempted. As soon as a match occurs, the search is stopped.
  
  

Indicates that data sets opened for input are to be repossessed. This keyword is mutually exclusive with EXCLUDE.

Indicates that the specified TSO userids are to be excluded from any data set repossessing.

This keyword is mutually exclusive with INPUT.

Examples:

The above example shows a request for repossessing at the data set level. To repossess, a SERVICE statement with CLAIM(R) is required. This triggers the automatic repossessing of data sets that are allocated but not in use. The REPO statement can be used to give further instructions to the repossessing process. In this case we are showing two statements. The first one excludes a particular user (PAY90JD) from any repossessing. The second one instructs DCS to repossess data sets, even if they are open for INPUT, from any TSO user with an id starting with PAY6.

See also: /*DCS FORDSN and JECL Syntax Conventions /*DCS SERVICE.

/*DCS SERVICE

 Service Level Request Statement

This JECL statement allows you to request a service level for all the data sets associated with a job or a particular data set.

Indicates that this Service level request statement is associated with a DCS FORDSN statement. The FORDSN statement has a SID coded with the same ‘nn’ value.

This parameter is mutually exclusive with the JOB keyword.

JOB

Indicates that this SERVICE Level request statement is associated with all the data sets in the job.

This keyword is the default, and is mutually exclusive with the ‘nn’ parameter.

The name of a data set service level. It can be one of the following:

DEFAULT indicates that you want the installation default value.

A list of up to 7 service level terms enclosed in parentheses. Each term, with the exception of the last one in the list, must include a time interval. The format is:

The name of a data set service level. It can be one of the following:

DEFAULT indicates that you want the installation default to be substituted in the data set service list.

DCS attempts to service the data set (or data sets) using the first service level coded. Once the interval for that service level has expired, the service level is altered to reflect the value of the next element in the list. When the last element of the list is reached, DCS will remain at this service levels until the request is honored.

A time interval from 1 to 999 minutes. It specifies the time that DCS is to keep a particular service level.

This subparameter must not be coded in the last element of the service list.

CLAIM(R)

Indicates that you want data set repossessing. If this request is coded in a service level list, it must be the last element in the list. Repossession will not take effect for either relative GDG’s (for example BASE(-1)) or GDG BASE data sets.

Examples:

The above example shows a request for SERVICE at the data set level. Only contention for data sets with the first two level qualifiers matching AP9005.PAYROLL will be managed under this SERVICE statement. If contention occurs, for the first 10 minutes the job will receive STANDBY service. After that time, the service is moved to the highest possible level: CLAIM(R).

The above example shows a request for SERVICE at the job level. Any contention for the job will be managed under this statement.

See also: /*DCS FORDSN and JECL Syntax Conventions /*DCS REPO.

/*DJC ANDIF

Additional Conditions to be Satisfied

This statement allows you to specify additional conditions that must be satisfied for a RUNIF or FLUSHIF statement. It is a way to specify “and” conditions.

Indicates which job-related condition or event must be satisfied before DJC can release this job, and can be either:

• A jobname, or
• A DJC Event name, which consists of 2-9 alphanumeric or national characters, the first of which must be a per cent sign (%).
  
  

Specifies that the dependency is to be satisfied by another DJC Group. If the Group does not already exist, it is created and the dependency is recorded.

Is a DJC Group name, which consists of 1-8 alphanumeric characters, the first of which must be alphabetic or national, optionally followed by a period and a second level name, also consisting of 1-8 alphanumeric characters.

This can be one of the following:

The comparison operators allowed are:

The completion code must have the following format:

Refers to a step completion code, or a completion code signaled by a DJC Event. nnnn represents a 1-4 digit decimal number.

The comparison operators allowed are:

The abend code must have one of the following formats:

Refers to a system abend, such as SB37. xxx represents a three digit hexadecimal number. All the digits must be coded, e. g. S001.

Refers to a user abend code. nnnn represents a four digit decimal number between 0-4095. All the digits must be coded, e.g. U0001.

The job or DJC Event ends normally or abnormally, but does not fail on a runtime condition, and is not flushed.

The job fails on a runtime condition, such as “unit not available.”

The referenced job was flushed from the DJC Group because the Group completed or because of a specific action.

The job or DJC Event ends without a system or user abend code, does not fail on a runtime condition, and is not flushed. This is the default.

The job or DJC Event ends with a system or user abend code.

The job or DJC Event ends with a system abend code.

The job or DJC Event ends with a user abend code.

Examples:

The job in this example will run on the successful completion of JOBA and JOBB. Once this job  executes the Group is no longer needed.

See also: JECL Syntax Conventions /*DJC FLUSHIF and JECL Syntax Conventions /*DJC RUNIF.

Notes:

The ANDIF statement is associated with the most recent RUNIF or FLUSHIF statement. If there is no preceding RUNIF or FLUSHIF statement, the job is flushed with a JCL error.

The ANDIF statement cannot follow a CONDIF.

 /*DJC CONDIF

CONDIF Statement

This statement allows you to specify the condition or conditions that must be satisfied before this job is released by DJC. The CONDIF statement is patterned after the JCL COND parameter. It simplifies the process of breaking up multi-step jobs into independent jobs. It has capabilities similar to RUNIF and FLUSHIF.

name

Indicates which job-related conditions or event must be satisfied before DJC can release this job, and can be either:

• A jobname, or
• A DJC Event name, which consists of 2-9 alphanumeric or national characters, the first of which must be a per cent sign (%).

Specifies that the dependency is to be satisfied by another DJC Group. If one does not already exist, it is created and the dependency is recorded.

Is a DJC Group name, which consists of 1-8 alphanumeric characters, the first of which must be alphabetic or national, optionally followed by a period and a second level name, also consisting of 1-8 alphanumeric characters.

The specification for running or flushing jobs follows the format of the JCL COND code facility.

The condition code that is being tested in the (nn,op) clause is the condition code that was returned from the job that terminated or from the event being posted.

If the condition is TRUE the job is flushed, if the condition is FALSE the job is released for execution.

Note that this is not the same behavior as a similar FLUSHIF statement. If the FLUSHIF condition is FALSE then nothing is altered with respect to the state of the job.

The job containing the statement is released when the designated job finishes or when the designated event is signaled.

The job containing the statement is released if the designated job is terminated abnormally, else the job is flushed.

Examples:

In this example, the job containing the CONDIF statement runs if COND=(0,NE), i.e. the highest return code from UPDATE01 is equal to 0.

See also: JECL Syntax Conventions /*DJC FLUSHIF and JECL Syntax Conventions /*DJC RUNIF.

/*DJC FLUSHIF

When to Flush Dependent Jobs

The FLUSHIF statement defines dependencies that the job has on other jobs or events in the DJC Group. A dependency can also be on a job/event in another Group. The job can contain many FLUSHIF statements. The first (possibly only) statement for which the condition (or conditions) is true will be used to determine the disposition of the job (in the context of the DJC Group).

A single FLUSHIF can have as many conditions as you wish. Multiple conditions are specified by following the FLUSHIF with a DJC ANDIF statement.

Indicates which job-related conditions or event must be satisfied before DJC flushes this job, and can be either:

• A jobname, or
• A DJC Event name, which consists of 2-9 alphanumeric or national characters, the first of which must be a per cent sign (%).

Specifies that the dependency is to be satisfied by another DJC Group. If one does not already exist, it is created and the dependency is recorded.

Is a DJC Group name, which consists of 1-8 alphanumeric characters, the first of which must be alphabetic or national, optionally followed by a period and a second level name, also consisting of 1-8 alphanumeric characters.

This can be one of the following:

The comparison operators allowed are:

The completion code must have the following format:

Refers to a step completion code, or a completion code signaled by a DJC Event. nnnn represents a 1-4 digit decimal number between 0-4095.

The comparison operators allowed are:

The abend code must have one of the following formats:

Refers to a system abend, such as SB37. xxx represents a three digit hexadecimal number. All the digits must be coded, e. g. S001.

Refers to a user abend code. nnnn represents a four digit decimal number between 0-4095. All the digits must be coded, e.g. U0001.

The job or DJC Event ends normally or abnormally, but does not fail on a runtime condition, and is not flushed.

The job fails on a runtime condition, such as “unit not available.”

The referenced job was flushed from the DJC Group because the Group completed or because of a specific action.

The job or DJC Event ends without a system or user abend code, does not fail on a runtime condition, and is not flushed. This is the default.

The job or DJC Event ends with a system or user abend code.

The job or DJC Event ends with a system abend code.

The job or DJC Event ends with a user abend code.

Examples:

If job JOB0001 (in the same DJC Group) terminates with a return code of 0, this job is flushed.

If the event %NOFIX is signaled from group PROGR01.DAILY, flush this job.

See also: JECL Syntax Conventions /*DJC ANDIF.

/*DJC GROUP

Associate a Job with a DJC Group

This statement associates a job with a DJC Group. If the Group does not exist, it is created.

Is a DJC Group name, which consists of 1-8 alphanumeric characters, the first of which must alphabetic or national, optionally followed by a period and a second level name, also consisting of 1-8 alphanumeric characters.

Requests that the CLOSE Event be signaled at job termination, whether normally or abnormally.

Specifies the maximum number of hours before the DJC Group closes automatically.

The range 1 to 99.

The short form for this keyword is CT.

Specifies that this job should be accepted into the current active (NOT CLOSED) group even if a job of the same name has already executed. The job that it is replacing cannot be executing or waiting for execution.

Specifies the maximum number of days that the Group history is kept. The default is the installation value from the DJC SET operator command or the DJC initialization statement.

The range is 1 to 365.

The short form for this keyword is HD.

Specifies the maximum number of generations of Group history to be kept. The default is the installation value from the DJC SET operator command or the DJC initialization statement.

The range 1 to 9.

The short form for this keyword is HC.

Specifies  that  the  DJC  Group  will  be  held  by  DJC  regardless  of  dependencies.  The  Group must subsequently be released with a DJC RELEASE GROUP operator command.

Indicates that jobs flushed by DJC are to be placed on the JES2 output queue. This keyword is mutually exclusive with PURGE_IF_NOT_RUN, and is the default.

The short form for this keyword is OUTPUT.

Specifies a Group password.

1-8 characters, following the same rules that apply to coding a job name.

Indicates that jobs flushed by DJC are to be placed on the JES2 purge queue. This keyword is mutually exclusive with OUTPUT_IF_NOT_RUN.

The short form for this keyword is PURGE.

Examples:

This statement indicates that the job is requesting membership in a DJC group called DEV505. BACKUP. The group is to be closed after 8 hours.

Notes:

The value from the last job processed is used if more than one job for a particular Group specifies any of:

CLOSE_TIME
HISTORY_DAYS
HISTORY_COUNT
OUTPUT_IF_NOT_RUN
PURGE_IF_NOT_RUN

A Group can be closed before CLOSE_TIME expires by a DJC Event or an operator or user command.

HISTORY_DAYS and HISTORY_COUNT are maximums. When either maximum is exceeded, the oldest generation of the Group’s history is deleted.

A Group password can be specified at any time by any arriving job, but once a password has been specified, all subsequent jobs specifying the same Group name must also provide the correct password. Failure to do so results in the job failing with a JECL error.

Group passwords cannot be altered or removed.

Group passwords must be specified when using the UCS DJC dialog, but do not apply to operator commands.

/*DJC MESSAGE

DJC API Message Statement

This JECL statement allows jobs to describe a system or application message that is to trigger the signal of an event or events. There must be a SIGNAL statement that matches the API id specified. The message must occur within the address space running the job with the MESSAGE statement.

Represents a character string pattern. It can contain either the wildcard characters “*” or “?”, and specific text within quotes. If your actual text contains quotes, then you express it as paired quotes.

Represents 0 or more characters of any kind.

Represents 1 character of any kind.

represents the text that requires an exact match for the API request to be triggered.

“Connects” the message statement with the actual DJC SIGNAL statement that describes the event.

Examples:

The above statement matches any message with IST009A and STARTED in its text. When a match occurs, the event %DBGOING is signaled because of the API number match.

The above statement matches any message with USERID=cccPROD, where c represents any character.

In the previous example, a match on either message triggers the signal of the event named %CICSOFF.

See also: JECL Syntax Conventions /*DJC SIGNAL.

*DJC RUNIF

When to Run Dependent Jobs

The RUNIF statement defines dependencies that the job has on other jobs or events in the DJC Group. A dependency can also be on a job or DJC Event in another Group. If the job contains multiple RUNIF statements, they are treated as OR conditions. In other words, the first (possibly only) statement for which the condition (or conditions) is true determines the disposition of the job in the context of the DJC Group.

A single RUNIF can have as many conditions as you wish. The multiple conditions are specified by following the RUNIF with a DJC ANDIF statement

Indicates which job-related conditions or event must be satisfied before DJC can release this job, and can be:

• A jobname, or
• A DJC Event name, which consists of 2-9 alphanumeric or national characters, the first of which must be a per cent sign (%).

Specifies that the dependency is to be satisfied by another DJC Group. If one does not already exist, it is created and the dependency is recorded.

Is a DJC Group name, which consists of 1-8 alphanumeric characters, the first of which must be alphabetic or national, optionally followed by a period and a second level name, also consisting of 1-8 alphanumeric characters.

This can be one of the following:

The completion code must have the following format:

Refers to a step completion code, or a completion code signaled by a DJC Event. nnnn represents a 1-4 digit decimal number between 0-4095.

The comparison operators allowed are:

The abend code must have one of the following formats:

Refers to a system abend, such as SB37. xxx represents a three digit hexadecimal number. All the digits must be coded, e. g. S001.

Refers to a user abend code. nnnn represents a four digit decimal number between 0-4095. All the digits must be coded, e.g. U0001.

The job or DJC Event ends normally or abnormally, but does not fail on a runtime condition, and is not flushed.

The job fails on a runtime condition, such as “unit not available.”

The referenced job was flushed from the DJC Group because the Group completed or because of a specific action.

The job or DJC Event ends without a system or user abend code, does not fail on a runtime condition, and is not flushed. This is the default.

The job or DJC Event ends with a system or user abend code.

The job or DJC Event ends with a system abend code.

The job or DJC Event ends with a user abend code.

Examples:

If job JOB0001 (in the same DJC Group) terminates with a maximum step return code less than or equal 8, this job is run.

If the event %READY is signaled from Group PROGR01.DAILY with a condition code of 4, this job is run.

If JOBXXXX terminates with a system abend of B37, this job is run.

See also: JECL Syntax Conventions /*DJC ANDIF.

/*DJC SIGNAL

Request to Signal Event

This statement is used to signal a DJC Event. The event is always associated with the DJC Group of the job issuing the signal. The signal can be specified to occur at the beginning of the job, at a designated step end, or upon the occurrence of a specified message from the job.

When the event is signaled, it causes any statements that were associated with this event to be evaluated and acted upon.

If there is no AT or API keyword, the event is signaled at the start of the job and the CODE parameter always results in a normal condition code of zero.

Represents a DJC Event name, which consists of 2-9 alphanumeric or national characters, the first of which must be a per cent sign (%).

The special DJC Event name %CLOSE is reserved. The first time %CLOSE is signalled, the DJC Group becomes closed, i.e. it no longer accepts new jobs or DJC Events from other Groups. You can set and test values for %CLOSE just like any other DJC Event. When %CLOSE is signalled as a result of a /*DJC GROUP statement or an operator command, it is given a value of 0.

Indicates that the event is to be signaled at the completion of the named step.

The name of the step.

In cases where there are multiple steps with the same name, the form:

can be coded with the keyword AT. Otherwise the first step that matches the name triggers the signal.

Indicates that the job intends to signal the event through the API interface.

This is a two digit identifier that connects the API request to a message described with the DJC MESSAGE JECL statement.

This keyword associates a value with the signal of the event.

Represents a fixed decimal integer from the range 0-4095.

When the SET keyword is coded with this parameter, if the step terminates normally then the signal is posted with a value equal to the condition code for the step.

If the step terminates abnormally, the signal is posted with a value of Sxxx or Unnnn equal to the value of the user or system abend code.

When the SET keyword is coded with this parameter, the signal is posted with a value of Sxxx, exactly as though a system abend had taken place. Note that this does not necessarily indicate that there actually was a system abend.

xxx represents 3 hexadecimal characters. All the digits must be coded, e.g. S001.

When the SET keyword is coded with this parameter, the signal is posted with a value of Unnnn, exactly as though a user abend had taken place. Note that this does not necessarily indicate that there actually was a user abend.

nnnn represents a four digit number between 0-4095. All the digits must be coded, e.g. U0001.

When the SET keyword is coded with this parameter, the signal is posted with a value of FAILS, exactly as though the job had failed. Note that this does not necessarily indicate that the job triggering the signal failed, but the signal is sent as if it had.

When the SET keyword is coded with this parameter, the signal is posted with a value of FLUSH, exactly as though a FLUSH had taken place. Note that this does not necessarily indicate that the job triggering the signal was flushed, but the signal is sent as if it were.

Examples:

This job will signal other jobs in the Group as soon as STEP05 and STEP09 are completed. Other jobs do not have to wait until JOBLONG terminates and can take advantage of the parallel processing of production job streams.

See also: JECL Syntax Conventions /*DJC MESSAGE.

A normal completion automatically posts the signals NORMAL and EVEN. An abnormal completion automatically posts the signals ONLY and EVEN.

 /*JAL TRACE

Activate JAL Tracing

This statement is used to activate JAL tracing for a job. Output is sent to the JOBLOG data set.

 /*JBS ACTIVATE

Job Related Binding Agent Activation Statement

To activate a named Job Related Binding Agent from an executing job.

The name of a Job Related Binding Agent (non-PERMANENT).

Represents the activation attribute of the Agent. The default is LOCAL.

Indicates that the Binding Agent will bind jobs to the processor where this job is running.

Indicates that the Binding Agent that has been activated can now bind jobs to any processor in this MAS node.

Indicates that activation is to take place at a step level.

If the FROM keyword is not present, the agent will be activated at the beginning of the job.

The name of the step in this job from where the agent is to become active. Activation of the agent will occur at the beginning of the step. If there are multiple steps with the same name, the agent will be activated when the first step that matches the name is encountered.

Similar to the parameter above for the deactivation of the Binding agent.

If the TO keyword is not present, the agent will be deactivated at the end of the job.

The name of the step.

Deactivation of the agent will occur at the end of the step.

Notes:

In cases where there are multiple steps with the same name, the form:

can be coded with the keywords FROM and TO.

Up to 24 JBS ACTIVATE statements can be present in a job (all types).

/*JBS ACTIVATE (API)

API Binding Agent Activation Statement

To activate a named Binding Agent from an executing job indirectly via the API.

The name of a Binding Agent. Both job-related Binding Agents and PERMANENT Binding Agents are allowed.

Indicates that the job intends to activate the named agent through the Application Program Interface.

The id represents the two digit identifier that the program will use to activate the corresponding Agent, via a message.

Represents the activation attribute of the Agent. The default is LOCAL.

Indicates that the Binding agent will bind jobs to the processor where this job is running.

Indicates that the Binding agent that has been activated can now bind jobs to any processor in this MAS node.

Notes:

If the Binding Agent is job related (non-PERMANENT), it is automatically deactivated at the end of the job.

If the Binding Agent is PERMANENT, then it must be explicitly deactivated either by an operator command or by a JBS DEACTIVATE statement.

Up to 24 JBS ACTIVATE statements can be present in a job (all types).

/*JBS ACTIVATE (PERM)

PERMANENT Binding Agent Activation Statement

To activate a named PERMANENT Binding Agent from an executing job. This Agent will not be automatically deactivated at the end of the job. Because it is a Permanent Agent it must be explicitly deactivated.

The name of a Binding Agent that has been defined as PERMANENT.

Represents the activation attribute of the Agent.

The default is LOCAL.

Indicates that the Binding agent will bind jobs to the processor where this job is running.

Indicates that the Binding agent that has been activated can now bind jobs to any processor in this MAS node.

Indicates that the agent is to be activated at a particular step.

If the AT keyword is not present, the agent will be activated at the beginning of the job.

The name of the step in this job that will cause the activation of the agent. The activation of the agent will occur at the beginning of the step.

If there are multiple steps with the same name, the agent will be activated when the first step that matches the name is encountered.

In cases where there are multiple steps with the same name, the form:

can be coded.

Special keyword, indicating that the agent is to be activated at job termination.

Indicates that the Agent is to be activated only if it was active before the job requested it to be deactivated. The Agent must have been defined using the UNIQUE attribute.

Notes:

PERMANENT agents are not automatically deactivated at the end of the job. If they are to be deactivated by the activating job, a JBS DEACTIVATE control statement must be included in the job stream.

Up to 24 JBS ACTIVATE statements (all types) can be present in a job.

/*JBS BIND

Job Binding Statement

To associate the scheduling of this job with the named Binding Agent. This controls when and where the job will be selected for execution.

The name of the Binding Agent. A list of up to four Binding Agent names can be included per /*JBS BIND control statement. This list represents OR conditions. Any one of the named Binding Agents can satisfy the BIND requirements.

The Binding Agent must have been previously defined, otherwise it is considered an error.

$$DELETE is a special Agent name that causes the Bind request to be ignored if it causes an incompatibility. If included, $$DELETE counts as one of the four allowable Agent names, and must be the last name in the list.

/*JBS BIND (compound)

Compound Form of BIND Statement

This JECL statement allows you to provide multiple BIND statements in a single JECL statement.

The name of a Binding Agent. The equivalent of a BIND statement is coded within brackets.

The rules are identical to the standard BIND statement.

$$DELETE is a special Agent name that causes the Bind request to be ignored if it causes an incompatibility. If included, $$DELETE counts as one of the four allowable Agent names, and must be the last name in the list that includes it.

You can code as many “bracketed” BIND statements as you can fit on a JECL statement.

Examples:

The above statement is the equivalent of:

/*JBS BIND IMS.PRODA,IMS.PRODB
/*JBS BIND IMS.CUSTOMER
/*JBS BIND IMS.PRICE

/*JBS DEACTIVATE (PERM)

PERMANENT Binding Agent Deactivation Statement

This statement deactivates Binding agents that have been previously activated. Used for the deactivation of permanent agents (agents that are defined with the attribute PERMANENT).

The name of a previously activated PERMANENT Binding Agent.

Indicates that the Agent is to be deactivated at a particular step.

Note that when this keyword is omitted, the Agent is deactivated at the end of the job.

Identifies the step that, upon termination, will result in the deactivation of the named Binding Agent.

If there are multiple steps with the same name the agent will be deactivated when the first step that matches the name is encountered.

In cases where there are multiple steps with the same name the following form can be used:

Special keyword. Indicates that the Agent is to be deactivated as soon at this job initiates.

This keyword must be coded to deactivate PERMANENT Agents that have been activated with the attribute GLOBAL. This is necessary even when the Agent has been activated by this job.

Indicates that the Agent is to be deactivated only if it was not active before the job requested it   to be activated. The Agent must have been defined using the UNIQUE attribute.

Notes:

This statement is used to deactivate Binding agents that were defined with the PERMANENT attribute.

Up to 24 DEACTIVATE statements can be coded.

 /*JBS DEACTIVATE (API)

API Binding Agent Deactivation Statement

This statement deactivates Binding agents via the API.

The name of a previously activated Binding Agent. It can either be a job related Agent or a PERMANENT Agent.

Indicates that the job intends to use the Application Program Interface.

The id allows the application program to link the message with the required DEACTIVATE control statement.

For Binding Agents that do not have the attribute PERMANENT, it must have been activated by this job.

This keyword must be coded to deactivate PERMANENT Agents that have been activated with the attribute GLOBAL, even if the Agent has been activated by this job.

Notes:

Up to 24 DEACTIVATE statements can be coded.

 /*JBS MESSAGE

API Message Statement

This JECL statement allows jobs to describe a WTO message that is to trigger the activation or deactivation of a Binding Agent.

Represents a character string pattern. It can contain either the wildcard characters ‘*’ or ‘?’, and specific text within quotes. If your actual text contains quotes, then you express it as paired quotes.

Represents 0 or more characters of any kind.

Represents 1 character of any kind.

represents the text that requires an exact match for the API request to be triggered.

“Connects” the message statement with the actual ACTIVATE or DEACTIVATE JBS statement that describes the Binding Agents.

Examples:

/*JBS ACTIVATE RESOURCE.A,API=10
/*JBS MESSAGE *’IST009A’*’STARTED’*,API=10

The above statement matches any message with IST009A and STARTED in its text in that sequence. The message must occur within the address space running the job with the Message statement. When a match occurs, RESOURCE.A is activated because of the API number match.

The above statement matches any message with USERID=cccPROD, where c represents any character.

/*JBS ACTIVATE CICS.PROD,API=10
/*JBS MESSAGE *’IEA123I’*’CICSPROD’*,API=10
/*JBS MESSAGE *’IEA125I’*’CICSPROD’*,API=10

In the previous example, a match on either message triggers the activation of CICS.PROD.

/*JBS NEEDS

Requests a JBS Environment

This statement specifies the JBS Environment needed by the job.

Is the name of the JBS Environment requested, and can be 1-16 alphanumeric, national ($,  #, @) or embedded underscore (_) characters.

Up to four Environments can be requested for a job. These requests are treated as a logical OR, that is, any one of the requested Environments satisfies the request.

Notes:

A job can have only one /*JBS NEEDS statement. Multiple statements cause the job to fail with a JECL error.

If JAL specifies the JBS NEEDS statement, this JECL statement is overridden. All specified Environments must be defined:

• If the Environment is undefined when the job is submitted, the job is failed with a JECL error.
• If the Environment is deleted after the job has been analyzed, the job is requeued in the Job Analysis class with MHS_TM hold applied.

/*JBS SET

Set a Resource Element

This statement allows you to set a Resource Element to a particular state on the system on which the job is running.

/*JCS AFTER

Request to run after a named job

This statement allows you to indicate that a job is to run after a particular job. Note that the job in question must be in the system at the time the determination is made. If the named job is not in the system, it is assumed that it has already run.

Represents the name of the job that must run prior to this job. If a job with that name is not found it is assumed that it has run.

Note that the scope of the AFTER applies only to jobs with the same Batch Name. The Batch Name could have been given either with a /*JCS BATCH statement or in JAL.

Allows you to be specific about a job. This is only applicable in situations where the named job has already been submitted, therefore you know its JES2 number.

The JES2 job ID.

Notes:

You can have multiple AFTER statements in a job. They must all be satisfied before the job is selected for execution.

For a job to be able to use this statement, it must be associated with a Batch Name. This can be done automatically in JAL, or the job can include a /*JCS BATCH statement.

Do not include this statement in a job that uses the SEQ keyword of the /*JCS BATCH statement. Doing so requests conflicting processing sequences with unpredictable results.

/*JCS BATCH

Assign a Batch Name to a job

This control statement associates the job with a group (batch) of jobs that have the same Batch Name.

To use BEFORE and AFTER statements, the job must have a Batch Name. The installation could chose to associate Batch Names with jobs in JAL, then this statement is not required.

Represents the Batch Name used to group jobs for the purpose of BEFORE & AFTER relationships.

The name can be a one or two level name following data set naming conventions.

When coded, this optional subparameter ensures that, within the named batch, this job will be executed in the sequence in which it was read in. Do not use this keyword for a job that includes any of the /*JCS AFTER, the /*JCS BEFORE, the /*AFTER, or the /*BEFORE statements. Doing so requests conflicting processing sequences with unpredictable results.

The short form for this subparameter is SEQ.

/*JCS BEFORE

Request to run before a named job

This statement allows you to indicate that a job is to run before a particular job. That is, if the named job is in the system, it is held until the job with the JCS BEFORE statement completes execution. If no job is found, no action is taken.

Represents the name of the job that is to be held until this job runs. If a job with that name is not found no action is taken.

Note that the scope of the BEFORE applies only to jobs with the same Batch Name. The Batch Name could have been given either with a /*JCS BATCH statement or in JAL.

Allows you to be specific about a job. This is only applicable in situations where the job you want to execute before has already been submitted, therefore you know its JES2 number.

The JES2 job ID.

/*JCS WITH

Establishes a Job Dependency

This JECL statement allows you to describe a job dependency. You can indicate that a job must run with another concurrently running job.

Specifies the name of the required job, that is, the job that must be running before this job is allowed to execute.

If the required job is not running, this job will not be selected for execution. It awaits execution with a status of pending WITH.

Once the required job begins execution, this job is eligible for selection. It will be selected for execution as soon as an initiator with the appropriate class becomes available.

This optional keyword specifies that this job can run on any system in the complex, that is, it does not have to run on the same system as the job upon which it depends..

Examples:

/*JCS WITH PAYROLL
/*JCS WITH DC9000JD,NOSYSAFF

Notes:

Only one JCS WITH statement is allowed per job.

Even though WITH support is a part of JCS, a JCS Batch Name is not required.

If a job references itself in the JCS WITH statement, it is an error and the job is failed. When two jobs reference each other, for example:

//JOB1 JOB ...
/*JCS WITH JOB2
//JOB2 JOB ...
/*JCS WITH JOB1

Neither job will be selected for execution until one of the jobs is released manually.

If more than one JCS WITH statement is found in the JCL, the last one encountered takes effect.

/*JLS ENQ

Allows you to serialize jobs

This JECL statement allows you to serialize jobs. This mechanism is analogous to the standard MVS facilities for data set SHR versus OLD.

Represents a valid Agent Name.

Self-explanatory. It is the default value.

Must be the only job running.

It allows you to indicate to ThruPut Manager that if a job requires exclusive control and it cannot get the resource because other jobs are using it in shared mode then:

• 
  
  • The resource is “drained” by not allowing any other job (requiring that resource) to be selected for execution.
  • When the last executing job that was using the resource in shared mode terminates, then the job with the DRAIN attribute is selected.

The DRAIN facility addresses situations where exclusive control of a resource cannot be obtained because there is a continuous stream of jobs requesting it in shared mode.

The DRAIN facility takes effect only after the job has been selected for execution under normal JES2 job selection rules, but initiation could not proceed because the resource was in use. Prior to the time the job is selected for execution, other jobs requesting the resource are not affected.

Notes:

An aggregate total of 24 statements of the following types can be included per job:

•  /*CNTL
• /*JLS ENQ
• /*JLS LIMIT

All of them must be satisfied before the job is allowed to execute.

/*JLS LIMIT

Define Limiting Agent for a Job

This statement allows you to assign a Limiting Agent and its limit value to a job or started task.

Represents a valid Limiting Agent Name. It does not have to be defined.

Indicates that you want to define Limiting values. If the keyword is omitted, the values ‘1,1’ are assumed.

Defines the maximum number of concurrent jobs that can run under the Limiting Agent. It can be from 1 to 999.

Defines the weight of this job. The default is one. The value can be from 1 to 999.

Notes:

This statement is provided mainly to handle situations where you want to ensure that a particular number of jobs/started tasks cannot be exceeded accidentally. A typical situation is when you want to have only one started task for a particular function in your MAS complex, even though more than one is technically possible. Placing a LIMIT statement in the started task JCL prevents any accidental starting of a second task.

An aggregate total of 24 statements of the following types can be included per job:

• /*CNTL
• /*JLS ENQ
• /*JLS LIMIT

All of them must be satisfied before the job is allowed to execute.

/*JTS HOLD_UNTIL

JTS User Statement

This JECL statement allows job submitters to apply a JTS hold, and describe when the hold is to be removed.

This keyword allows you to specify the date on which the JTS hold is to be removed.

If DATE is not specified, TODAY is assumed.

To describe the actual date, you can use one of the following Julian date formats:

yyyy.ddd
yy.ddd
ddd

In these formats:

yyyy represents all the digits for a calendar year, for example 2014.

yy represents the last two digits of a calendar year. For example, for 2014, yy is 14.

ddd represents the day (from 1 to 365 or 366 depending on the year) including leading zeros.

Instead of the DATE keyword, you can use one of the following alphabetic keywords:

MONDAY | MON
TUESDAY | TUE
WEDNESDAY | WED
THURSDAY | THU
FRIDAY | FRI
SATURDAY | SAT
SUNDAY | SUN
TODAY
TODAY[+ddd]

The day that you specify represents the next occurrence of the day of the week. For example, if you specify FRIDAY and the job is submitted on a Friday, the job is delayed until next Friday.

Indicates that the JTS hold is to be removed on the day it is submitted. TODAY begins one minute after midnight, therefore this form should be accompanied by a TIME keyword (see below).

Specifies a relative day on which the JTS hold is to be removed.

Represents the number of days to be added to the date.

AT=numeric-time
TIME=numeric-time

This keyword allows you to specify the time that the JTS hold is to be removed.

If TIME or AT is not specified, a default value specified by your installation is used.

The valid numeric values that you can specify are:

In these formats:

hh represents the hour as read from a 24-hour clock.

mm represents the minutes.

Instead of the TIME or AT keyword, you can use one of the following alphabetic keywords:

MORNING
AFTERNOON
TONIGHT | NIGHT
NOW+mmmm

The actual time values of the above keywords (except NOW) are set by your installation.

Indicates a relative number of minutes from the time of job submission. This keyword is mutually exclusive with any DATE keyword.

Represents the number of minutes (1-1440) to be added to the current time.

Examples:

/*JTS HOLD_UNTIL DATE=2014.123 TIME=09:00
/*JTS HOLD_UNTIL MONDAY AT=08:30
//*+JTS HOLD_UNTIL MONDAY NIGHT
//*+JTS HOLD_UNTIL NOW+120

/*MHS_USER

Request a user hold

This JECL statement allows a job submitter to request that a ThruPut Manager user hold be applied to the job. Explanatory notes can be added to the user hold.

Specifies a unique identifier that is used to distinguish between multiple user holds.

1 to 8 alphabetic, numeric, or national characters that uniquely identify this hold. If more than one JECL statement specifies the same identifier, the last one encountered takes effect.

Specifies additional information that can be used to document the hold.

Text that will be displayed in addition to the hold identifier, up to the number of characters that can legally fit on the JECL statement. Notes that do not include commas or blanks can omit the enclosing apostrophes.

Examples:

/*MHS_USER HOLD ID=POOL3,NOTES=’UNTIL JOE READY’
/*MHS_USER HOLD ID=9202,NOTES=’NEEDS APPROVAL’

/*SLM SERVICE

SLM ONLY   

Specify SLM Job Importance

This statement allows you to specify the SLM Job Importance for a job. Job Importance is relevant only in the context of a job’s Batch Importance.

Requests a specific Job Importance for the job. This keyword can be abbreviated J_I.

Is a number in the range 1-5, where 1 represents the highest Job Importance and 5 the lowest.

/*STROBE

The strobe card is coded as follows:

/*STROBE  [stepname],[program],[duration],[samples],[email-address]

Note that all parameters are optional. The parameters are positional:

Stepname — ‘*ALL’, OR ‘,’ SEPERATED. PROCSTEP.STEPNAME ALLOWED Default *ALL

Program — 1-8, ‘,’ SEPERATED program name or blank for default Duration – in minutes

Samples —1-150000

Email — up to 70 characters

/*TM TRACE

Turn On ThruPut Manager Tracing

This statement turns on ThruPut Manager tracing options for the job. The trace facility is used to gather data for problem reporting, and should only be activated on the explicit instructions of Customer Support.

/*WITH

Establishes a Job Dependency

This JECL statement allows you to describe a job dependency. You can indicate that a job must run with another concurrently running job,

This statement is intended to ease the conversion for those installations that used the Mellon modifications. If your installation did not use these mods, code the /*JCS WITH statement.

Specifies the name of the required job, that is, the job that must be running before this job is allowed to execute.

If the required job is not running, this job will not be selected for execution. It awaits execution with a status of pending WITH.

Once the required job begins execution, this job is eligible for selection. It will be selected for execution as soon as an initiator with the appropriate class becomes available.

Specifies that the jobs do not have to run on the same system within the JES2 complex.

Examples:

A job specifying this statement can run only if a job named PAYROLL is running on the same JES2 complex member.

This statement specifies that the job can run if a job named IMSMAINT is running anywhere in the JES2 complex.

Even though WITH support is a part of JCS, a JCS Batch Name is not required. If a job references itself in the WITH statement, it is an error and the job is failed. When two jobs reference each other, for example:

//JOB1 JOB ...
/*WITH JOB2
//JOB2 JOB ...
/*WITH JOB1

Neither job will be selected for execution until one of the jobs is released manually.

If more than one WITH statement is found in the JCL, the last one encountered takes effect.