This file contains variables definition.

These variables must be set before using the RunTime Batch.

This file contains messages used by RTBatch.

The messages may be translated in a local language.

This file contains internal codes associated with a message.

This file contains return codes associated with a message and returned to the KSH script.

This file contains usage and samples of writer.

Users can add their writers into this file.

The following table lists the environment variables that are used in the KSH scripts and must be defined before using the software.

• JESDIR
• MT_KSH
• MT_LOG
• MT_REFINEDIR
• MT_SYSOUT
• MT_TMP

The following table lists optional environment variables used by Batch Runtime:

The following lists the environment variables that are used by Native JCL Batch Runtime and must be defined before using the software:

The following table lists optional environment variables used by Native JCL Batch Runtime.

Oracle Tuxedo Application Runtime for Batch normalizes Korn shell script formats by proposing a script model where the different execution phases of a job are clearly identified.

Oracle Tuxedo Application Runtime for Batch scripts respect a specific format that allows the definition and the chaining of the different phases of the KSH (JOB).

Within Batch Runtime, a phase corresponds to an activity or a step on the source system.

A phase is identified by a label and delimited by the next phase.

At the end of each phase, the JUMP_LABEL variable is updated to give the label of the next phase to be executed.

In the following example, the last functional phase sets JUMP_LABEL to JOBEND: this label allows a normal termination of the job (exits from the phase loop).

The mandatory parts of the script (the beginning and end parts) are shown in bold and the functional part of the script (the middle part) in normal style as shown in the table below. The optional part of the script must contain the labels, branching and end of steps as described below. The items of the script to be modified are shown in italics.

Listing 2‑1 Korn shell Script Example

#!/bin/ksh
#@(#)--------------------------------------------------------------
#@(#)-
m_JobBegin -j METAW01D -s START -v 2.00 -c A
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
# -----------------------------------------------------------------
# 1) 1st Step: DELVCUST
# Delete the existing file.
# 2) 2nd Step: DEFVCUST
# Allocates the Simple Sample Application VSAM customers file
# -----------------------------------------------------------------
#
# -Step 1: Delete...
JUMP_LABEL=DELVCUST
;;
(DELVCUST)
m_FileAssign -d OLD FDEL ${DATA}/METAW00.VSAM.CUSTOMER
m_FileDelete ${DD_FDEL}
m_RcSet 0
#
# -Step 2: Define...
JUMP_LABEL=DEFVCUST
;;
(DEFVCUST)
# IDCAMS DEFINE CLUSTER IDX
m_FileBuild -t IDX -r 266 -k 1+6 ${DATA}/METAW00.VSAM.CUSTOMER
JUMP_LABEL=END_JOB
;;
(ABORT)
break
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT} "Unknown label : ${JUMP_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
#@(#)--------------------------------------------------------------

A step (also called a phase) is generally a coherent set of calls to Batch Runtime functions that enables the execution of a functional (or technical) activity.

The most frequent steps are those that execute an application or utility program. These kind of steps are generally composed of one or several file assignment operations followed by the execution of the desired program. All the file assignments operations must precede the program execution operation shown in Listing below.

Listing 2‑3 Application Program Execution Step Example

(STEPPR15)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRO099
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRO001
m_OutputAssign -c “*” SYSOUT
m_FileAssign -i LOGIN
IN-STREAM DATA
_end
m_FileAssign -d MOD LOGOUT ${DATA}/PJ01DDD.BT.QSAM.KBPRO091
m_ProgramExec BPRAB001 "20071120"
JUMP_LABEL=END_JOB
;;

ABEND routines, ILBOABN0, CEE3ABD and ART3ABD can be called from a running program to force it to abort and return the abend code to KSH script. For example, ILBOABN0 is supplied as both source and binary gnt file. It can be directly called by any user-defined COBOL program.

(STEPPR15)
m_ProgramExec USER
JUMP_LABEL=END_JOB
;;

Listing 2‑5 USER.cbl Example

PROCEDURE DIVISION.
PROGRAM-BEGIN.
DISPLAY "USER: HELLO USER".
MOVE 2 TO RT-PARAM.
CALL "ILBOABN0" USING RT-PARAM.
DISPLAY "USER: CAN'T REACH HERE WHEN ILBOABN0 IS CALLED".
PROGRAM-DONE.
...

Oracle Tuxedo Application Runtime for Batch offers a set of functions to define and use "procedures". These procedures follow generally the same principles as z/OS JCL procedures.

The advantages of procedures are:

• Write a set of tasks once and use it several times.
• Make this set of tasks dynamically modifiable.

Procedures can be of two types:

• In-stream Procedures: Included in the calling script, this kind of procedure can be used only in the current script.
• External Procedures: Coded in a separate source file, this kind of procedure can be used in multiple scripts.

The following topics describe how to create the above procedures:

• Creating an In-Stream Procedure
  
• Creating an External Procedure
  

The use of a procedure inside a Korn shell script is made through a call to the m_ProcInclude function.

As described in Script Execution Phases, during the Conversion Phase, a Korn shell script is expanded by including the procedure's code each time a call to the m_ProcInclude function is encountered. It is necessary that after this operation, the resulting expanded Korn shell script still respects the rules of the general structure of a script as defined in the General Structure of a Script.

A procedure, either in-stream or external, can be used in any place inside a calling job provided that the above principals are respected shown in Listing below.

…
(STEPPR14)
m_ProcInclude BPRAP009
JUMP_LABEL=STEPPR15
…

The execution of the tasks defined in a procedure can be modified in two different ways:

• Modifying symbols and/or parameters
• Symbols can be used inside a procedure and the values of these symbols can be specified when calling the procedure.

Listing 2‑9 Defining Procedure Example

m_ProcBegin PROCE
JUMP_LABEL=STEPE
;;
(STEPE)
m_FileAssign -d SHR SYSUT1 ${DATA}/DATA.IN.PDS/DTS$[SEQ]
m_FileAssign -d MOD SYSUT2 ${DATA}/DATA.OUT.PDS/DTS$[SEQ]
m_FileLoad ${DD_SYSUT1} ${DD_SYSUT2}
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
m_ProcEnd

Listing 2‑10 Calling Procedure Example

(COPIERE)
m_ProcInclude PROCE SEQ="1"
JUMP_LABEL=COPIERF
;;

• Using Overrides for File Assignments
  

This section contains the following topics:

• Using m_CondIf, m_CondElse, and m_CondEndif
  
• Using m_CondExec
  

The script's execution flow is determined, and can be controlled, in the following ways:

• The start label specified by the m_JobBegin function: this label is usually the first label in the script, but can be changed to any label present in the script if the user wants to start the script execution from a specific step.
• The value assigned to the JUMP_LABEL variable in each step: this assignment is mandatory in each step, but its value is not necessarily the label of the following step.
• The usage of the m_CondExec, m_CondIf, m_CondElse and m_CondEndif functions: see Conditioning the Execution of a Step
• The return codes and abnormal ends of steps.

If Batch Runtime administrator wishes to change the default messages (to change the language for example), this can be done through a configuration file whose path is specified by the environment variable: MT_DISPLAY_MESSAGE_FILE.

This file is a CSV (comma separated values) file with a semicolon as a separator. Each record in this file describes a certain message and is composed of six fields:

1. Message identifier.
2. Functions that can display the message (can be a generic name using '*').
3. Level of display.
4. Destination of display.
5. Reserved for future use.
6. Message to be displayed.

Files are created using the m_FileBuild or the m_FileAssign function.

Four file organizations are supported:

• Sequential file
• Line sequential file
• Relative file
• Indexed file

You must specify the file organization for the file being created. For indexed files, the length and the primary key specifications must also be mentioned.

• m_FileBuild Examples
  
• m_FileAssign Examples
  

When using Batch Runtime, a file can be used either by a Batch Runtime function (for example: m_FileSort, m_FileRename etc.) or by a program, such as a COBOL program.

In both cases, before being used, a file must first be assigned. Files are assigned using the m_FileAssign function that:

• Specifies the DISP mode (Read or Write)
• Specifies if the file is a generation file
• Defines an environment variable linking the logical name of the file (IFN) with the real path to the file (EFN).

The environment variable defined via the m_FileAssign function is named: DD_IFN. This naming convention is due to the fact that it is the one used by Micro Focus COBOL to map internal file names to external file names.

Once a file is assigned, it can be passed as an argument to any of Batch Runtime functions handling files by using the ${DD_IFN} variable.

For COBOL programs, the link is made implicitly by Micro Focus COBOL. COBOL-IT is compatible with Micro Focus COBOL regarding DD assignment.

Listing 2‑15 Example of File Assignment

(STEPCP01)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIDI001
m_FileAssign -d SHR OUTFIL ${DATA}/PJ01DDD.BT.VSAM.KBIDU001
m_FileLoad ${DD_INFIL} ${DD_OUTFIL}
…

Listing 2‑16 Example of Using a File by a COBOL Program

(STEPCBL1)
m_FileAssign -d OLD INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFI091
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFO091
m_ProgramExec BIFAB090
…

• About DD DISP=MOD
  

Batch Runtime provides a lock mechanism to prevent one file from being written simultaneously in two jobs.

To enable the concurrent file access control, do the following:

1. Use environment variable MT_ACC_FILEPATH to specify a directory for the lock files required by concurrent access control mechanism.
2. Create two empty files, AccLock and AccWait, under the directory specified in step 1.

   Make sure the effective user executing jobs has read/write permission to these two files.

   Note:

   • The file names of AccLock and AccWait are case sensitive.
   • When accessing generation files, a GDG rather than a generation file is locked. That is, a GDG is locked as a whole.
   • Following two lines in ejr/CONF/BatchRT.conf should be commented out:

     ${MT_ACC_FILEPATH}/AccLock

     ${MT_ACC_FILEPATH}/AccWait

Oracle Tuxedo Application Runtime for Batch allows you to manage Generation Data Group (GDG)files either based on file or based on database (DB). In file-based management way, Batch Runtime manages GDG files in separate "*.gens" files, and one "*.gens" corresponds to one GDG file. In DB-based management way, ART for Batch allows users to manage GDG information in Oracle database or DB2 database.

• GDG Management Functionalities
  
• File-Based Management
  
• DB-Based Management
  
• Support for Data Control Block (DCB)
  

To define and use a file whose data is written directly inside the Korn shell script, use the m_FileAssign function with the -i parameter. By default the string _end is the “end” delimiter of the in-stream flow as shown in Listing below:

Listing 2‑28 In-stream Data Example

(STEP1)
m_FileAssign -i INFIL
data record 1
data record 2
…
_end

To use a set of files as a concatenated input (which in z/Os JCL was coded as a DD card, where only the first one contains a label), use the m_FileAssign function with the -C parameter as shown in the Listing 2-29 below:

Listing 2‑29 Using a Concatenated Set of Files Example

(STEPDD02)
m_FileAssign -d SHR INF ${DATA}/PJ01DDD.BT.QSAM.KBDDI002
m_FileAssign -d SHR -C ${DATA}/PJ01DDD.BT.QSAM.KBDDI001
m_ProgramExec BDDAB001

Files (including generation files) can be deleted using the m_FileDelete function:

m_FileDelete ${DATA}/PJ01DDD.BT.QSAM.KBSTO045

In a migration project from z/Os to UNIX/Linux, some permanent data files may be converted to relational tables. See the File-to-Oracle chapter of the Oracle Tuxedo Application Runtime Workbench.

When a file is converted to a relational table, this change has an impact on the components that use it. Specifically, when such a file is used in a z/Os JCL, the converted Korn shell script corresponding to that JCL should be able to handle operations that involve this file.

In order to keep the translated Korn shell script as standard as possible, this change is not handled in the translation process. Instead, all the management of this type of file is performed at execution time within Batch Runtime.

In other words, if in the z/OS JCL there was a file copy operation involving the converted file, this is translated to a standard copy operation for files in Batch Runtime, in other words an m_FileLoad operation).

The management of a file converted to a table is made possible through an RDB file. An RDB file is a file that has the same name as the file that is converted to a table but with an additional suffix:.rdb.

Each time a file-related function is executed by Batch Runtime, it checks whether the files were converted to table (through testing the presence of a corresponding .rdb file). If one of the files concerned have been converted to a table, then the function operates the required intermediate operations (such as: unloading and reloading the table to a file) before performing the final action.

All of this management is transparent to the end-user.

When executing an application program that needs to connect to the RDBMS, the -b option must be used when calling the m_ProgramExec function.

Connection and disconnection (as well as the commit and rollback operations) are handled implicitly by Batch Runtime and can be defined using the following two methods:

• Set the environment variable MT_DB_LOGIN before booting the TuxJES system.

  Note:

  In this case, all executing jobs use this variable.
• Set its value in the TuxJES Security Configuration file for different users.

(STEPDD02)
m_FileAssign -d MOD OUTF ${DATA}/PJ01DDD.BT.QSAM.REPO001
m_ProgramExec -b DBREP001

The m_ProgramExec function may submit three types of files.

• Generated code files (.gnt file extension) compiled from COBOL source code file.

  Make sure that the .gnt files can be found in $COBPATH (for Micro Focus COBOL) or $COB_LIBRARY_PATH (for COBOL-IT).

• Callable shared library (.so file extension) compiled from C source code file.

  Make sure the callable shared library file can be found at $COBPATH (for Micro Focus COBOL) or $COB_LIBRARY_PATH (for COBOL-IT), or at system library file search path like LIBPATH, LD_LIBRARY_PATH, and so on.

  This type of file must have an entry function whose name is equal to the file name.

  For example, callable shared library file ProgA.so must contain a function declared by one of the following:

  • ProgA(short* arglen, char* argstr): if you need parameters
  • ProgA(): if you do not need parameters
• Any other types of executable program (such as system utilities, shell scripts, and third party utilities)

  m_ProgramExec will determine the deliverable type of the program in the following sequence: COBOL program (.gnt), C program in callable shared library (.so), and other executable programs. Once a COBOL program is executed, m_ProgramExec will not execute other programs with the same name. For example, once ProgA.gnt is executed, ProgA.so or other programs named ProgA will not be executed.

For .gnt file and .so files, m_ProgramExec launches the runb program to run it. ART provides runb for the following:

• $JESDIR/ejr_mf_ora for combination of Micro Focus COBOL and Oracle database
• $JESDIR/ejr_mf_db2 for combination of Micro Focus COBOL and DB2 database
• $JESDIR/ejr_cit_ora for combination of COBOL-IT and Oracle database
• $JESDIR/ejr_cit_db2 for combination of COBOL-IT and DB2 database

If you do not use the above four types of combination, go to $JESDIR/ejr and run make.sh to generate your personalized runb.

The runb program, runtime compiled with database libraries, runs the runbatch program.

The runbatch program, is in charge to:

- do the connection to the database (if necessary)

- run the user program

- do the commit or rollback (if necessary)

- do the disconnection from the database (if necessary)

You should include only one function in a single file with the same name as the function. For example, m_*_Begin or m_*_End. Further, you should put all such files under ejr/USER_EXIT.

You are not allowed to provide custom entry/exit functions for any mi_ prefix function provided by Batch Runtime.

This section contains the following topics:

• Log Message Format
  
• Log Message Level
  
• Log Level Control
  
• Log File Structure
  

Batch Runtime logging functionality provides an informative log header in front of each log line, in the following format:

YYYYmmdd:HH:MM:SS:TuxSiteID:JobID:JobName:JobStepName

You can configure the format of log header, but should not impact any configuration and behavior of existing specific message header: type 0, 1 and b.

The following table shows the variables you can use for specifying the general log header:

• Configuration
  

Logging system can logs the detailed file information in job log, as well as the information when a file is assigned to a DD and when it is released.

File assignment information is logged in the following functions:

m_FileAssign

File release information is logged in the following functions:

m_PhaseEnd

File information is logged in the following functions:

• m_FileBuild
• m_FileClrData
• m_FileConcatenate
• m_FileCopy
• m_FileDelete
• m_FileEmpty
• m_FileExist
• m_FileLoad
• m_FileRename
• m_FilePrint
• m_FileRepro

The following topic describes the configurations required to log detailed file information:

• Configuration
  

Oracle Tuxedo ART Batch Runtime supports users to manage native JCL jobs without pre-conversion by ART Workbench.

It is required to set TuxJES using database to manage job. See Setting up TuxJES as an Oracle Tuxedo Application (Using Database) for more information.

It is required to add following setting item to jesconfig file: JOBLANG=JCL.

All the environment variables described in Setting Environment Variables is also available for native JCL execution.

The usage is the same as KSH jobs:

• Submitting a JCL Job
  
• Printing Jobs
  
• Holding/Releasing/Canceling/Purging a JCL Job
  
• JCL Engine's Debug Trace File
  

Table 2‑17 lists the supported JCL statement. Table 2‑18 lists the supported utilities.

Native JCL Test Mode is a running mode of native JCL. This mode helps you analyze defects in user jobs/procs, find gaps in the use of the Native JCL feature, and detect environment dependency issues that block jobs from running.

Configure as follows to use Native JCL Test Mode.

• Environment Variables Configurations (Mandatory)
  
• Native JCL Configuration File Configurations (Optional)
  

You can use artjclchk tool to launch test mode for a job or a group of jobs. The command line syntax for the artjclchk tool is as follows:

artjclchk -d <destdir> [-i <job_file|job_dir>] [-p <parallel number>] [-r]

-d <destdir>

Specifies the destination directory to save output report files. There are three types of output report file; all of them are generated here. See Test Mode Report Files for more information.

-i <job_file|job_dir>

Specifies jobs to be analyzed in test mode. You can specify an individual job or a directory; if you specify a directory, all jobs under this directory are analyzed.

-p <parallel number>

Specifies the number of jobs that can be processed concurrently.

-r

Specifies to generate category report and summary report.

• If you specify -r but do not specify -i, this command generates category report and summary report for every individual report under -d directory.
• If you specify -r and specify -i, this command generates individual reports for all jobs that -i specifies, and then generates category report and summary report only for these individual reports.
• If you do not specify -r, category report and summary report are not generated.

There are three types of report files that artjclchk generates.

• Individual Report File

  An individual report file is a job specific report file. artjclchk generates an individual report file for each job; anything found in the job is reported in this file.

• Category Report File

  A category report file is organized according to the type of information. artjclchk generates a summary report file for each type of information; any occurrence falling in the category together with job location and line number is reported in this file.

• Summary Report File

  A summary report file is a simplified version of category report. artjclchk generates it. Unlike category report file, summary report file only records the issues and issue occurrences. Summary report file has the same name with the corresponding category report file but without "Occurences".

  The following topics describe each of the reports in details:

• Individual Report File
  
• Category Report File
  
• Summary Report File
  

With NJE support, users can implement the following functionalities in Batch Runtime exactly as they do in JCL jobs.

• /* ROUTE XEQ
• /* XEQ
• /* XMIT

By m_SetJobExecLocation API of Batch Runtime, users can develop KSH jobs with NJE support. For example,

• Specify the server group, on which the job will be executed.
• In a job, transmit an in-stream job to another server group and make it run on that server group.

This section contains the following topics:

• Job Execution Server Group
  
• ON/OFF Setting of NJE Support
  
• Environment Variable MT_TMP in MP Mode
  
• Queue EXECGRP
  

Listing 2‑32 Sample of Specifying Job Execution Server Group (XEQ)

m_JobBegin -j SAMPLEJCL -s START -v 2.0 -c R
m_JobSetExecLocation "ATLANTA"
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
# XEQ ATLANTA
JUMP_LABEL=STEP01
;;
(STEP01)
m_OutputAssign -c "*" SYSPRINT
m_FileAssign -i SYSIN
m_FileDelete ${DATA}/GBOM.J.PRD.ABOMJAW1.ABEND02
m_RcSet 0
_end
m_UtilityExec
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : ${CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd

Listing 2‑33 Sample of Transmitting and Submitting a Job to Another Server Group (XMIT)

m_JobBegin -j JOBA -s START -v 2.0
while true;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
m_FileAssign -i -D \_DML_XMIT_TEST1 SYSIN
m_JobBegin -j TEST1 -s START -v 2.0 -c B
m_JobSetExecLocation "ATLANTA"
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
JUMP_LABEL=STEP01
;;
(STEP01)
m_OutputAssign -c "*" SYSPRINT
m_FileAssign -i SYSIN
m_FileDelete ${DATA}/GBOM.J.PRD.ABOMJAW1.ABEND02
m_RcSet 0
_end
 
m_UtilityExec
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : ${CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
_DML_XMIT_TEST1
m_ProgramExec artjesadmin -i ${DD_SYSIN}
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : {CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd

In the above sample, job TEST1 will be submitted by the current job and executed by the ARTJESINITIATOR which belongs to JES's Tuxedo server group ATLANTA.

With file catalog support in Batch Runtime, users can access dataset under volumes. A volume is a dataset carrier and exists as a folder; each dataset should belong to a volume.

File catalog contains the mapping from each dataset to each volume. When referencing an existing and cataloged file on Mainframe, file catalog will be requested to find out the volume in which the file is located, and then the file will be accessed.

If file catalog functionality is disabled, the behavior in Batch Runtime remains the same as it is without such functionality.

This table shows the general management for file catalog functionality by Batch Runtime. In this table, each row represents one file-to-volume mapping.

Four configuration variables are required to be added in BatchRT.conf or set as environment variables:

MT_USE_FILE_CATALOG

If it is set to yes (MT_USE_FILE_CATALOG=yes), the file catalog functionality is enabled; otherwise, the functionality is disabled.

MT_VOLUME_DEFAULT

If no volumes are specified when a new dataset is created, Batch Runtime uses the volume defined by MT_VOLUME_DEFAULT. MT_VOLUME_DEFAULT contains only one volume. For example, MT_VOLUME_DEFAULT=volume1.

MT_DB_LOGIN

This variable contains database access information. For Oracle, its value is "username/password@sid" (for example, "scott/password@gdg001").

For Db2, its value is "your-database USER your-username USING your-password" (for example, "db2linux USER db2svr USING db2svr").

MT_CATALOG_DB_LOGIN

This variable contains file catalog database access information. Its format is the same as MT_DB_LOGIN. Since the file catalog is stored in database, BatchRT must access it through MT_DB_LOGIN or MT_CATALOG_DB_LOGIN.

MT_CATALOG_DB_LOGIN precedes MT_DB_LOGIN in accessing file catalog. If file catalog DB is the same as data DB, configuring MT_DB_LOGIN only is required; otherwise, both must be configured.

You can use CreateTableCatalog[Oracle|Db2].sh or DropTableCatalog[Oracle|Db2].sh to create or drop the new database table.

• Description
  
• Usage
  
• Sample
  
• DropTableCatalog[Oracle|Db2].sh
  

To use file catalog functionality in Batch Runtime, File Converter and JCL Converter in ART Workbench should enable catalog functionality. For more information, please refer to Oracle Tuxedo Application Rehosting Workbench User Guide.

MT_REXX_PATH has no default value. It should be set with the main path where all REXX execs located in. Place REXX programs in proper subdirectories under ${MT_REXX_PATH}. These subdirectories correspond to PDS on mainframe where REXX programs live.

If SYSEXEC is defined, BatchRT accepts programs run by m_ProgramExec as REXX EXEC.

DD SYSEXEC specifies where to find object REXX programs.

All relevant REXX files (REXX APIs and TSO commands) are located in the Batch_RT/tools/rexx directory. The directory structure is as follows:

-- lib

/-- outtrap.rex

/ -- regis_tso_cmd

-- tso

/-- DELETE

/-- LISTDS

/- RENAME

/-- libTSO.so

Batch_RT/tools/rexx/tso is where TSO commands are located. REXX APIs should be put in theBatch_RT/tools/rexx/lib directory.

To enable this feature, you need to set the following environment variables:

Also, you need to set the following environment variables.

• LD_LIBRARY_PATH should include TimesTen library and the bundled instant client library.
• TNS_ADMIN should be set to the directory containing file tnsnames.ora, in which both TimesTen and Oracle TNS information should be included. For more information, see Oracle TimesTen In-Memory Database documentation.

All EXEC SQL statements to Oracle database does not need to specify connection name; however, all operations to TimesTen should specify the TimesTen connection name as it is set in MT_TT_CONN .

In this feature, all COBOL programs accessing Oracle database or TimesTen database should be processed by TimesTen Pro*COBOL.

The following are the list of examples:

• Example for Setting Environment Variables
  
• Example for COBOL Programs Accessing to Oracle Database
  
• Example for COBOL Programs Accessing to TimesTen Database
  
• Example for Preprocessing COBOL Programs
  
• Example for Compiling COBOL Programs (CIT)