Transaction Scheduler Section

The transaction scheduler section contains information about how the program will be scheduled by the APPC/MVS transaction scheduler. Programs not scheduled by the APPC/MVS transaction scheduler must provide an exit to syntax check the format expected by that scheduler.

Figure 1. APPC/MVS Transaction Scheduler Section

Utility command and exit ───────→ Command_name TPSCHED_EXIT(exit name)
  ... TP profile key ...
  ... Attributes section ...
  Security SYSOUT Update ─────────→TAILOR_SYSOUT(NO|YES)
  Security Account Update ────────→TAILOR_ACCOUNT(NO|YES)
  Scheduler Class Name ───────────→CLASS(class name)
  TP Scheduler Type ──────────────→TPSCHED_TYPE(STANDARD|MULTI_TRANS)
  ID for Multi_Trans TPs ─────────→GENERIC_ID(generic userid)
  Beginning of TP JCL ────────────→JCL_DELIMITER(delimiter2)
                                   //jobname  JOB  ...
                                   //stepname EXEC ...
  End of TP JCL ──────────────────→delimiter2
  Message Log Option ─────────────→KEEP_MESSAGE_LOG(ERROR|ALWAYS|NEVER)
  Name of Message Data Set ───────→ MESSAGE_DATA_SET(data set name)
  Status of Message Data Set ─────→ DATASET_STATUS(NEW|OLD|MOD)
  SMS Storage Class ──────────────→ STORAGE_CLASS(class name)
  SMS Management Class ───────────→ MANAGEMENT_CLASS(class name)
  SMS Data Class ─────────────────→ DATA_CLASS(class name)

TPSCHED_EXIT(ASCH|exit name)

Names the exit that syntax checks the scheduler section. This keyword must appear on the same line as the utility command, after the command name when adding or modifying TP profiles. For example, when adding a TP profile that will use the ASCH scheduler exit, you can specify:

  TPADD TPSCHED_EXIT(ASCH)

The default is ASCH, so this keyword can be omitted for TPs scheduled by the APPC/MVS transaction scheduler.

For information about writing an exit to check syntax, see z/OS MVS System Messages, Vol 3 (ASB-BPX).

TAILOR_SYSOUT(NO|YES)

Indicates whether a program tailors each transaction's SYSOUT with additional SYSOUT information from the requestor's security profile. When the requestor uses a security specification of security_none on the Allocate call, no SYSOUT tailoring can occur. The default is NO.

The SYSOUT specification in the TP profile JCL applies to all transaction instances of the program whether or not tailoring is requested. To guarantee that output is processed before a TP ends, include the FREE=CLOSE parameter with the SYSOUT specification. For SYSOUT recommendations, see Specific Scheduler JCL Information for TP Profiles.

When the RACF® security product is used, the SYSOUT information is stored in the WORKATTR segment of the RACF user profile. For information about the RACF user profile, see Setting up Network Security.

Note: When SYSOUT tailoring is requested, OUTPUT statement keywords have varying default and override values. See individual OUTPUT keyword descriptions in z/OS MVS JCL Reference for specific defaults and overrides.

TAILOR_ACCOUNT(NO|YES)

Indicates whether a program tailors each transaction's account with the account information from the requestor's security profile. If there is no account number in the requestor's security profile and account tailoring was requested, the account number passed is 00000000. When the requestor uses a security specification of security_none on the Allocate call, no account tailoring can occur. The default is NO.

When no account tailoring is requested, the initial account specification in the TP profile JCL records applies to all transaction instances of the program.

When the RACF security product is used, the account information is stored in the WORKATTR segment of the RACF user profile. For information about the RACF user profile, see Setting up Network Security.

When a TP profile indicates that accounts are to be tailored, an installation can verify each transaction's account number with exit IEFUAV. For information about IEFUAV, see z/OS MVS Installation Exits.

Note: When account tailoring is requested and account numbers appear in both the TP profile JCL and the security profile, the security profile's account number overrides the TP profile's account number.

CLASS(class name)

Names the 1- through 8-character scheduler class into which the TP is scheduled. Classes set up scheduling characteristics, such as the maximum and minimum number of transaction initiators for the class, and the response time for each transaction.

Classes are named by CLASSADD statements in ASCHPMxx parmlib members. If no class is specified in the TP profile, APPC/MVS administration searches for a default class named by the OPTIONS statement in an ASCHPMxx parmlib member. For information about the ASCHPMxx parmlib member, see Defining Scheduling Characteristics with ASCHPMxx.

TPSCHED_TYPE(STANDARD|MULTI_TRANS)

Indicates whether the TP is scheduled as standard or multi-trans. The default is standard.

When a TP is scheduled as standard, an environment for the transaction is created, resources are allocated for its use, and the TP is initialized in its isolated environment. When the transaction completes, the resources are cleaned up and the TP ends.

When a standard TP issues or receives multiple allocate calls, each call causes re-allocation of resources and re-initialization of the TP, resulting in a new instance of the TP.

To enhance performance for TPs that are frequently invoked, you can write a multi-trans TP and specify a schedule type of multi-trans. Multi-trans programs assume responsibility for resource cleanup between transaction requests so that they can remain initialized for subsequent requests.

GENERIC_ID(generic user ID)

Names a generic user ID for a multi-trans program. Because the generic user ID covers processing that typically must be isolated from the different conversation partners, it must be secure from unauthorized specification or modification. To protect the generic user ID, you can use RACF or an equivalent security product to control read and update access to the TP profile where the generic user ID is specified. For more information, see Protecting Multi-Trans TP Profiles.

JCL_DELIMITER(delimiter2)

Marks the beginning of the JCL that will actually schedule and attach the TP, and identifies a delimiter that will be used to mark the end of the JCL. The delimiter can be from 1 through 59 characters but cannot be a character string that appears within the JCL itself. When you use the delimiter to mark the end of the JCL, it must appear on a line of its own starting in the first column.

JCL records

The JCL by which the TP is scheduled and attached. The JCL allowed in this section is a subset of all JCL statements. Two statements are required:

JOB statement, which is the place to specify limits. For tracking purposes, specify a unique jobname. If resources the TP uses are to be billed to an account that is not tailored, include an account number.
EXEC statement, which names the program to invoke the TP.
To print the TP message log, invoke the write log routine ASBSCHWL from a second EXEC statement. For information about the TP message log, see Logging Transaction Program Processing.

Note that DD statements, although not required by APPC/MVS, might be required by the program.

When certain job-related information is not specified, APPC/MVS administration searches for default information in a TPDEFAULT statement of an ASCHPMxx parmlib member. For information about TPDEFAULT, see Defining Default Scheduler Options — TPDEFAULT.

Examples and restrictions appear in Specific Scheduler JCL Information for TP Profiles.

KEEP_MESSAGE_LOG(ERROR|ALWAYS|NEVER)

Indicates the conditions under which messages are written to the TP message log data set. If ERROR is specified, messages are written only when an error occurs. ALWAYS indicates that messages at all times are written, and NEVER indicates that no messages are written. The default is ERROR.

This keyword works together with a MSGLEVEL keyword parameter that can be specified in the scheduler JCL section of the TP profile. (A default MSGLEVEL parameter is provided in the TPDEFAULT statement of the ASCHPMxx parmlib member.) The MSGLEVEL keyword controls the generation of messages and KEEP_MESSAGE_LOG controls writing the messages to the TP message log.

MESSAGE_DATA_SET(data set name)

Names the data set where TP messages are written. When no name is specified, the name defaults to &SYSUID.&SYSWUID.&TPDATE.&TPTIME.JOBLOG. The variables resolve to the following:

For a multi-trans TP, &SYSUID resolves to the generic userid. For a standard TP, &SYSUID resolves to the userid passed in with the inbound allocate request, unless security_none is used (no userid passed), and then &SYSUID resolves to SYSUID.
&SYSWUID resolves to the work unit identifier
&TPDATE resolves to the date that the TP ran. &TPDATE is in the form Dyyyyddd where yyyy is the year and ddd is the day of the year. The initial D simply identifies the qualifier as being a date.
&TPTIME resolves to the time that the TP ran. &TPTIME is in the form Thhmmss where hh is the hour (of a 24-hour clock), mm is the minutes, and ss is the seconds. The initial T simply identifies the qualifier as being a time.

Note:

You can use &SYSUID, &SYSWUID, &TPDATE, and &TPTIME as variables for any qualifiers in the data set name.
When an inbound allocate request has the security specification of security_none, no user ID is passed with the request, and the system variable &SYSUID resolves to SYSUID.

DATASET_STATUS(NEW|OLD|MOD)

Indicates the status of the TP message log data set. OLD indicates that a message log data set already exists and is cataloged. When messages are written to an old data set, they overwrite previous data. MOD indicates that a data set will be created and cataloged if it doesn't already exist. If it does exist, messages are added to the end of the data set. NEW indicates that the data set does not yet exist. The default is NEW.

Note: When the status of the TP message log is NEW, the disposition is CATALOG, which means the data set is kept once it is created. If a TP profile specifies KEEP_MESSAGE_LOG(ALWAYS), a new data set will be created each time the TP runs and message log data sets will accumulate.

STORAGE_CLASS(class name)

Names the 1- through 8-character storage class used to define a new SMS-managed message data set. If the message log data set is to be SMS-managed, this keyword is required. If not specified, dynamic allocation defaults are used to allocate the message data set.

Note: Use this keyword only when all of the following are true:

The data set is new.
SMS is available at your installation.
You want to create a SMS-managed message data set.

MANAGEMENT_CLASS(class name)

Names the 1- through 8-character management class for an SMS-managed message data set. For data sets already identified as SMS-managed (through a storage class name), SMS will provide a management class.

Note: Use this keyword only when all of the following are true:

The data set is new.
SMS is available at your installation.
You want to create a SMS-managed message data set.

DATA_CLASS(class name)

Names a 1- through 8-character data class for an SMS-managed message data set. The specified data class must have a record length of 133 bytes. For data sets already identified as SMS-managed (through a storage class name), SMS will provide a data class with a record length of 133 bytes.

Note: Use this keyword only when all of the following are true:

The data set is new.
SMS is available at your installation.
You want to create a SMS-managed message data set.