Previous Topic: z/OS Mainframe Server Component Startup JCLNext Topic: Input Parameters


z/OS Startup JCL Control Statements

Startup JCL job control statements required for the Mainframe Server component are as follows:

EXEC

Provides the name of the program (SVDBSPR) to execute.

JOB

Specifies a valid job statement for the site and must be site-specific.

SNAPER

Specifies the output file to which CA Datacom/DB will write SNAP dumps.

STEPLIB

Specifies the DSN statements used by CA Datacom Server, CA Datacom/DB and the CA Common Services for z/OS if CAICCI is to be used as a communication protocol. The CA Datacom/DB load library includes the specification for the Multi-User Facility to which the server is to connect. If an operating group of servers is running at the same time, each can only connect with one Multi-User Facility, but each Multi-User Facility can be accessed by more than one server.

The library containing the User Requirements Tables (URT) to be loaded must be concatenated into the server STEPLIB. The server startup parameter LOADURT attempts to locate the URT from this DD statement.

SYSPRINT

Specifies when messages are written to SYSPRINT. Additionally contains trace information from the main task if TRACEON=YES is specified.

SYSTCPD

Specifies the output file to which general informational and error messages are written. Startup parameters are echoed to this file along with any informational messages written during Mainframe Component processing..

SYSUDUMP

Specifies a SYSUDUMP will be written when a dump is needed. The output from the SYSDUMP will be directed to this file.

CAOESTOP

Specifies that abend processing may be interfered with and that a valid abend may be masked. This statement only needs to be added if your site is running CA SymDump Batch and CA Optimizer/II.

Trace Output Files

TCPTRACE

This file is dynamically allocated unles a DD statement is found in the inline JCL. This file show all TCP/IP activity for CA Datacom Server if tracing is enabled (TRACEON=YES).

T4Annnnn

This file is dynamically allocated for EACH type 4 driver connection that is opened with "traceNative" specified in the client side connection, where nnnnn is a consecutively increasing number for each such connection.