Skip to main content
Version: OpCon

OS 2200 Job Details

The information in this section applies to defining an OS 2200 job. The text fields in the graphical interfaces support OpCon token replacement. For additional information about this platform, refer to OS 2200 LSAM and BIS LMAM Configuration in the OS 2200 LSAM online help.

Job Information

Start Command

  • Qualifier: Defines the qualifier of the ECL file.
  • File Name: Defines the filename of the ECL file.
  • Element Name: Defines the element name of the file containing the ECL, include Version when needed (e.g., ELT/VERSION).
  • Priority: Define the priority to be placed on the start statement when submitting the job to the Exec.
  • Options: Defines the valid options used for inclusion on the start statement.
  • Condition Word (octal): Defines an octal number placed in the middle third of the condition word for this job (sets T2 of run's condition word, the "set" parameter of the start statement).

Run Card Control

  • Run ID: Defines the run to the Exec and replaces the Run ID on the \@RUN card of the ECL.
  • Account: Defines the account code used for billing purposes. It is also used on the start statement issued for the job.
  • User ID: Defines the user of the account, used with the account code on the start statement. When user ID = "-SECURITY-", LSAM issues an ST <ELT> to start the job. This allows starting security officer jobs from SYS$LIB$*RUN$ when Auto Answer for Security is turned on.
  • Project: Define the project for file access and accounting purposes. Used on the start statement issued for the job.
  • Max Pages and Max Cards: Defines the maximum values for page and card generation for use on the start statement.

LSAM Resolved Dependencies

LSAM Resolved Dependencies option indicates if the job should include a Prerun job or a File dependency. Valid values include: <None>, Pre Run, File.

Prerun Information

If Pre Run is set for the LSAM Resolved Dependencies, the Prerun Information can be defined. The Prerun definition can contain all of the same fields as the Start Command and Run Card Control in the Job Information. Refer to the Job Information details above.

  • The Prerun information allows the user to specify an ECL to be executed immediately before the initiation of the job specified for the Job Information.
  • When the Prerun ECL terminates with an error, it is rescheduled at a user-defined interval. For information on this Prerun setting, refer to Time Settings.
  • The Prerun ECL continues to execute at the user-defined interval until it succeeds, allowing the ECL on the Job Information to process. The primary purpose of a Prerun is to test any required preconditions to job execution.

File Dependencies

If File is set for the LSAM Resolved Dependencies, the File Dependencies information can be defined. File Dependencies include the following information:

  • Qualifier: Defines the qualifier for the file dependency. Placing # before or after the qualifier directs the LSAM to search the SHARED File Directory for the file; without the # indicates the STD File Directory is to be searched.
  • File Name: Defines the filename the ECL is dependent on.
  • Type: Defines the type of dependency the ECL has on the file. The types of dependencies are:
    • Exists: The file must exist.
    • Created: The file must exist and was catalogued today.
    • Deleted: The file must not exist.
    • Size: The file exceeds the value already entered in the entered in the size.
    • Referenced: The file has been referenced today.
    • Assigned: The file is currently assigned.
    • BackedUp: The file has a current backup (Backed up and not yet modified).
    • Unloaded: The file is currently unloaded.

Completion Status Based on Condition Word

Upon termination of an LSAM started job, the run condition word is evaluated for completion status of the job. User-defined values can be used for range testing of any of the standard divisions of the condition word.

  • And/Or: Determines the association between multiple tests.
  • Word Part: Defines the portion of the word to be analyzed. Valid values are S1 through S6, and T1 through T3.
  • Condition: Defines the condition codes to specify how the word part is to be tested.
    • L AND: Logical And between the associated Value and the run's condition word.
    • LT: Less than
    • EQ: Equal
    • GE: Greater than or equal to
    • NE: Not equal
    • LE: Less than or equal to
    • GT: Greater than
    • Range: Range of values
Example

The following example is an "L AND" condition. A job has the run condition word test defined as follows:

S6 L AND 0016 (decimal equivalent of an octal 20) = BAD FI
or ANYTHING ELSE = GOOD FIN.
If S6 = 0001(octal)
000 001 Bits in S6 part of run's condition word
010 000 Logical AND of Bits by LSAM (octal 20, decimal 16)
000 000 Result of Logical AND
The job terminated normally (GOOD FIN)
If S6 = 0020 (octal)
010 000 Bits in S6 part of run's condition word
010 000 Logical AND of Bits by LSAM (octal 20, decimal 16)
010 000 Result of Logical AND
The job terminated abnormally (BAD FIN)
If S6 = 0063 (octal)
110 011 Bits in S6 part of run's condition word
010 000 Logical AND of Bits by LSAM (octal 20, decimal 16)
010 000 Result of Logical AND
The job terminated abnormally (BAD FIN)
  • Value: Defines the value associated with the Condition. When Range is the defined Condition, enter the starting decimal value for the range. This must be the decimal equivalent of the octal value.
  • End Value: Defines the ending decimal value when Range is the defined Condition. The End Value must be greater than the Value.
  • Fin Status: Determines whether the condition word test describes a GOOD FIN or BAD FIN.
  • Anything Else: Determines the final status for the job when an error code that was received was not defined in the Completion Status based on Condition Word section. Anything not defined is treated as GOOD FIN or BAD FIN based on the option defined.

Tokens

Tokens provide a way of substituting variable data into a job's runstream at execution time. The tokens information allows users to associate literal tokens or OpCon tokens with strings that are matched and replaced in the ECL. When the run requires a replacement within the ECL, the characters that represent the location within the ECL can be equated here. Separate multiple token equations with a comma (,).

Example

The following example shows how to separate multiple tokens.

?SCHEDNAME?=[[$SCHEDULE NAME]],?MY TOKEN?=[[MYVALUE]]
  • When the ECL contains the string "?SCHEDNAME?", then those characters can be replaced with the schedule name by equating it to the OpCon Schedule Name token.

  • Key in the following information for the token: ?SCHEDNAME?=[[$SCHEDULE NAME]] - OpCon replaces [[$SCHEDULE NAME]] with the literal schedule name. The OS 2200 LSAM searches the ECL for ?SCHEDNAME? and replaces the string, character by character, with the resolved schedule name provided by the SAM. It is the user's responsibility to insure the length or content of the resulting ECL statement does not violate ECL syntax rules.

  • The following are resolved by the OS 2200 LSAM and do not require definition:

    Token String Equates To


    ????????OPCON-JOBID???????? Full OpCon Job ID (27 Characters) ???JOB-ID??? OpCon Job ID (first 12 Characters) ?JOB-ID? OpCon Job ID (first 8 Characters) ?RNID? Job's Run ID (6 Characters)

    : OS 2200 Token Resolution