Option sets that the application program implements

Although VTAM® does not offer the option sets in this section, the application program can implement them. An application should verify VTAM's support for these option sets at assembly time with the ISTGAPPC macroinstruction, or at OPEN ACB time by examining the LU-6.2-function-list vector in the access-method-support vector list:

Get attributes (102): Enables a program to obtain attributes of a mapped conversation.
Post on receipt with wait (104): Enables a transaction program to request posting of multiple conversations and to wait (suspend its processing) until information is available on any one of the conversations. The functions available through VTAM (including the VTAM receive-any function and asynchronous return after issuing an APPCCMD macroinstruction) largely negate any need for this option set.
Sync point services (108): Enables a program to request synchronization point processing of all protected resources (any resource to which access is controlled) throughout the transaction. Transaction programs can synchronize their resources when partners in protected conversations fail or encounter errors. To keep databases consistent, a network of protected resources is built into a synchronization tree. Sync point services include the SYNCPT and BACKOUT verbs.
Get conversation type (110): Enables a program that supports both basic and mapped conversations to determine which category of verbs it should use in conjunction with a resource identifier.
Conversations between transaction programs located at the same LU (204): Enables a local transaction program to allocate a conversation to a remote transaction program located at the same LU as the local program. This option set is not available for applications that are either single-session capable or serving as a generic resource.
Send persistent verification (219): Enables a program to allocate consecutive conversations during which the conversation-level security information, once verified, remains verified for specific combinations of user identifiers, profiles, and partner LUs.
Receive persistent verification (220): Enables a program or an operator to designate the remote LUs from which the local LU can accept consecutive allocation requests that, once verified, remain verified for specific combinations of user identifiers, profiles, and partner LUs.
Password substitution (223): Enables an LU to send or receive tokens that represent an end user's password for an ALLOCATE.
A VTAM application indicates support for this option on the application capabilities vector. For more information, see Vector lists supplying information to VTAM.
Extended Security Sense Codes (225): Allows an LU to generate and return a more granular set of return codes for security errors during ALLOCATE. The more granular security return codes provide a greater level of detail in regards to the security failures on ALLOCATE. The use of the more granular return codes is indicated to the partner on the BIND. Option set 211 is a prerequisite.
A VTAM application indicates support for this option on the application capabilities vector. For more information, see Vector lists supplying information to VTAM. Extended security sense codes are listed in z/OS Communications Server: IP and SNA Codes.
Authentication using GSS-API Mechanisms (230): Allows a program or an operator to designate the remote LUs that are permitted to send to the local LU allocation requests carrying a DCE ticket based authentication information. This option set also allows the program allocating a conversation to specify that the allocation request carry DCE ticket based access security information determined by the local LU.
A VTAM application indicates support for this option on the application capabilities vector. For more information, see Vector lists supplying information to VTAM.
Optimization using GSS_Continue_Deferred (231): Allows an LU to optimize performance when using a GSS-API Authentication Mechanism that returns GSS_Continue_Deferred.
Option sets 230 and 243 are prerequisites.
Send PIP data (241): Enables the local program allocating a conversation to provide the remote program with program initialization parameter (PIP) data. VTAM offers pass-through support for this option by allowing PIP data on the FMH-5.
Receive PIP data (242): Enables the local program to receive some program initialization parameters from the remote program allocating a conversation. VTAM offers pass-through support for this option by allowing PIP data on the FMH-5.
Accounting (243): Enables an LU implementation to generate and send both a logical-unit-of-work (LUW) identifier and a conversation correlator (CC) to the remote LU.
Data mapping (246): Enables a program to request mapping of the data by the local and partner LUs. This is done through the use of mapped conversations.
FMH data (247): Enables programs to send and receive data records containing FM header data.
Mapped conversation LU services component (291): Enables implementation of a mapped conversation LU services component program, which processes mapped conversation verbs.
Logging of data in a system log (296): Enables a transaction program to record error information in the system's error log.