Skip to content
CA Datacom Tools - 15.0
Documentation powered by DocOps

Running in a Batch Environment

Last update March 8, 2017

This chapter describes how to run a CA Ideal™ for CA Datacom® in a batch environment, including:

  • The capabilities of CA Ideal™ for CA Datacom® in batch
  • The required job control language (JCL) records necessary to run CA Ideal™ for CA Datacom® in batch
  • The results (output) of a batch run
  • Submitting a batch job

Contents

Capabilities of CA Ideal™ for CA Datacom® in Batch

You can use batch CA Ideal™ for CA Datacom® to perform any CA Ideal™ for CA Datacom® service that is initiated by a command and that does not require interaction with the user. These include the following:

You cannot run services that require interaction with a user in batch. For example, the following command has insufficient syntax to complete the DUPLICATE command and returns a prompter:

DUPLICATE

In batch, the DUPLICATE command is terminated at this point since you cannot enter information into the prompter, and the next CA Ideal™ for CA Datacom® command in the job stream is executed. However, the following command works successfully in any environment, provided the entity exists.

DUPLICATE PANEL ORDFRM VERSION 2 NEXT VERSION

In addition, a program with any panel-processing PDL statements, such as TRANSMIT, cannot run in batch and terminates the run. If you use a DISPLAY command for index, session, or dataview option display, the command is treated like a PRINT command.

Note: Printing to a network printer (DESTINATION NET) is not allowed in batch.

Components of a Batch Job Stream

You can use CA Ideal™ for CA Datacom® members to build and store job streams (JCL records and CA Ideal™ for CA Datacom® commands) online and to submit job streams. You can also use any other means suitable for batch job submission to submit JCL for batch CA Ideal™ for CA Datacom®. Members are described fully in the section titled Data Members in the chapter “Data Members.”

Batch Job Stream in z/OS

An example in z/OS of a job stream to compile and run a program follows:

//COMP1 JOB . . .
//BATCH EXEC IDLBATCH,PARM.IDEAL='NOPRINT'
//IDEAL.SYSPRINT DD SYSOUT=(W,,SMAL)
//IDEAL.COMPLIST DD SYSOUT=A
//IDEAL.RUNLIST DD SYSOUT=A
//IDEAL.SYSIN DD *
SIGNON PERSON userid PASSWORD password PRODUCT IDEAL

SELECT SYSTEM DOC
COMPILE COMP1 VERSION 1 DESTINATION SYS name
RUN COMP1 VERSION 1 DESTINATION SYS name
OFF
//

In this example, the DESTINATION clause of the RUN command is shown as a system printer. This example also shows a DD record for a report where the ddname (COMPLIST) corresponds to the name of the compile report produced in this run.

You can monitor the status of a report directed to the output library by displaying the output library. As soon as the program starts to execute, the report's status in the library is CRTIN. When the status is READY, the report is released from the batch process.

The following standard JCL statements are used in the z/OS environment to execute CA Ideal™ for CA Datacom® in batch.

  • // JOB
    Identifies a standard JOB statement containing information about the job for the operating system.
    If your site uses an external security system to control access to a CA Ideal™ for CA Datacom®, the USER= parameter on this statement must specify a security ID that is authorized to access a CA Ideal™ for CA Datacom®. Do not include the CA Ideal™ for CA Datacom® SIGNON statement when external security is used.
  • // EXEC IDLBATCH,PARM.IDEAL='NOPRINT'
    Identifies a JCL PROC containing the CA Ideal™ for CA Datacom® batch JCL for a batch session. These statements are described in the following paragraphs. IDLBATCH is the default name of the PROC as installed. See your CA Ideal™ for CA Datacom® Administrator for the correct name for your site.
    The parameter PARM.IDEAL='NOPRINT' is optional. If you leave out this parameter or assign a null value ('') to it, the SYSPRINT file contains a simulated CA Ideal™ for CA Datacom® panel as a response to each command in the batch job stream. Including the parameter with the value NOPRINT suppresses the simulated panels and prints only the commands entered and the messages produced.
    You can use the COND parameter with an EXEC statement to check the value associated with a batch job step. You can use condition codes to ensure that no step runs unless the previous steps executed successfully.
    For example, you can define the following steps in a batch job:

     //STEP1 EXEC IDLBATCH

       ...

       RUN ABC PROD               :May set $RC to 12.

       OFF

     //STEP2 EXEC,COND=(12,LE)

       ...                        :Bypass if 12 is

       RUN XYZ PROD               :less than or equal to the

       OFF                        :return code from any

                                  :prior step.

     //STEP3 EXEC,COND=(12,LE)

       ...

       RUN PQR PROD

       OFF

    //

    If program ABC encounters an error that sets the $RETURN-CODE to 12, then programs XYZ and PQR do not run. If the $RETURN-CODE is set to 12 in program XYZ, program PQR does not run in STEP 3. For a list of condition codes, see Processing Programs.

  • //SYSIN DD
    Identifies a data set containing CA Ideal™ for CA Datacom® commands executed (normally //SYSIN DD *, which means immediately following). The CA Ideal™ for CA Datacom® commands are entered in a sequence that simulates an online session. For example, a SIGNON command is the initial command that simulates the signon panel and OFF is the final command.
  • //SYSPRINT DD (optional)
    Identifies a data set (normally SYSOUT) meant to receive the listing of the CA Ideal™ for CA Datacom® batch session. This output includes an image of each command and resulting panel with one page per transaction. This statement is provided in the IDLBATCH PROC, but you can override it.
  • //report DD (optional)
    You are required to write a DD statement for each report generated by a program run in batch. The ddname must be the unique one- to eight-character report name. These DD statements are not provided in the procedure named in the EXEC record. If no DD statement is provided for the report, then the DD statement //AUXPRINT DD SYSOUT=A, which is supplied in the IDBATCH PROC, is used for all reports.
    If you do not supply DD records for reports and a RUN produces several reports in parallel, the reports can be intermingled in the AUXPRINT listing.
  • //COMPLIST DD (optional)
    Identifies a data set (normally SYSOUT) meant to receive the compilation listing of all programs compiled in the batch sequence of commands. This statement is provided in the IDLBATCH PROC, but you can modify it.
  • //RUNLIST DD (optional)
    Identifies a data set (normally SYSOUT) meant to receive data generated by a LIST statement in the procedure of a CA Ideal™ for CA Datacom® program. This JCL record is provided in IDLBATCH, but you can override it.
  • //PRTLIST DD (optional)
    Identifies a default data set (normally SYSOUT) to receive any data printed using CA Ideal™ for CA Datacom® PRINT commands. This JCL record is provided in IDLBATCH, but you can override it. If you use the NAME parameter in a PRINT command, the parameter specified indicates the alternate DD record name.
  • //seqfilename DD
    Identifies the one- to eight-character name for a sequential file used by an application. CA Ideal™ for CA Datacom® provides the ddname as the FILENAME in the dataview comment when the dataview is displayed.
    According to the rules of z/OS JCL, overriding DD statements must appear in the same order as the DD statements in IDLBATCH.

Components of a VSE Batch Job Stream

You can use CA Ideal™ for CA Datacom® members to build and store job streams (JCL records and CA Ideal™ for CA Datacom® commands) online and to submit job streams. You can submit JCL for batch CA Ideal™ for CA Datacom® through any other means suitable for batch job submission. See Data Members for a complete description of the CA Ideal™ for CA Datacom® member.

The following standard JCL records are used in a VSE environment to execute CA Ideal™ for CA Datacom® in batch.

* $$ JOB JNM=IDBATCH,PRI=n,USER='username',DISP=D
* $$ LST DISP=D,CLASS=L,LST=cuu...
* $$ LST DISP=D,CLASS=L,LST=cuu...
* $$ LST DISP=D,CLASS=L,LST=cuu...
* $$ LST DISP=D,CLASS=L
// JOB IDBATCH
// OPTION LOG,NODUMP
// EXEC PROC=IDLPROC
*****************************
* Assignments for sequential file dataviews and work areas
* for sorted reports. 
*****************************
// ASSGN SYS...,cuu
// ASSGN SYS...,cuu
// ASSGN SYS...,cuu
// EXEC IDBATCH,SIZE=80K,PARM='NOPRINT'
SIGNON PERSON username PSW psword 
COMPILE pgmname
RUN pgmname
OFF
/*
// EXEC LISTLOG
/*
/&
* $$ EOJ

There are three types of instructions in this job stream: operating system commands, spooling system commands, and CA Ideal™ for CA Datacom® commands.

VSE JOB control instructions all begin with the characters // . VSE JOB control interprets the commands beginning with an asterisk and followed immediately by a space (* ) as comments. POWER is the VSE JOB Input/Output spooling system. JOB Entry Control Language (JECL) commands all begin with the * $$ character string.

  • $$ JOB JNM=IDBATCH, PRI=n, USER='username', CLASS=c,DISP=D
    This statement identifies the job to POWER.
    • JNM=IDBATCH
      This job stream is identified to POWER as IDBATCH.
    • PRI=n
      Dispatching priority of this job is n.
    • USER='username'
      Used for accounting purposes. If your site uses external security to control access to CA Ideal™ for CA Datacom®, this parameter provides a security ID for the job stream.
    • CLASS=c
      Defines which VSE partition this job stream can execute in.
    • DISP=D
      Defines the disposition in the reader spool for the job stream. D submits the job stream for execution immediately and does not retain it in the reader queue (spool) after execution.
  • $$ LST DISP=D,CLASS=L
    This statement defines the output parameters for the VSE system log file.
    • DISP=D
      This parameter defines the disposition of the output in the POWER list queue. As in the DISP option for the JOB command, D releases the job stream immediately and does not retain it in the queue.
    • CLASS=L
      This parameter organizes the LIST queue. Use it with subsequent * $$ LST statements to logically separate the various CA Ideal™ for CA Datacom® outputs.
  • // JOB IDBATCH
    This is the first VSE job control command of the job stream. The job stream is identified as IDBATCH. All references to the JOB on the operator's console are to IDBATCH (not the POWER jobname).
  • // OPTION LOG,NODUMP
    The OPTION command sets execution options for this jobstep and all following jobsteps until a contrary option command is issued. LOG sets the request for all job control statements to list with the output; NODUMP suppresses the DUMP option.
  • // EXEC PROC=IDLPROC
    This statement copies a JCL procedure into the job stream. IDLPROC is an installed procedure to define all CA Ideal™ for CA Datacom® and user system files for batch.
  • * $$ LST DISP=D, CLASS=L,LST=cuu...
    These POWER statements keep CA Ideal™ for CA Datacom® outputs logically separated. An execution of batch CA Ideal™ for CA Datacom® has two or more outputs:
    • CA Ideal™ for CA Datacom® session output. This file shows a simulated session of CA Ideal™ for CA Datacom® commands and the resulting panels and messages.
    • CA Ideal™ for CA Datacom® error log
    • If a RUN command is issued in the batch run, then you must make additional * $$ LST entries for LIST statement output and for each application report.
    • DISP=D This parameter defines the disposition of the output in the POWER list queue. As in the DISP option for the JOB command, D releases the job stream immediately and does not retain it in the queue.
    • CLASS=L This parameter organizes the LIST queue. These statements are used with other * $$ LST statements to logically separate the various CA Ideal™ for CA Datacom® outputs.
    • LST=cuu... Indicates the logical printer defined for the various output files. See your systems programmer for the actual logical unit assignments for these files.

      ***************************

      *Assignments for sequential file dataviews and work areas

      *for sorted reports

      ***************************

    These comments show where sequential dataview files and sorted report work files go. Since they are not needed on every batch CA Ideal™ for CA Datacom® run, they are not included in the IDLPROC procedure.
  • // EXEC IDBATCH, SIZE=80K,PARM='NOPRINT'
    IDBATCH is the CA Ideal™ for CA Datacom® batch processing program. The size parameter sets the amount of storage allocated to the program for execution. The rest of the partition is used for processing other CA Ideal™ for CA Datacom® routines.
    The parameter PARM='NOPRINT' is optional. If you omit this parameter or specify it with a null value (''), a simulated CA Ideal™ for CA Datacom® session is printed. Specifying the parameter with the value NOPRINT suppresses all SYSPRINT output except the commands entered and the messages produced. The simulated CICS session is not printed.
    The statements that follow the EXECUTE command are CA Ideal™ for CA Datacom® commands.

    SIGNON PERSON username PSW password PRODUCT IDEAL

    COMPILE pgmname

    RUN pgmname

    OFF

The statements follow the same format as an online session.

  • /* This is a JOB step delimiter.
  • // EXEC LISTLOG LISTLOG is a VSE utility that adds all operator console messages associated with the job stream to the end of the output for the job stream.
  • /& VSE job delimiter.
  • $$ EOJ POWER job delimiter.

Batch Report JCL Considerations for VSE

The following only applies to batch jobs that route reports to the system printer.

The run of CA Ideal™ for CA Datacom® program can produce 15 reports and a LIST statement output. Actually, you can generate more than 15 reports if they are not sorted reports and one report is released before the next one starts (see RELEASE statement). There is a maximum of four concurrent reports and a total of four sorted reports.

Report output and LIST statement output are arbitrarily assigned to the logical units defined in the PSSPRT01 through PSSPRT15 file table entries. Check with the CA Ideal™ for CA Datacom® Administrator for the logical unit assignments defined for these entries in the file table.

If no special forms are required, there is no need to be concerned with which logical unit assignment is used. You can use POWER logical printers and $$ LST statements to keep the outputs logically separated. An example of this follows.

If a special form is required, then the programmer needs to know which logical unit assignment corresponds to the report. In this case, you can do the following:

  1. For each report in the run, assign the report to a specific logical unit using the ASSIGN command before the RUN command or the ASSIGN statement in the program before the first PRODUCE statement for that report.

    Note: Sorted reports that share the same forms and copies can share VSE logical assignments. Unsorted reports that share the same forms and copies can share VSE logical assignments only if the first report is released before the second is produced.
  2. Do the same with report RUNLIST, which is the name of the print output associated with LIST statement output.
  3. Add the POWER JCL records to control the logical output and its forms.

For example, in the following run REPORT1 is assigned to special form FRM1, REPORT2 to FRM2, and REPORT3 and LIST statement output to standard forms. The $$ LST statements are always required to keep the outputs logically separated even if special forms are not required.

* $$ JOB JNM=IDBATCH,PRI=n,USER='username',DISP=D

* $$ LST DISP=D,CLASS=L,LST=SYS102

* $$ LST DISP=D,CLASS=L,LST=SYS103,FNO=FRM1

* $$ LST DISP=D,CLASS=L,LST=SYS104,FNO=FRM2

* $$ LST DISP=D,CLASS=L,LST=SYS105

* $$ LST DISP=D,CLASS=L,LST=SYS106

* $$ LST DISP=D,CLASS=L

// JOB IDBATCH

// OPTION LOG,NODUMP

// EXEC PROC=IDLPROC

// EXEC IDBATCH,SIZE=15K

SIGNON PERSON userid PASSWORD password

ASSIGN REPORT RUNLIST TO SYS102

ASSIGN REPORT REPORT1 TO SYS103

ASSIGN REPORT REPORT2 TO SYS104

ASSIGN REPORT REPORT3 TO SYS105

ASSIGN REPORT REPORT4 TO SYS106

SET RUN URT DBURT010

RUN RPTPGM

OFF

/*

// EXEC LISTLOG

/*

/&

* $$ EOJ

Note: Session command output and the system error log go to SYSLST (by default). To separate them, add two $$ LST statements and modify the IDSYSFT entries for SYSPRINT and ADRL.

SYS102-SYS106 Logical units defined in the batch file table for PSS outputs. These units are user-defined.

Sorted reports have special JCL requirements. You must provide SORT work files. The report writer needs one internal work file for each sorted report. The report work files are defined in the file table. The JCL for the work file for each sorted report looks like this:

// ASSGN SYSnnn,DISK,VOL=volser,SHR

// DLBL IDRWK01,'IDEAL.report.work01',0,SD

// EXTENT SYSnnn,volser,,,trks,numtrks

You must specify JCL for each sorted report work file. The requirements for each are the same except for the DLBL names of IDRWK01 through IDRWK04, respectively.

The size of the report work file depends on the size of the report. One logical record is written every time a PRODUCE statement is executed. The size of the record depends on the number and sizes of the data fields defined in the detail and heading sections of the report. A block size of approximately 3KB is used.

The following example shows the JCL needed to run a CA Ideal™ for CA Datacom® program that has two sorted reports. No special forms are used. The same SORT work files are shared for each report. An adequate number of SORT work files with sufficient space are needed to sort the data in one report work file for the largest report in a RUN.

* $$ JOB JNM=IDBATCH,PRI=n,USER='username',DISP=D

* $$ LST DISP=D,CLASS=L,LST=SYS100

* $$ LST DISP=D,CLASS=L,LST=SYS101

* $$ LST DISP=D,CLASS=L,LST=SYS102

* $$ LST DISP=D,CLASS=L,LST=SYS103

* $$ LST DISP=D,CLASS=L,LST=SYS104

* $$ LST DISP=D,CLASS=L

// JOB IDBATCH

// OPTION LOG,NODUMP

// EXEC PROC=IDLPROC

*

* Assign for report and SORT work files

*

// ASSGN SYS050,DISK,VOL=SYSWK1,SHR

*

* Report work files

// DLBL IDRWK01,'IDEAL.REPORT.WORK01',0,SD

// EXTENT SYS050,volser,,,9000,50

// DLBL IDRWK02,'IDEAL.REPORT.WORK02',0,SD

// EXTENT SYS050,volser,,,9050,50

// DLBL IDRWK03,'IDEAL.REPORT.WORK03',0,SD

// EXTENT SYS050,volser,,,9100,50

// DLBL IDRWK04,'IDEAL.REPORT.WORK04',0,SD

// EXTENT SYS050,volser,,,9150,50

*

* SORT work files

*

// DLBL SORTWK1,'DOS.WORKFILE.SORT01',0,SD

// EXTENT SYS050,volser,,,9100,50

// DLBL SORTWK2,'DOS.WORKFILE.SORT02',0,SD

// EXTENT SYS050,volser,,,9150,50

// DLBL SORTWK3,'DOS.WORKFILE.SORT03',0,SD

// EXTENT SYS050,volser,,,9200,50

*

// EXEC IDBATCH,SIZE=nnK

PERSON username PSW psword PRODUCT IDEAL

RUN SORTRPT2

OFF

/*

// EXEC LISTLOG

/*

/&

* $$ EOJ

The size parameter on the // EXEC IDBATCH statement must be 15K for CA Ideal™ for CA Datacom®, plus the amount of partition storage (not GETVIS storage) required by the SORT (80K should be sufficient for a sorted report or cross reference on a compilation). For more information, see the IBM DOS SORT Manual.

Sequential File Considerations for VSE

Five types of sequential file dataviews are supported under VSE-disk, standard label tape, non-labeled tape, printer, and punch. Each type has its own set of one or more entries in the CA Ideal™ for CA Datacom® File Table. For more information, see Creating Dataviews for Sequential Files.

Before a program using a sequential dataview can be successfully compiled, you must enter the definition for the dataview, either in Datadictionary (a modeled dataview) or in CA Ideal™ for CA Datacom® (an unmodeled dataview) and then cataloged in CA Ideal™ for CA Datacom®. The catalog step puts the device type, record size, block size, file name and whether the file is labeled into the dataview object code used at compile time.

The display of the cataloged dataview shows the information needed to code the batch JCL. You can override some of this information with the ALTER PROGRAM and ASSIGN DATAVIEW commands. With the file table entry, this provides the information needed to access the file.

  • Device type
    Information as to whether a sequential dataview is disk, standard label tape, non-labeled tape, printer, or punch. You can override this option with an ALTER PROGRAM or ASSIGN DATAVIEW command before the run. At run time, the device type specifies to CA Ideal™ for CA Datacom® what type of file table entry to use-DISK, SLTAPE, NLTAPE, PRT, or PUNCH.
  • Filename
    The DLBL for disk files and TLBL for standard labeled tape files.
  • Logical Unit Assignment
    For standard label tape, non-labeled tape, printer, and punch files, the default assignment comes from the file table entry. You can override it with an ASSIGN DATAVIEW command before the RUN command or an ASSIGN statement executed before the first FOR construct referencing the dataview. The logical assignments for disk files are made completely through the JCL.
    Under VSE, two additional dataview status codes are used for error conditions. I7 is used if the block size specified for the file is larger than the maximum defined in the VPE File Table entry. I8 is used if multiple sequential files of the same type are referenced in the same run and there are not enough file table entries defined for that type.

If multiple tape, print, or punch files are referenced from the same run, there can be some ambiguity as to the logical unit assignment that is used. This is because multiple file table entries of the same type are allocated on a first come, first serve basis. That is, the first dataview of a type is allocated the first file table entry for that type; the second file of the same type gets the second, and so on. You can override the logical unit assignment defined in the file table with an ASSIGN COMMAND or ASSIGN statement.

Consequently, for runs that access multiple dataviews of the same type, assign the logical unit of each dataview with either an ASSIGN command before the run or an ASSIGN statement as the first thing done in the program. This prevents any JCL mix-ups.

This is not required for dataviews where there is only one of its type in the run; the logical unit used is the one for the first file table entry of that type. This is not required for disk dataviews since logical unit assignments are completely handled in the JCL.

You must add the following to batch run JCL to reference a sequential file dataview.

For DISK

// ASSGN SYSnnn,DISK,VOL=volser,SHR

// DLBL dlblnam,'IDEAL.report.work01',0,SD

// EXTENT SYSnnn,volser,,,trks,numtrks

  • dlblnam
    Displays the filename on the dataview Parameter Definition panel. The assign is completely defined in the JCL.

For Standard Labeled Tape

// PAUSE PLEASE MOUNT TAPE volser ON 180

// TLBL file-id,'IDEAL.XPRT.TAPE',,volser

// ASSGN SYSnnn,180

  • file-id
    Displays the filename on the dataview Parameter Definition panel.
  • SYSnnn
    Defines the logical unit in the CA Ideal™ for CA Datacom® batch file table or the override value specified in an ASSIGN command or ASSIGN statement.

For Nonlabeled Tape

// ASSGN SYSnnn,180

  • SYSnnn
    Defines the logical unit in the VPE Batch File Table or the override value specified in an ASSIGN command or ASSIGN statement.

For Print Files

// ASSGN SYSnnn,printer

  • SYSnnn
    Defines the logical unit in the VPE Batch File Table, or the override value specified in an ASSIGN command or ASSIGN statement.
  • printer
    Identifies a logical unit defined to POWER as a printer.

For punch files

// ASSGN SYSPCH,punch

  • punch
    Identifies a logical unit defined to POWER as a punch.

By default, when a tape DTF is generated, it has the parameter REWIND=UNLOAD specified. This causes a rewind when the file is opened and a rewind and unload when the file is closed. You can alter this in the CA Ideal™ for CA Datacom® batch file table definition.

Terminating a RUN

The RUN command, issued online or in batch, terminates upon successful completion of the executed program, upon encountering abnormal conditions, or by encountering online interruptions.

Successful Completion of a Run

A run terminates when program execution is successfully completed (when a QUIT RUN statement in any program or subprogram or a QUIT PROGRAM statement in the main program is encountered, or when the main program falls through to the end without an explicit QUIT RUN).

Abnormal Termination of a Run

A run terminates when CA Ideal™ for CA Datacom® does not give control to the ERROR PROCEDURE, such as when an environmental or system error occurs (for example, MAXLINES are exceeded). An error message is issued.

A run terminates when an execution error occurs and there is no ERROR PROCEDURE in the program. A default ERROR PROCEDURE is used that lists the error, performs a BACKOUT, issues a message, and quits the program. See Error Procedure for more information.

Online Interruption of a Run

A run terminates when a panel is on the panel and a command or function key initiates a new activity, such as CLEAR, RETURN, EDIT, DISPLAY, or DELETE.

At the end of a run, the message RUN completed, RC=nn appears. The RC=nn is the value of the return code at the end of the run. Each system message has a message level with an associated return code. The program can also explicitly set the return code to any value.

When an internal system error is detected in the run, $RC is set to 12. See also $RETURN-CODE Function.

Submitting a Batch Job Stream

Use the SUBMIT command to submit a CA Ideal™ for CA Datacom® data member containing a batch job stream or a series of data members that contain portions of a job stream. Access the SUBMIT prompter by selecting option 4 on the Process Program Menu or issuing the SUBMIT command.

Note: Some external security systems can assign a user's security ID to jobs that user submitted. If your site uses one of these security systems to control access to CA Ideal™ for CA Datacom® and you omit the JOB statement, your security ID is assigned to the submitted job.

For more information, see SUBMIT Command.

Using CA Ideal™ for CA Datacom® Commands in Batch

The first CA Ideal™ for CA Datacom® command required in any job stream is the SIGNON command. If your site uses an external security system to control access to CA Ideal™ for CA Datacom®, do not include this command.

This command is followed by any sequence of CA Ideal™ for CA Datacom® commands. If an error is encountered while executing one of the commands, the transaction containing the error is ended and the next command is executed.

Note: If the SET OUTPUT DESTINATION statement is included in either the signon member or the batch input statements, the destination specified in the SET OUTPUT command overrides the usual batch output destination of AUXPRINT.

The command OFF must be the last command entered. You can use the following set of IF, ELSE, ENDIF commands in the job stream to execute subsets of commands in the job stream based on the value of the return code.

The commands appear in the following syntax:

                  {GE}

                  {GT}

                  {LE}

IF [$RETURN-CODE] {LT}   nnn

   [$RC         ] {EQ}

                  {NE}

    <i_dcm> commands

ELSE

    [<i_dcm> commands  ]

ENDIF

The value nnn is tested against the current return code using the specified relational operator. The relational operator must be in the form shown above and is required.

The ELSE clause is optional. If the condition evaluates True, all commands are executed until the ELSE or ENDIF command is encountered, and all commands after ELSE are bypassed. If the condition is False, no commands are executed until either an ELSE or an ENDIF is encountered.

You cannot nest the IF-ELSE-ENDIF command series in other sets of IF-ELSE-ENDIF commands.

You can use the SET $RETURN-CODE command in the job stream to override the condition codes set by previous commands in the session.

For commands other than RUN (which can set any value for $RC), the following table shows how $RC values are associated with warning or error messages.

Message Level Return Code
I - Information 0
A - Advisory 4
W - Warning 4
E - Error 8
F - Fatal Error 12 or greater
C - Conditional 16
D - Disaster 16
T - Terminal 16

Batch Job Stream in an z/OS Environment

The following is a sample CA Ideal™ for CA Datacom® batch job stream in the z/OS environment:

//DEMO1 JOB . . .

//BATCH EXEC IDLBATCH

//IDEAL.EMPRPT DD SYSOUT=A

//IDEAL.SYSIN DD *

SIGNON PERSON userid PASSWORD password

.

.

.

SELECT SYSTEM CTL

EXEC USRPROF

SET OUTPUT COPIES 2

.

.

.

COMPILE PROGRAM DEMO1 VERSION 2

CATALOG DATAVIEW EMPY VERSION 1

RUN DEMO1 VERSION 2

.

.

.

OFF

/*

In this example:

  • A user's profile (a series of SET commands) is stored in a member named USRPROF. This member is executed using the EXEC USRPROF command.
  • A program runs that generates a report (the report name is EMPRPT) and, therefore, requires the EMPRPT DD record.
  • The value of $RETURN-CODE is passed back to the operating system when OFF is executed.

The following job stream uses the IF, ELSE, ENDIF, and SET commands.

//DEMO2 JOB ...

...

SIGNON PERSON xxx PASSWORD

SET RUN $RC KEEP

RUN PGM1 PROD

IF $RETURN-CODE EQ 0

   RUN PGM2 PROD

ELSE

   RUN ERRPGM PROD

   SET $RETURN-CODE EQ 8

ENDIF

SEL SYS ABC

IF $RETURN-CODE EQ 0

   RUN MAINTABC PROD

ELSE

   SET $RETURN-CODE EQ 0

   SEL SYS XYZ

   RUN MAINTXYZ PROD

ENDIF

SET RUN $RC ZERO

RUN RPT1 PROD

RUN RPT2 PROD

OFF

...

In the above example, the SET RUN $RC KEEP is entered in the job stream before the first batch run. All subsequent programs that are run receive the return code value that was previously set. The value of the return code that was in effect before the RUN is therefore available for testing or changing in the RUN. Whenever you enter SET $RETURN-CODE EQ 0, the return code is set back to zero. The SET RUN $RC ZERO option sets the return code back to zero at the start of each following RUN, which ensures that the RPT2 program executes regardless of the success or failure of any of the previous RUN commands.

Note: $RC is an abbreviation for $RETURN-CODE. You can use either name .
Was this helpful?

Please log in to post comments.