Defining and Managing JCL for a Job

#### Search Results

Search

# Defining and Managing JCL for a Job

A job needs job control language (JCL) instructions to perform a task. The required JCL is contained in the JCL member of a library/file of the operating system, or in a Natural object contained in a Natural library/system file.

This section provides information on defining JCL for a job master and editing the JCL source referenced by a job.

Note
FTP jobs do not have a standard JCL definition. They have an FTP parameter definition instead.

This document covers the following topics:

- Using Job Control in Entire Operations

- Dynamic JCL Generation (JCL Location MAC)

- Job Control for Jobs under BS2000

- Job Control for Jobs under UNIX

- Job Control for Jobs under Windows

- Defining Master JCL for a Job

- Displaying Master JCL

- JCL Locations

- Defining Operating System Dependent JCL Specifications

- Handling JCL during Job Submission

- Symbol Replacement in JCL

- Pregenerating Active JCL

#### Related Topics:

- Editing Master JCL and Natural Sources

- Regenerating Active JCL in the section Active Job Networks

## Using Job Control in Entire Operations

Entire Operations handles JCL as follows:

- Job Master Control
  Entire Operations used JCL in its original format on the original storage medium. The usual JCL storage locations of the various operating systems are supported. The source texts for dynamic JCL generation are also considered job master control.

- Active Job Control
  Entire Operations used the actual JCL submitted to the operating system for execution. It is produced from the master JCL when the job or network is activated. The symbols are replaced with values from the active symbol table. If it is dynamic JCL, the generation is performed at this time. The active JCL is stored in the active Entire Operations database.

- Pregenerated Active Job Control
  For reasons of performance, it might be necessary to generate active JCL in advance. See also Pregenerating Active JCL.

  JCL must be pregenerated again when:

  - The definition of the master JCL storage has been modified;

  - The master JCL has been edited;

  - The corresponding symbol table has been modified.

- Submitted Job Control - Header Information
  Entire Operations inserts a header with Entire Operations environment information as a comment into the submitted JCL.

  For UNIX, the header is inserted into the frame script.

  For Windows, the header is inserted into the frame BAT file.

- Submitted Job Control - Environment Variables for UNIX and Windows
  The generated and submitted JCL frame script (UNIX) or frame BAT file (Windows) can contain predefined symbols provided as environment variables. For details, see Reserved Symbols for UNIX and Windows Environment Variables in the section User Exits.

## Dynamic JCL Generation (JCL Location MAC)

When defining a job within a network, you can specify that its JCL is to be generated dynamically either at job activation time or at job submission time.

Dynamic JCL generation is achieved by using the Entire Operations edit macro function. The text strings contained in the JCL can contain escape characters (see Symbol Escape Characters) followed by variables that are replaced by their current values during dynamic generation.

These current values are taken from a symbol table which must contain the current values to be substituted. The symbol table to be used can be determined by choosing the Usable Symbol Tables function from the context menu of a network or job node (see Listing Usable Symbol Tables).

If any symbol specified in the dynamic JCL is not found in the symbol table defined for the job, the symbol is searched for in the symbol table next in the search hierarchy for symbol tables (see Symbol Table Types and Symbol Search Order.

Additionally, Entire Operations passes predefined symbols from the parameter section to the dynamically generated program, such as job owner, network name, current job name and original scheduling date. The same applies to Natural system variables such as `*DATE`, `*TIME` and `*USER`. As these parameters can be replaced in any part of the JCL, different JCL configurations can be generated depending on time, date, user ID etc.

Entire Operations provides dynamic JCL generation for all supported operating systems (z/OS, z/VSE, BS2000, UNIX and Windows) as shown in the following examples.

This section covers the following topics:

- Example 1: Dynamic JCL in a z/OS Environment

- Example 2: Dynamic JCL in a BS2000 Environment

- Example 3: Dynamic JCL in a UNIX Environment

#### Related Topics:

- Handling Macro Sources for Dynamic JCL Generation

### Example 1: Dynamic JCL in a z/OS Environment

The following is the symbol table specified for the macro program:

Symbol Name | Current Value
--- | ---
STEPLIB | SN.SYSF.SOURCE
CLASS | G

The variable from the parameter section is assumed to have the following value:

P-OWNER | NET1

The system variables are assumed to have the following values:

*TPSYS | COMPLETE
*DEVICE | BATCH
*INIT-USER | SN

The following is a macro Natural program including a parameter section and JCL with the escape character (`#`) followed by variable names from the symbol table:

    # DEFINE DATA PARAMETER USING NOPXPL-A
    # LOCAL /* MUST BE CODED
    # END-DEFINE
    //SNMAC4 JOB ,#P-OWNER,MSGCLASS=X,CLASS=#CLASS //STEP01 EXEC
    PGM=NOPCONTI,PARM='C0004' //STEPLIB  DD DISP=SHR,DSN=#STEPLIB
    //* DEVICE: *DEVICE, INIT-USER: *INIT-USER //* TPSYS: *TPSYS
    # IF CLASS = 'G'
    //* THE MSGCLASS IS REALLY 'G'
    # ELSE
    //* ANOTHER MSG-CLASS FOUND
    # END-IF
    //*

The resulting dynamically generated JCL will be:

    //SNMAC4 JOB ,NET1,MSGCLASS=X,CLASS=G
    //STEP01 EXEC PGM=NOPCONTI,PARM='C0004' //STEPLIB  DD
    DISP=SHR,DSN=SN.SYSF.SOURCE //* DEVICE: BATCH, INIT-USER: SN
    //* TPSYS: COMPLETE
    //* THE MSGCLASS IS REALLY 'G'
    //*

### Example 2: Dynamic JCL in a BS2000 Environment

The fields taken from the `DB-INFO` view are assumed to have the following values after the `FIND` statement:

Field | Value
--- | ---
NUCLEUS | 055
LP1 | 1000
NU1 | 100
ACCOUNT | EXAMPLE
NH1 | 4000
MSG | FHL
VERSION | 524

The variables taken from the parameter section have the following current values:

Variable | Value
--- | ---
P-OWNER | OS
P-JOB | NUC055
P-EXECUTION-NODE | 055

No symbol table was defined for this example job.

The following is the example JCL written using the edit macro function, including variables to be substituted from the `DB-INFO` view and the parameter section. Variables are preceded by the escape character (`#`):

    # DEFINE DATA PARAMETER USING NOPXPL-A
    #  1 L-JOB
    # 1 REDEFINE L-JOB
    # 2  L-JOB-A    (A3)
    # 2  L-JOB-NUC  (N3)
    # LOCAL   /* LOCAL VARIABLES START HERE
    # 1 DB-INFO VIEW OF DB-INFO
    # 2  NUCLEUS
    # 2  LP1
    # 2  NU1
    # 2  ACCOUNT
    # 2  NH1
    # 2  MSG
    # 2  VERSION    /* E.G. 524
    # 1 LWP  (N7)
    # 1 NUC  (N3)
    # 1 SPOOL  (A10) INIT <'NOSPOOL'>
    # END-DEFINE
    # *
    # MOVE P-JOB TO L-JOB-A
    # MOVE P-EXECUTION-NODE TO NUC
    # F1. FIND DB-INFO WITH NUCLEUS = NUC
    /.NUC NUC LOGON #P-OWNER,#ACCOUNT
    /OPTION MSG=#MSG
    /REMARK
    /REMARK  NUCLEUS #NUC
    /REMARK
    /SYSFILE  SYSLST = NUC NUC..LST.NUC
    /SYSFILE  SYSDTA = SYSCMD
    /FILE  ADA VERSION..MOD,LINK=DDLIB
    /FILE  *DUMMY,LINK=DDLOG
    /FILE  *DUMMY,LINK=DDSIBA
    /FILE  ADA NUC..ASSO,LINK=DDASSOR1,SHARUPD=YES
    /FILE  ADA NUC..DATA,LINK=DDDATAR1,SHARUPD=YES
    /FILE  ADA NUC..WORK,LINK=DDWORKR1,SHARUPD=YES
    /EXEC  (ADARUN,ADA VERSION..MOD)
    # COMPUTE LWP = F1.LP1 * (F1.NU1 + 100)
    ADARUN PROG=ADANUC,LP=F1.LP1,LU=65535,LWP=#LWP ADARUN
    DB=#NUC,NU=#NU1,NC=20,TT=600,TNAE=1800 ADARUN NH= NH1
    /SYSFILE  SYSLST = (PRIMARY)
    /SYSFILE  SYSDTA = (PRIMARY)
    /SYSFILE  SYSOUT = (PRIMARY)
    /LOGOFF  SPOOL
    # END-FIND

The resulting dynamically generated JCL will be:

    /.NUC055 LOGON OS,EXAMPLE
    /OPTION MSG=FHL
    /REMARK
    /REMARK  NUCLEUS 055
    /REMARK
    /SYSFILE  SYSLST = NUC055.LST.NUC
    /SYSFILE  SYSDTA = SYSCMD
    /FILE ADA524.MOD,LINK=DDLIB
    /FILE *DUMMY,LINK=DDLOG
    /FILE *DUMMY,LINK=DDSIBA
    /FILE ADA055.ASSO,LINK=DDASSOR1,SHARUPD=YES
    /FILE ADA055.DATA,LINK=DDDATAR1,SHARUPD=YES
    /FILE ADA055.WORK,LINK=DDWORKR1,SHARUPD=YES
    /EXEC (ADARUN,ADA524.MOD)
    ADARUN PROG=ADANUC,LP=1000,LU=65535,LWP=200000 ADARUN
    DB=055,NU=100,NC=20,TT=600,TNAE=1800 ADARUN NH=4000
    /SYSFILE  SYSLST = (PRIMARY)
    /SYSFILE  SYSDTA = (PRIMARY)
    /SYSFILE  SYSOUT = (PRIMARY)
    /LOGOFF NOSPOOL

Note
Any JCL generated at activation time using the macro language can be modified by the user until the job is actually submitted. Of course this modification is valid only for the current network run.

### Example 3: Dynamic JCL in a UNIX Environment

The following example illustrates dynamic symbol replacement within a Bourne shell script (escape character `§`):

    #
    # Bourne shell script for checking the number of users
    # entered in /etc/passwd.
    # If more than §USER-LIMIT entries appear,
    # the script will be ended with exit 1.
    #
    #!/bin/sh
    set -x
    USER_COUNT='wc -l < /etc/passwd'
    echo Number of users on node 'hostname' : $USER_COUNT
    if test $USER_COUNT -gt §USER-LIMIT
    then
        echo USER_COUNT_WARN
        exit 1
    else
        echo USER_COUNT_OK
    fi

The symbol table to be used should appear as follows:

Symbol Name | Current Value
--- | ---
USER-LIMIT | 100

The result is the following executable shell script:

    #
    # Bourne shell script for checking the number of users
    # entered in /etc/passwd.
    # If more than 100 entries appear,
    # the script will be ended with exit 1.
    #
    #!/bin/sh
    set -x
    USER_COUNT='wc -l < /etc/passwd'
    echo Number of users on node 'hostname' : $USER_COUNT
    if test $USER_COUNT -gt 100
    then
        echo USER_COUNT_WARN
        exit 1
    else
        echo USER_COUNT_OK
    fi

Note
Any JCL generated at activation time using the macro language can be modified by the user until the job is actually submitted. Of course this modification is valid only for the current network run.

## Job Control for Jobs under BS2000

This section covers the following topics:

- Naming Conventions for Work Files

- User Exit for Work File Names

### Naming Conventions for Work Files

The name generation for work files under BS2000 is described in the section Naming Conventions for Work Files of the Installation and Setup documentation.

### User Exit for Work File Names

Names of BS2000 work files can also be generated via an exit (see Generating SYSOUT File Names for BS2000 in the section API Routines).

## Job Control for Jobs under UNIX

The environment variable `$EOR_WORK` of Entire System Server/UNIX contains the name of the Entire Operations work directory. Within this directory, the work files are hierarchically stored.

## Job Control for Jobs under Windows

This section covers the following topics:

- Job Control Characteristics under Windows

- Components Required

- Executing Operating System Functions

- File Names

- SYSOUT Redirection

- Entire Operations Work Directory

- Environment Variables

- Job Control (JCL)

- Job Start and Job Control

- End-of-Job Check

- End-of-Job Actions

### Job Control Characteristics under Windows

The job control system Entire Operations also runs in a Windows environment, with the following characteristics:

- Operating system neutral modeling of job networks.

- Entire Operations functionality and flexibility is also transparently available on Windows.

- Support of DOS batch files and executables (EXE).

- It is not necessary to directly enter Windows DOS commands.

- Can also run in mixed mainframe/Windows/UNIX environments.

- Job control on several Windows machines at the same time.

### Components Required

- #### Entire Operations Monitor

  The Monitor can run under the operating systems BS2000, z/OS, z/VSE or UNIX, concurrently controlling jobs executed under BS2000, z/OS, z/VSE and UNIX.

- #### Entire System Server - For Mainframes, UNIX and Windows

  Required to access mainframe, UNIX or Windows operating systems.

  On every machine to be controlled, an Entire System Server/Windows server has to be installed. This is installed as a Windows service and is administrated with the Windows services administration.

- #### Entire Net-work/EntireX Broker

  Used as the transport layer.

### Executing Operating System Functions

For executing operating system functions, there is a server of type Entire System Server/Windows on each Windows node. This server runs as a background Windows process.

The Entire Operations Monitor and the Entire Operations online application use the following components for server communication:

- The System Automation Tools (SAT) communication layer

- The EntireX Broker for transmitting client/server requests

- Entire Net-work as the transport layer

- Up to 740 Windows nodes can be served concurrently

### File Names

As there is no backslash (`\`) available on mainframes, Windows file names can be written with a slash (`/`) as an alternative as well if the character sequence `+F+` directly precedes the file name. This applies to file names within JCL as well.

#### Example:

Original Windows | c:\jcl\script1.bat
Alternative representation | +F+c:/jcl/script1.bat

### SYSOUT Redirection

From the Entire Operations Monitor, all jobs are started which redirect their output to a file. The SYSOUT files are stored in the Entire Operations work directory. If the job is repeated, the old SYSOUT file is renamed.

### Entire Operations Work Directory

The Entire System Server/Windows environment variable `%EOR_WORK%` contains the name of the Entire Operations work directory. Within this directory, the work files are stored hierarchically.

The name generation for work files under BS2000 is described in Naming Conventions for Work Files Created by Entire Operations, Windows in the section Installing Entire Operations on Mainframes in the Installation and Setup documentation.

The name of the work directory for an active network is available in the predefined symbol `P-NADIR`. You may store application-specific work files there, provided there are no naming conflicts with files created by Entire Operations.

Work files created by Entire Operations or by the application are deleted by the Entire Operations Monitor on network or job deactivation.

### Environment Variables

You can use Windows environment variables freely within file names. This corresponds to the behavior of BAT files. You can combine environment variables and variables from symbol tables.

### Job Control (JCL)

The Windows JCL can be stored in any place. Among other places, it can be stored in Natural text objects or in mainframe files. Symbol replacement and JCL generation (jobs with JCL location `MAC`) are available.

### Job Start and Job Control

The Entire Operations Monitor starts jobs based on conditions and on time. Accounting data is retrieved and stored. You can manually cancel the job from the online environment.

### End-of-Job Check

Entire Operations adds some echo commands to the Windows job control. This allows control of certain messages in the SYSOUT:

- Starting and ending message with timestamp

- Elapsed job time

These messages are used to check whether a job did run completely. Additionally, accounting information is retrieved. For checking the job, strings can be searched for in SYSOUT and End-of-Job check routines can be used.

### End-of-Job Actions

You can send messages (for example by e-mail) to other users from the Windows node. In the Windows node definition, a program for sending mail can be defined. It is required that this program can be started from the DOS command prompt. One example for such a program is the shareware wsendmail. All other forms of news broadcasting, such as the Entire Operations Mailbox, can still be used.

You can define printing of files and of SYSOUT lists as an End-of-Job action. For each Windows node, a Windows print command with a variable for the file name can be defined. User exits can help start further actions.

## Defining Master JCL for a Job

To define master JCL for a Job

1. In the Maintenance Job Master window, open the tabbed page JCL Definition:

2. Make your definitions. The input fields and special functions available are explained in Fields: Master JCL Definition and Functions: Master JCL Definition.

3. Choose OK to save your definitions.

If you want to edit the defined JCL, proceed as described in Editing Master JCL and Natural Sources.

This section covers the following topics:

- Fields: Master JCL Definition

- Functions: Master JCL Definition

### Fields: Master JCL Definition

The fields on the JCL Definition page are described in the following table:

Field | Description
--- | ---
Use symbol as JCL node | Select this check box if you want to use a symbol for a JCL node (see below).
JCL Location | Type of JCL storage location. For selection options, see JCL Locations. In a network definition, this field serves as a default for the entire network. See also Fields: Network Definition in the section Network Maintenance.
JCL Node | JCL for the job is read from this node. The job is started on the execution node. The default is the value specified in the job network definition (see Fields: Network Definition), which can be overwritten here. You can define the JCL node as a symbol if the Use symbol as JCL node option is marked. For details, see Symbols in Node Definitions in the section Symbol Table and Symbol Maintenance.
JCL Load Mode | Possible selection options:
At activation | Load JCL at activation time (default). Note If the job is defined as cyclic, the job's active JCL will be loaded only once. Only Symbol Replacement with Symbol Escape Characters will be performed before each submission.
At submission | Load JCL at submission time. Notes: JCL load errors are detected very late. Network execution might slow down because of the time necessary for JCL load before submission. JCL pregeneration also works with JCL loading at submission time. If resources are defined, they are allocated at submission time. If the JCL loading at submission time fails, the allocated resources are freed immediately. JCL loading at submission time is also intended to allow you the generation of Macro JCL as late as possible. The JCL of a cyclic job will be loaded again before each Cyclic execution. For other types of JCL, it is still recommend to use activation time symbol replacement, which causes less system overhead.
File/Natlib | Storage type of the JCL corresponding to the job type. For Natural programs and dynamic JCL (storage location `NAT`): the Natural library where the program or the variable JCL resides. The Natural library must reside in the FUSER system file and must not have the same name as the SYSEOR system library. For z/VSE: library and sub-library associated by a period (`.`). For all others: the file name. You can select the required library or file from the drop-down list box. For BS2000: The default pubset is stripped from the file name prior to storing it. This allows easier migration to another default pubset. For UNIX: Be aware of upper and lower case. You may use environment variables and symbols within names. Symbols may be used. If a JCL file contains the activation escape character (see Escape Characters), symbol replacement is performed: When editing JCL (temporary, using the symbol table master); When loading JCL (permanently, using the active symbol table). For detailed information, see the section Symbol Table and Symbol Maintenance.
Member | Name of the Natural object or library/file member of the operating system that contains the JCL. This applies to all JCL locations which support members: see List of JCL Locations. This field cannot be used and is protected for other JCL locations. When you add a new job definition, the name of the job is entered in this field by default. You can select the required member from the drop-down list box. New Members: You can also enter the name of a non-existing member if, for example, no JCL has yet been defined for the job. Entire Operations accepts the member name assuming a member with this name will be created. Before activating a network and before starting a job, Entire Operations checks whether a member has been defined. If there is no member, an error message is issued. Symbols may be used. If a JCL file contains the activation escape character (see Escape Characters), symbol replacement is performed: When editing JCL (temporary, using the symbol table master); When loading JCL (permanently, using the active symbol table). For detailed information, see the section Symbol Table and Symbol Maintenance. Note for BS2000: JCL location `PRC` (Callable procedure): If no member is specified, the JCL file must be a BS2000 sequential file.
VolSer | Volume serial of the file. Only required if the file has not been cataloged (z/OS only).
Password | The file password if the file has been protected by a password.
OS Specials | Operating system-dependent input fields: see Fields: Operating System Specials for JCL.

### Functions: Master JCL Definition

The following special function is available on the JCL Definition page:

Function | Description
--- | ---
Edit | Opens the editor for the source entered in the Member field or the file entered in the File/Natlib field depending on the specified JCL location. This command is only available if you are authorized to edit the specified source and if the Apply and OK buttons are disabled in the window. This command corresponds to the Edit Master JCL or Edit Active JCL function available from the context menu of a selected job instance. See also Editing Master JCL and Natural Sources.

## Displaying Master JCL

To display the master JCL source defined for a job

- In the object workspace, select a Job Master instance and choose Browse Master JCL from the context menu.

  A Browse window like the Edit window opens displaying the source of the JCL.

## JCL Locations

This section covers the following topics:

- List of JCL Locations

- Restrictions for Job Types

- Location on another Node

- Replacing Symbols

- JCL Location PRC: BS2000 Procedure

- JCL Frames for BS2000 DO Procedures

### List of JCL Locations

Entire Operations offers a broad range of possible locations for its original (master) JCL.

The following table describes the physical locations you can select for JCL from the JCL location drop-down list box on the JCL Definition page.

The locations `NAT` (Natural source) and `MAC` (Macro Natural source) are available on all operation systems supported by Entire Operations. Other locations are available for individual operating systems only as indicated in the following table:

JCL Location/Selection Option | Applies to Operating System | Description
--- | --- | ---
blank field (No JCL required) | n/a | None (no JCL required).
`BS2` SAM or ISAM | BS2000 | SAM or ISAM file. See also BS2000 in Fields: Operating System Specials for JCL.
`EXE` Executable program | UNIX, Windows | Executable, for direct file execution. Not intended for shell scripts or BAT files. You can pass parameters to the executable file with the `CMDLINE-job` reserved symbol. See Reserved Symbols for Command Line Parameters in the section Symbol Table and Symbol Maintenance.
`LIB` Librarian | z/OS | Librarian.
`LMS` LMS library | BS2000 | LMS library. See also BS2000 in Fields: Operating System Specials for JCL.
`MAC` Macro Natural source | all | For macro JCL. A Natural source object is used.
`NAT` Natural source | all | Natural source object. See also Restriction for Job Types.
`PDS` Partitioned data set | z/OS | Member of a partitioned data set. See also Restriction for Job Types.
`PRC` Callable procedure | BS2000 | BS2000 procedure. See JCL Location PRC: BS2000 Procedure for more information.
`RDR` z/VSE reader queue | z/VSE | z/VSE reader queue for job type `STC` (Started Task).
`VSE` z/VSE sublibrary | z/VSE | z/VSE member in z/VSE sublibrary.
`TXT` Text file | UNIX, Windows | Text file. See also UNIX and Windows in Fields: Operating System Specials for JCL.

### Restrictions for Job Types

- Jobs of the type `STC` (Started Task) must have the location `PDS` (Partitioned data set) on z/OS.

- Jobs of the type `NAT` (Natural Program) must have the location `NAT` (Natural source).

- Jobs of the type `DUM` (Dummy Job) must not have any JCL location.

- Jobs of the type `FTP` (File Transfer Job) do not require a JCL location. Entire Operations generates the FTP JCL itself, depending on the FTP parameters defined on the FTP Definition page.

During definition, it is checked whether the defined JCL exists at all. If the JCL cannot be found, a warning appears in the Job JCL Definition (Master) window.

### Location on another Node

The JCL can be saved on another machine, not identical with the executing machine and even on another operating system, not identical with the executing operating system.

### Replacing Symbols

In all JCL locations, you can easily replace symbols as described in Symbol Replacement in the section Symbol Table and Symbol Maintenance.

### JCL Location PRC: BS2000 Procedure

If this location has been defined, Entire Operations generates a BS2000 ENTER job in the active JCL calling this procedure.

The following rules are applied:

- If no JCL member is specified, the JCL file must be a BS2000 sequential file. If a JCL member is specified, the JCL file must be a BS2000 LMS library.

- The BS2000 job name adopts the Entire Operations job name and if it is longer than 8 characters, it cuts the name to 8 characters.

- SDF statements (`CALL-PROC`) are used.

- The symbol table for which the job has been defined must contain all parameters of the BS2000 procedure. The symbol values are used for calling the BS2000 procedure.

- Positional and keyword parameters are supported.

- Numbers and names of the parameters are automatically retrieved from the procedure (`PROC / BEGIN-PROC` statement).

- The generated `CALL-PROCEDURE` statement has the parameter `LOGGING=*YES`.

- BS2000 job submissions are performed with the generated line `/MODIFY-SDF-OPTIONS CONTINUATION=*NEW-MODE`.

### JCL Frames for BS2000 DO Procedures

For BS2000 procedures, a user-defined JCL frame can be used. It must be saved under the name PRCFRAME in the library SYSEORU. If PRCFRAME is not found in SYSEORU (or in SYSEOR, for compatibility), Entire Operations generates a standard frame.

#### Special Commands

Command | Description
--- | ---
`#ESC-FRAME escape-character` | Defines the escape character the JCL frame uses to replace symbols. This command must be at the top and is compulsory.
`#CALL-PROC` | The procedure call (`/CALL-PROC`) is generated here. Adding User-Defined Parameters to the /CALL-PROC Statement It is possible to add user-defined parameters to the `CALL-PROC` statement in the PRCFRAME text object. The following applies: The `#CALL-PROC` line must look like `#CALL-PROC -`. The minus sign (`-`) indicates a continuation. In the generated JCL, it will be placed in column 72. The user-defined continuation(s) follow the `#CALL-PROC` line. They must begin with the following characters: `/ ,`. Example:
    #CALL-PROC -
    / ,LOGGING=YES

#### Example of PRCFAME Contents

    #ESC-FRAME §
    /.SN§P-RUN LOGON SN,1
    /REMARK === PRC FRAME EXAMPLE
    /REMARK §AAAA YYYYYYYYYYYYY
    #CALL-PROC
    /STA L
    §BBBB
    /LOGOFF

Notes:

1. All symbols used in the JCL frame must be contained in the active symbol table of the job. The active symbol table must continue to contain all symbols for calling the procedure.
2. If a symbol does not exist, job activation is discontinued.

## Defining Operating System Dependent JCL Specifications

Some operating systems or JCL locations may require some additional definitions.

To define JCL parameters specific to an operating system

- On the JCL Definition page, enter valid values in the input fields provided for the relevant operating system in the OS Specials section.

  The fields contained in the window are explained in Fields: Operating System Specials for JCL.

This section covers the following topics:

- Fields: Operating System Specials for JCL

### Fields: Operating System Specials for JCL

The operating system specific input fields provided in the OS Specials section of the JCL Definition page are described in the following table.

Operating System | Field | Description
--- | --- | ---
BS2000 | Default User ID | Valid logon user ID defined for BS2000. This ID has no meaning for other operating systems. Unqualified file and job variable names in this job definition are prefixed with this BS2000 user ID. Note The user ID TSOS can be defined only if the user defining the ID is working under TSOS. See also the default setting User ID Definition described in Defaults for Other Settings in the Administration documentation.
JCL User ID | If this field is not empty, the JCL is loaded under the rights of this BS2000 user ID and may be overridden by specific definitions. TSOS may only be defined, if the defining user is working under TSOS. Default: If this field is left blank, the user ID from the fully qualified JCL file name is used as JCL User ID. Symbol replacement is performed in this field if the activation escape character or the submission escape character is used. See also the default setting of User ID Definition (Defaults for Other Settings, Administration documentation), and the sections Operating System User IDs and Default User ID Determination.
Member Version | Applies to the JCL locations `LMS` (LMS library) and `PRC` (Callable procedure). Version of the specified LMS member. This must be exactly the same as given in LMS itself. Leading zeroes must be specified in the same way.
Member Type | Applies to the JCL locations `LMS` (LMS library) and `PRC` (Callable procedure). LMS member type. Possible selection options:
Source program
Procedure or ENTER job
Document
Data of any format
z/OS | JCL User ID | JCL in z/OS is loaded under this user ID by the Entire Operations Monitor. You may define this field only if you are logged on to the JCL node with the same user ID. Symbol replacement is performed in this field if the activation escape character or the submission escape character is used. See also the default setting User ID Definition (Defaults for Other Settings, Administration documentation), and the sections Operating System User IDs and Default User ID Determination.
VolSer | Volume serial number of the file where the JCL resides. Only required if the file has not been cataloged.
z/VSE | Library | Name of the z/VSE library within the selected file.
Sublib | Name of the z/VSE sublibrary within the selected file. You can select a name from the drop-down list box.
Member | Name of the member where the JCL for the job resides. You can select a name from the drop-down list box.
Member Type | Member type of the z/VSE library.
Volser | Volume serial number of the file where the JCL resides. This is a required parameter for z/VSE.
VSAM Catalog | Name of the VSAM catalog for the selected file.
UNIX and Windows | JCL User ID | The Entire Operations Monitor will load JCL with the access rights of this user ID. Symbol replacement is performed in this field if the activation escape character or the submission escape character is used. See also the default setting User ID Definition (Defaults for Other Settings, Administration documentation), and the sections Operating System User IDs and Default User ID Determination.
JCL Group | UNIX group or Windows domain (optional). Symbol replacement is performed in this field if the activation escape character or the submission escape character is used. UNIX: If this field is blank, the user's default UNIX group (from `/etc/passwd`) is used. Otherwise, this field must contain one of the UNIX groups, which is visible in the output of the UNIX `groups` command. Windows: The Windows domain to be used for the logon.

## Handling JCL during Job Submission

This section covers the following topics:

- JCL Modifications during Job Submission

- Trigraph Encoding for JCL Submission on UNIX and Windows

#### Related Topics:

- Maintaining Active JCL (Job Control Language) in the section Maintaining Active Jobs and Networks

### JCL Modifications during Job Submission

Jobs defined and scheduled in Entire Operations are submitted automatically under the control of the Entire Operations Monitor. During the submission process, the submitted JCL can be handled in any of the following ways:

- Completion or modification of the job JCL according to the Entire Operations defaults;

- Checking of all submitted JCL by a global user exit (to be defined in the Entire Operations defaults; see the Administration documentation);

- Insertion of header information into the submitted JCL. This is always performed if the Generate Header in submitted JCL option is activated in the Entire Operations defaults (see Defaults for Other Settings in the Administration documentation).

- Insertion of information on replaced symbols if the Log Symbol Values in submitted JCL option is activated in the Entire Operations defaults (see Defaults: System/Log Files in the Administration documentation).

- For z/OS only:
  If a submission time symbol replacement error occurs, a JCL error is forced to prevent the job from executing. Lines similar to the following force a JCL error:

  `// ###### Entire Operations Symbol Replacement Error ######`

  The job remains in an error status such as the following:

  `JobId 51058 - Symbol Replacement Error`

  End-of-Job processing is not completed, because this is treated as a submission error.

See also Working with Entire System Server Nodes in the section Operating System User ID.

Related Topic:

- Header and Symbol Information in SYSOUT in the section Maintaining Active Jobs and Networks

### Trigraph Encoding for JCL Submission on UNIX and Windows

Trigraph encoding is used to avoid translation failures during ASCII/EBCDIC text conversion. An ASCII character for which no equivalent EBCDIC character exists is then substituted by a trigraph and the text can be encoded successfully.

Entire Operations uses trigraphs when generating JCL for UNIX and Windows. For Entire System Server execution nodes on UNIX and Windows, trigraph encoding is switched on by default using the question mark (`?`) as the default escape character.

> Switching Trigraph Encoding On and Off

>   You can switch on and off trigraph encoding in the JCL with the following meta commands:

>   `#EOR-TRIG=YES` | Enables trigraph encoding.
>   `#EOR-TRIG=NO` | Disables trigraph encoding.

>   Each meta command must be in a single line as shown in the following example for UNIX and Windows.

>   Defined JCL:

>       ...
>       echo '??( test ??)'
>       #EOR-TRIG = OFF
>       echo '??( test ??)'
>       #EOR-TRIG = ON
>       ...

>   Submitted JCL:

>       ...
>       echo '[ test ]'
>       echo '??( test ??)'
>       ...

> Supported UNIX and Windows Trigraphs

>   Entire System Server execution nodes on UNIX and Windows support the trigraphs listed in the following table. A trigraph always begins with two escape characters; the table below assumes the question mark (`?`) to be the default escape character.

>   ASCII | Trigraph | Remarks
>   --- | --- | ---
>   [ | ??( |
>   \ | ??/ |
>   ] | ??) |
>   ^ | ?? ' |
>   { | ??< |
>   | | ??_ |
>   } | ??> |
>   ~ | ??- |
>   @ | ??% |
>   ` | ??; |
>   ! | ??: |
>   \f | ??+ | Form feed
>   \t | ??& | Tab

## Symbol Replacement in JCL

Symbols for replacement can be defined for all storage locations of master JCL.

Escape characters for symbols can be assigned system-wide, and they can also be defined individually for each job. Defaults for escape characters can be defined for each operating system.

Escape characters for symbol replacement must not conflict with other characters used in the JCL.

For detailed information, see the following sections in Symbol Table and Symbol Maintenance:

- Defining Symbols and Symbol Values

- Symbol Replacement and Defining Escape Characters

## Pregenerating Active JCL

For performance reasons, it might be necessary to pregenerate active JCL to be used for job submission. This function is conceived mainly for macro jobs, whose dynamic JCL generation can become time-consuming, because macro language must always be executed. JCL can also be pregenerated for all other job types.

Note
In the case of a resubmission of the active job, the pregenerated JCL is not reloaded if the active JCL of the job has been edited in the meantime.

To pregenerate active JCL

- In the object workspace, select a Job Master instance and choose Pre-generate Active JCL from the context menu.

  If no generation errors occur, a message indicates that active JCL is pregenerated for the job.

This section covers the following topics:

- Editing Pregenerated JCL

- Removing Pregenerated JCL

#### Related Topic:

- Regenerating Active JCL in the section Active Job Networks

### Editing Pregenerated JCL

This function allows editing the pregenerated JCL.

To edit pregenerated JCL

1. In the object workspace, select a Job Master instance for which pregenerated active JCL exists.

2. Choose Edit pre-generated Active JCL from the context menu.

   An Edit window opens where you can change the pregenerated JCL as required.

   See also Editing Master JCL and Natural Sources.

### Removing Pregenerated JCL

To remove pregenerated active JCL

1. In the object workspace, select a Job Master instance for which pregenerated active JCL exists.

2. Invoke the context menu and choose the Remove pre-generated Active JCL function.

   The message `Pregenerated JCL deleted` indicates that the pregenerated JCL has been removed.

### On this page

- Using Job Control in Entire Operations
- Dynamic JCL Generation (JCL Location MAC)
- Job Control for Jobs under BS2000
- Job Control for Jobs under UNIX
- Job Control for Jobs under Windows
- Defining Master JCL for a Job
- Displaying Master JCL
- JCL Locations
- Defining Operating System Dependent JCL Specifications
- Handling JCL during Job Submission
- Symbol Replacement in JCL
- Pregenerating Active JCL