SNAX/APC Application Programming Manual Abstract SNAX/APC provides LU type 6.2 support for the Tandem implementation of SNA. This manual describes how to use SNAX/APC to write transaction programs that require LU 6.2 support. Product Version SNAX/APC D41.00 Supported Releases This manual supports G06.00 and all subsequent releases until otherwise indicated in a new edition.
Document History Part Number Product Version Published 064527 SNAX/APC D10 February 1993 098288 SNAX/APC C30 SNAX/APC D10 May 1993 111814 SNAX/APC D30 July 1995 138786 SNAX/APC D41.00 May 1998 New editions incorporate any updates issued since the previous edition. A plus sign (+) after a release ID indicates that this manual describes function added to the base release, either by an interim product modification (IPM) or by a new product version on a .99 site update tape (SUT).
SNAX/APC Application Programming Manual Glossary Index Figures Tables What’s New in This Manual ix Manual Information ix New and Changed Information ix About This Manual xi Who Should Read This Manual xi How This Manual Is Organized xi Related Documentation xi Your Comments Invited xiv Notation Conventions xiv 1.
1. Using the Application Program Interface (continued) Contents 1.
3. Verb Definitions (continued) Contents 3.
3. Verb Definitions (continued) Contents 3. Verb Definitions (continued) GET-TP-PROPERTIES Verb TP-END Verb 3-92 3-95 3-97 TP-READY Verb 4.
4. Application Prototype Simulator (continued) Contents 4.
Index Contents Index Figures Figure 1-1. Initial SNA Environment 1-12 Figure 1-2. Requesting a Conversation 1-14 Figure 1-3. Data Flow for Initiating a Conversation 1-15 Figure 1-4. Waiting for a Conversation 1-16 Figure 1-5. Data Flow Waiting for a Conversation 1-18 Figure 1-6. A Dispatched TP Figure 1-7. A Dispatched Conversation 1-21 Figure 1-8. Verb Flow for Requesting a Change to Send State Figure 1-9. Sending and Receiving a GDS Variable Figure 1-10.
Tables (continued) Contents Tables (continued) Table B-3. IPC Header Return Codes (HEADER-RETURN-CODE) B-1 Table B-4. IPC Header Return Code Detail Summary (HEADER-RETURN-CODEDETAIL) B-2 Table B-5. Verb Request Code Summary (REQ-UOW-CODE) Table B-6. UOW Return Codes (REP-RETURN-CODE) Table B-7. ALLOCATION-ERROR Return Code Detail (REP-RETURN-CODEDETAIL) B-5 Table B-8. DEALLOCATE-ABEND-PROG Return Code Detail (REP-RETURNCODE-DETAIL) B-5 Table B-9.
Contents SNAX/APC Application Programming Manual—138786 viii
What’s New in This Manual Manual Information SNAX/APC Application Programming Manual Abstract SNAX/APC provides LU type 6.2 support for the Tandem implementation of SNA. This manual describes how to use SNAX/APC to write transaction programs that require LU 6.2 support. Product Version SNAX/APC D41.00 Supported Releases This manual supports G06.00 and all subsequent releases until otherwise indicated in a new edition.
New and Changed Information What’s New in This Manual • • Added PS Header values to RECEIVE-AND-WAIT Processing on page 1-23. Added a new subsection, Support of APPC Sync Point Services in SNAX/APC on page 1-31. Section 2, Interprocess Communications and Units of Work contains the following changes: • • • • Added a new value for The IPC Header on page 2-4. Added information about the usage of the IPC Version Code, S5, to The IPC Header on page 2-4.
About This Manual Who Should Read This Manual This manual is for programmers writing distributed transaction programs (TPs) requiring LU 6.2 support. The SNAX Advanced Program Communication (SNAX/APC), the Tandem implementation of LU 6.2 services, provides support for the C, TAL, COBOL85, Pascal, and TACL programming languages.
SNAX/APC Manuals About This Manual SNAX/APC Manuals In addition to this manual, the following Tandem manuals relate specifically to SNAX/APC: • • • The SNAX/APC Configuration and Management Manual describes how to configure and manage SNAX/APC. The SNAX/APC Management Programming Manual provides information about how to use the SPI and EMS network management interfaces to programmatically interrogate, configure and control the SNAX/APC process, and interpret SNAX/APC EMS event messages.
Availability Information in Tandem Manuals About This Manual General Manuals The Introduction to SNA Capabilities of Tandem NonStop Systems provides information about the various products and solutions that Tandem offers for interfacing with IBM Systems Network Architecture (SNA) networks. Availability Information in Tandem Manuals Tandem provides several manuals which address issues of availability.
Your Comments Invited About This Manual • • • Systems Network Architecture Technical Overview continues the introduction begun in the concepts and products manual. It explains how SNA functions combine to provide communications facilities. Systems Network Architecture Reference Summary provides a technical summary of the structure and use of SNA and is an invaluable tool for anyone having to analyze an SNA session. It contains descriptions of all messages that flow in SNA sessions.
General Syntax Notation About This Manual [ ] Brackets. Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list may be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines.
Notation for Messages About This Manual Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example: CALL STEPMOM ( process-id ) ; If there is no space between two items, spaces are not permitted. In the following example, there are no spaces permitted between the period and any other items: $process-name.#su-name Line Spacing.
Notation for Messages About This Manual Bold Text. Bold text in an example indicates user input entered at the terminal. For example: ENTER RUN CODE ?123 CODE RECEIVED: 123.00 The user must press the Return key after typing the input. Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or returned exactly as shown. For example: Backup Up. lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned.
Notation for Management Programming Interfaces About This Manual Notation for Management Programming Interfaces The following list summarizes the notation conventions used in the boxed descriptions of programmatic commands, event messages, and error lists in this manual. UPPERCASE LETTERS. Uppercase letters indicate names from definition files; enter these names exactly as shown. For example: ZCOM-TKN-SUBJ-SERV lowercase letters.
1 Using the Application Program Interface This section will tell you what you need to be aware of to get the most from SNAX/APC. This includes decisions that you need to make, and also decisions that affect you but have been possibly made by other members of staff, such as the network planners, at your site. This section contains the following topics: • • • • • The first subsection, General Programming Considerations, describes general considerations for writing programs.
Using the Application Program Interface General Programming Considerations General Programming Considerations You can write a SNAX/APC TP in any of the following languages: • • • • • • • C, as a process COBOL (COBOL85), as a process Extended BASIC, as a process FORTRAN, as a process Pascal, as a process SCREEN COBOL, as a program executed by a terminal control program (TCP) TAL, as a process All SNAX/APC TPs communicate with the SNAX/APC server through the standard Tandem interprocess communication mec
Using the Application Program Interface Basic and Mapped Conversations general datastream (GDS) structures, which define the data transmitted on an LU 6.2 conversation. However, any TP, including application TPs (ATPs), may use basic conversations. Any data transmitted or received by a TP on a basic conversation will be in GDS format, and the TP must provide data in that format.
Using the Application Program Interface Version Levels of the IPC Header If the SNAX/APC TP is a target TP (not the originator of the conversation), when the TP-READY verb completes, the TP should issue a GET-TYPE verb and continue with the appropriate verb set. However if the conversation type is mapped, SNAX/APC will allow the local TP to issue basic verbs in a mixed-mode conversation. Using mixed-mode conversations requires additional coding in the SNAX/APC TP.
Using the Application Program Interface Version Levels of the IPC Header DEACTIVATE-SESSION If the IPC version code is S1, the LU has to be a single-session LU. If the LU is a parallel-session LU, the IPC is rejected. If the IPC version code is S2 or S3, the form of the verb specifies the session ID. The LU may use single or parallel sessions. Note. To deactivate a session using this verb, your application will need to know the session ID.
Using the Application Program Interface SCREEN COBOL Transaction Programs You do not have to activate and deactivate LU sessions just because SNAX/APC makes the verbs available. It may be the responsibility of your network support staff to control sessions. Just as adding and starting LUs is not really the responsibility of the application programmer, so starting and ending sessions need not be your responsibility either.
Qualified Opens Using the Application Program Interface For TPs written in COBOL, the definition for the (MC)RECEIVE-AND-WAIT data areas might be as follows: 01 MC-RWR-DATA-LENGTH 01 MC-RWR-DATA-AREA. 02 RWR-DATA-TEXT PIC 9(4) COMP VALUE 0. PIC X OCCURS 0 to N TIMES DEPENDING ON RWR-DATA-LENGTH. The DDL also describes how to create these definitions in COBOL and TAL.
Using the Application Program Interface Error Handling in all UOW headers in the IPC message. If one UOW fails the parameter check, the IPC header is returned with an error; SNAX/APC processes no UOWs in the IPC message. If the UOWs pass the parameter check but a UOW is still found in error while processing verbs, processing of the IPC message stops at the UOW in error.
Using the Application Program Interface Error Handling IPC; the file system discards the reply. Thus, a CANCEL message cancels the entire IPC, not just the single verb being processed when the message arrives. Every response to every verb in the outstanding IPC is lost when that IPC is cancelled. Support for CANCEL messages must be specifically enabled by specifying the CANCELSUPPORT startup parameter.
Using the Application Program Interface • Fault-Tolerant Programming General Conversational Verbs: If any verb other than those previously listed is in progress when SNAX/APC receives a CANCEL system message, SNAX/APC deactivates the session and replies to the cancelled IPC. SNAX/APC frees the internal resources after finishing the processing of the verb. Fault-Tolerant Programming The SNAX/APC server can be configured to run as a NonStop process pair.
Using the Application Program Interface Establishing Communication With the Local LU Establishing Communication With the Local LU A local TP initiates communication with the SNAX/APC server by sending a TPREADY request to it. There are three types of TP-READY requests: • • LOCAL-ATTACH = Y (TP is the source TP) The local TP initiates the conversation. Local attach means that the TP requests the SNAX/APC server to initiate the SNA ATTACH request processing.
Initial Environment Using the Application Program Interface Figure 1-1. Initial SNA Environment IBM Tandem SNA TP CICS SNAX/APC TP CDT 001.CDD Queuing TP-Ready Requests When SNAX/APC receives a remote ATTACH request, it first checks the TP-READY waiting queue for the LU that received the request. If a TP-READY request is already waiting on the queue, SNAX/APC satisfies the ATTACH request by sending a TP-READY reply to the local TP.
Using the Application Program Interface Initial Environment Once a resource ID has been assigned by SNAX/APC and returned to a TP in a TP-READY reply, that resource ID is used by the TP until the TP issues a TP-END request specifying that resource ID. A multithreaded TP can establish a number of concurrent conversations by issuing TPREADY requests to multiple single-session LUs, or multiple TP-READY requests to the same parallel-session LU.
Local Source TP Example Using the Application Program Interface 1. Issue a (MC)GET-ATTRIBUTES verb sometime before the end of the conversation. This will return, among other things, a session ID. 2. At the end of the conversation, issue a DEACTIVATE-SESSION verb using the appropriate session ID. Reusing Conversation Resources A TP that repeatedly allocates and deallocates conversations using the same local LU can reuse its conversation resources by issuing a single TP-READY request.
Local Source TP Example Using the Application Program Interface FMH-5 message sent to the remote LU, indicating the name of the remote TP with which the local TP wants to communicate.) 5. The remote LU processes the ATTACH request and associates it with the remote TP. When the local TP receives the ALLOCATE reply, it can begin to send data to the remote TP, using the SEND-DATA verb. Another Way of Looking at the Same Dataflow Figure 1-3 illustrates the same process. Figure 1-3.
Local Target TP Example Using the Application Program Interface Local Target TP Example The local SNAX/APC process can receive an ATTACH request from a remote TP in two instances: • • The local TP exists and is waiting for an ATTACH request from a remote TP. The local TP does not exist but is created by the Dispatcher on receipt of a remote ATTACH request. Figure 1-4 illustrates the situation in which the local TP already exists. Figure 1-4.
Using the Application Program Interface Local Target TP Example 4. The remote LU sends an ATTACH to the local LU, and includes the data (and a request for confirmation) as part of the same message. The SNAX/APC process receives an ATTACH request for the local TP from the partner LU. 5. The server completes the ATTACH request by dequeuing the TP-READY request and sending a TP-READY reply to the local TP. Note.
Local Target TP Example Using the Application Program Interface Figure 1-5.
DISPATCHED Request Example Using the Application Program Interface • • If the REPLY-RETURN-CODE field contains RC-OK, the TP can check the WHAT-RECEIVED field to determine the type of data received. DATA or DATA-COMPLETE indicates success. (In Figure 1-5 the local TP receives the indication DATA in WHAT-RECEIVED because it specified FILL-BUFFER on the RECEIVE-AND-WAIT verb request.) If the REPLY-RETURN-CODE field contains DEALLOCATE-NORMAL, the TP must issue DEALLOCATE (LOCAL).
Using the Application Program Interface DISPATCHED Request Example 2. The SNAX/APC process receives an ALLOCATE request from the partner LU for a specific local TP that has not been started. The SNAX/APC process queues the ALLOCATE request until it receives a TP-READY from the requested TP. 3. The SNAX/APC process dequeues the DISPATCHER-READY request and sends a DISPATCHER-READY reply to the SNAX/APC Dispatcher. The reply includes the name of the requested TP. 4.
DISPATCHED Request Example Using the Application Program Interface Another Way of Looking at the Same Dataflow Figure 1-7 illustrates the same conversation illustrated in Figure 1-6. Figure 1-7.
Using the Application Program Interface TP Conversation States TP Conversation States When a TP participates in a conversation, a set of states defines when the TP can issue specific conversational verb requests. The states are defined by LU 6.2. The state of a particular TP can change due to verbs issued by the local TP, verbs issued by the remote TP, or errors in the SNA network.
Using the Application Program Interface Parsing SNAX/APC Reply Messages Any violation of conversation states will result in immediate deallocation of the conversation. Parsing SNAX/APC Reply Messages When you receive a reply to a SNAX/APC request (a service UOW, a control operator verb, or a conversational verb), the following steps are recommended to ensure that the request completed correctly: 1.
Using the Application Program Interface RECEIVE-AND-WAIT Processing normal conditions). It should also be understood under what conditions a TP can issue a (MC)SEND-ERROR or (MC)DEALLOCATE (ABEND) verb request. When a TP issues (MC)SEND-ERROR, it enters Send state; further action must be determined by transaction conventions. The recommended way to prepare for information from the SNAX/APC server is to write a loop in the TP, at the beginning of which is a (MC)RECEIVE-AND-WAIT verb request.
Using the Application Program Interface • Changing Send and Receive States If WHAT-RECEIVED indicates CONFIRM-DEALLOCATE (value 6), the TP must issue a CONFIRMED or SEND-ERROR verb request to the remote TP. • • If the CONFIRMED verb request completes successfully, the TP enters Deallocate state and must issue a DEALLOCATE LOCAL verb request. If a TP issues a SEND-ERROR verb request in response to CONFIRM, CONFIRM-SEND, or CONFIRM-DEALLOCATE, the TP enters Send state.
Data Exchanged Using SNAX/APC Using the Application Program Interface Figure 1-8.
Using the Application Program Interface Basic Conversations Basic Conversations Basic conversations (those using basic verbs) define a logical record as the elementary unit of information transferred between TPs. A logical record consists of the two-byte length prefix (LL) followed by up to 32,767 bytes of data. A pair of LU 6.2 LUs transmit and receive data as General Data Stream (GDS) variables. GDS variables consist of a four-byte GDS header, followed by the data.
Using the Application Program Interface GDS Variables and TP Data Note that SNAX/APC buffering is totally transparent to the receiving TP. The receiving TP’s RECEIVE-AND-WAIT verb request completes only when its buffer is full or when it receives one complete logical record (depending on the fill code). GDS Variables and TP Data When a TP sends or receives data using SNAX/APC, it must format or interpret GDS variables.
GDS Variables and TP Data Using the Application Program Interface Figure 1-9.
GDS Variables and TP Data Using the Application Program Interface Finally, Figure 1-11 illustrates the case in which the data sent exceeds the size of the GDS variable. In this case, the TP split the data into two segments, each less than 32,767 bytes long, and set the continuation indicator in the first segment of the GDS variable. Figure 1-11. Using the GDS Continuation Indicator Data (>32767 Bytes) Data 1 LL Continuation Indicator Set ID Data 0 LL Data Continuation Indicator Clear CDT 011.
Using the Application Program Interface Support of APPC Sync Point Services in SNAX/APC Support of APPC Sync Point Services in SNAX/APC General Description of Sync Point Services The APPC architecture describes the synchronization point (sync point) services as follows. The sync point services allow all Transaction Programs (TPs) processing a distributed transaction to coordinate error recovery and maintain consistency among distributed resources such as data bases.
Using the Application Program Interface What You Must Do to Use Sync Point With SNAX/APC that affect the integrity of changes, and commits or backs out the changes as determined by the sync point protocol to each protected resource. • Resynchronization TP: Resynchronization uses service transaction programs to exchange sync point status among the LUs during an LU failure which might occur during the sync point protocol, so that some LU never receives an expected LUW status report.
Using the Application Program Interface The SNAX/APC Implementation The SNAX/APC Implementation From the point of view of the local SNAX/APC user, sync point support is controlled by the SNAX/APC configuration. Including sync point information in TP requests may require changes in the actual TP, depending on how it was designed.
Sync Point Session and Conversation Activation Using the Application Program Interface Table 1-1.
Using the Application Program Interface Presentation Services (PS) Header Support in Data Transfer The GET-TP-PROPERTIES verb returns this LUWID in the UNPROTECTED-LUWIDENTIFIER or PROTECTED-LUW-IDENTIFIER field of its reply, depending on the session allocation sync level. When SNAX/APC receives an ALLOCATE request from the TP, it validates the ALLOCATE request for the SYNC-LEVEL parameter.
Presentation Services (PS) Header Support in Data Transfer Using the Application Program Interface Figure 1-12. Normal Sync Point Data Flow Local Transaction Program User-Supplied SPM Initiator SNAX/APC Remote SPM Agent Remote Transaction Program SYNCPT SEND-DATA (PREPARE) TAKE_SYNCPT SYNCPT SEND-DATA (REQUEST COMMIT) SEND-DATA (COMMITTED) SEND-DATA (FORGET) RC = OK CDT 999.
2 Interprocess Communications and Units of Work This section describes the application program interface that transaction programs (TPs) use to communicate with SNAX/APC.
IPC Message Structure Interprocess Communications and Units of Work IPC Message Structure TPs communicate with the SNAX/APC system through the Tandem file system using a message-oriented application program interface. The basic unit of communication is an interprocess communication or IPC message. The IPC messages flow in both directions, both to and from SNAX/APC.
IPC Message Structure Interprocess Communications and Units of Work Figure 2-2. IPC Message Structure IPC Header UOW UOW UOW CDT 013.CDD For example, a single IPC message might contain the UOWs ALLOCATE, SENDDATA, SEND-DATA, and CONFIRM. In this example, these four UOWs are issued and completed in a single WRITEREAD procedure call. Although you have the ability to enclose multiple UOWs in a single IPC message, you should nevertheless be careful in your choice of UOWs.
The IPC Header Interprocess Communications and Units of Work A reply from SNAX/APC to the TP is similar in form to the request shown in Figure 2-2. The reply consists of the following: • • An IPC header, with reply and return codes supplied by the SNAX/APC system One or more reply UOWs, also with reply and return codes The reply from SNAX/APC contains one reply UOW for each successfully processed request UOW.
The IPC Header Interprocess Communications and Units of Work 02 02 02 02 88 INVALID-RCVD-LENGTH 88 CONFIG-ERROR 88 INVALID-SESSION-ID 88 SYNCPT-NOT-ENABLED 88 PROCESS-RESET 88 MULT-UOW-NOT-ALLOWED 88 PREVIOUS-IPC-NOT-COMPLETED 88 MULT-ALLOC-NOT-ALLOWED 88 TP-RQ-NOT-SUPPORTED 88 LU-STOPPED 88 PTNR-LU-STOPPED 88 PTNR-MODE-STOPPED 88 TPN-STOPPED 88 TPI-ABORTED 88 IPC-VERSION-MISMATCH 88 VERB-NOT-ALLOWED-FOR-PS-LU 88 IPC-OUT-OF-BUFFER 88 INVALID-SNAX-DEV-TYPE 88 SYNC-LEVEL-NOT-SUPPTD-BY-LU RESOURCE-ID PIC UO
Interprocess Communications and Units of Work The IPC Header REQ-ERROR (3) SNAX/APC detected an error in the IPC header or in one of the UOW headers; or a SNAX/XF or SNAX/CDF error occurred while processing the IPC message. None of the UOWs were processed. The IPC reply contains only the IPC reply header. See the IPC return code for the actual error. VERSION-CODE In both verb requests and replies, this field contains the version of the SNAX/APC interface used.
Interprocess Communications and Units of Work IPC Return Codes LOG-LEVEL Reserved for future use. This field should be set to 0 to avoid future incompatibility. IPC Return Codes Table 2-1 describes the return codes that can be returned in the HEADER-RETURNCODE field of the IPC reply message. (Additional information is returned in the HEADER-RETURN-CODE-DETAIL field for values 2, 3, 4, and 9. Refer to Table 2-2) Table 2-1.
IPC Return Code Details Interprocess Communications and Units of Work Table 2-1. IPC Header Return Codes (page 2 of 2) Value Label Meaning 8 INVALID-REQCODE The value in the REQUEST-CODE field was invalid. 9 SNAX-FILEERROR The SNAX/APC process received an operating system error from SNAX/XF or SNAX/CDF while processing the verb request. The HEADER-RETURN-CODE-DETAIL field contains the operating system error number.
IPC Return Code Details Interprocess Communications and Units of Work Table 2-2. IPC Return Code Details (page 2 of 3) HEADER-RETURNCODE HEADER-RETURNCODE-DETAIL Value Label Value Label Meaning 3 SEVICEDENIED (Cont.) 406 LU-STOPPED A TP-READY verb was issued specifying a local SNAX/APC LU that was in the stopped state. Start the LU and subordinate objects using SCF. 407 PTNR-LUSTOPPED This code is not currently returned. 408 PTNR-MODESTOPPED This code is not currently returned.
IPC Return Code Details Interprocess Communications and Units of Work Table 2-2. IPC Return Code Details (page 3 of 3) HEADER-RETURNCODE HEADER-RETURNCODE-DETAIL Value Label Value Label Meaning 3 SEVICEDENIED (Cont.) 417 SYNC-LEVELNOT-SUPPTDBY-LU Returned if the ADD LU specified LOCAL-LU-SYNC2-SUPPORT NONE and the TP^READY specifies SYNC-SUPPORT Y.
Interprocess Communications and Units of Work Structure of the UOW Headers Structure of the UOW Headers User transaction programs (TPs) interact with SNAX/APC through verb requests and replies. These verb requests and replies are in the form of Units of Work (UOWs), which implement the functions described in the following subsection. IPC messages can contain multiple UOWs (provided that all of the UOWs are intended for the same conversation). All UOWs in an IPC message must be word-aligned.
Interprocess Communications and Units of Work UOW Classes TP-END This releases all resources allocated to a TP by one TP-READY, essentially canceling the TP-READY. A local TP must issue a TP-END verb request when it has completed the last conversation associated with a TP-READY. This results in the destruction of the TP instance. Control Operator Verb UOWs Control operator verbs are defined by LU 6.2. As a category, control operator verbs perform functions that aid operators in controlling LUs.
Interprocess Communications and Units of Work UOW Classes queries the local SNAX/APC process for information about the conversation attributes. PREPARE-TO-RECEIVE and MC-PREPARE-TO-RECEIVE prepares the local TP to receive data by changing it from the Send state to the Receive state. RECEIVE-AND-WAIT and MC-RECEIVE-AND-WAIT waits for and receives information from the remote TP.
Interprocess Communications and Units of Work UOW Request Headers UOW Request Headers All UOWs begin with a standard UOW header followed by the request fields unique to each UOW. The COBOL data definition for the standard header is: ?SECTION QUALIFIED-REQ-HEADER,TANDEM 01 QUALIFIED-REQ-HEADER. 02 REQ-UOW-ID PIC X(2).
Interprocess Communications and Units of Work UOW Reply Headers UOW Reply Headers Each reply UOW returned by the SNAX/APC system also begins with the same standard header, followed by two return-code fields and the reply fields specific to each verb. The COBOL data definition for the common fields of each reply is: ?SECTION QUALIFIED-REP-HEADER,TANDEM 01 QUALIFIED-REP-HEADER. 02 REP-UOW-ID PIC X(2). 02 REP-VERB-CODE PIC 9(4) COMP. 88 ACTIVATE-SESS-REP-CODE VALUE IS 2001.
Interprocess Communications and Units of Work UOW Reply Headers 88 RC-PARAMETER-ERROR VALUE IS 1006. 88 RC-PROGRAM-ERROR-NO-TRUNC VALUE IS 1007. 88 RC-PROGRAM-ERROR-PURGING VALUE IS 1008. 88 RC-PROGRAM-ERROR-TRUNC VALUE IS 1009. 88 RC-RESOURCE-FAIL-NO-RETRY VALUE IS 1010. 88 RC-RESOURCE-FAIL-RETRY VALUE IS 1011. 88 RC-SVC-ERROR-NO-TRUNC VALUE IS 1012. 88 RC-SVC-ERROR-PURGING VALUE IS 1013. 88 RC-SVC-ERROR-TRUNC VALUE IS 1014. 88 RC-UNSUCCESSFUL VALUE IS 1015. 88 RC-DEALLOCATE-ABEND VALUE IS 1016.
UOW Return Codes Interprocess Communications and Units of Work The individual fields in the standard UOW reply header contain the following information: REP-UOW-ID This field contains the value ST, identifying the beginning of a UOW. REP-VERB-CODE This field contains a value identifying the type of verb request UOW to which this reply corresponds. For example, if the verb request UOW is an ALLOCATE verb (code 1001), the reply UOW header also contains 1001.
UOW Return Codes Interprocess Communications and Units of Work Table 2-3. UOW Return Codes (page 2 of 4) Value Label Meaning 1003 RC-DEALLOCATEABEND-SVC The remote TP issued a DEALLOCATE verb with TYPE(ABEND-SVC) specified. If the remote TP was in the Receive state, any data sent by the local TP and not yet received by the remote TP is purged. The local TP is in the deallocate state after receiving this return code. 1005 RC-DEALLOCATENORMAL The remote TP requested conversation deallocation.
UOW Return Codes Interprocess Communications and Units of Work Table 2-3. UOW Return Codes (page 3 of 4) Value Label Meaning 1013 RC-SVC-ERRORPURGING The remote TP issued a SEND-ERROR (SVC) verb from receive or confirm state. The local TP enters Receive state. The SEND-ERROR verb purges any information sent to the remote TP but not yet received by the remote TP.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-3. UOW Return Codes (page 4 of 4) Value Label Meaning 1025 RC-PROGRAMSTATE-CHECK The local TP issued a verb that is not valid in the current program state. The conversation state remains unchanged. 1027 RC-BACKOUT-NORESYNC The sending TP is directing that the LUW (Logical Unit of Work) be backed out without resynchronization.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-4. UOW Return Code Details (page 1 of 4) REP-RETURN-CODE REP-RETURN-CODEDETAIL Value Label Value Label Meaning 1001 RCALLOCATIONERROR 1 RCD-ALLOCFAIL-NORETRY The allocation failed because of an error condition that is not temporary (for example, SNAX/APC received an abnormal UNBIND request from the partner LU). The local TP should issue DEALLOCATE (LOCAL) and then TP-END.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-4. UOW Return Code Details (page 2 of 4) REP-RETURN-CODE REP-RETURN-CODEDETAIL Value Label Value Label Meaning 1001 RCALLOCATIONERROR (Cont.) 7 RCD-TPNOTAVAILRETRY The remote LU rejected an allocation request because the local TP specified a remote TP name that the remote LU recognizes but currently cannot start. This condition can be temporary, and the TP can retry the allocation request later.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-4. UOW Return Code Details (page 3 of 4) REP-RETURN-CODE REP-RETURN-CODEDETAIL Value Label Value Label Meaning 1006 RCPARAMETERERROR (Cont.) 4 SYNCLVLNOT-SUPPTD The local TP does not support sync point. 5 IMPROPERSYNCLEVEL A PREPARE-TO-RECIEVE or DEALLOCATE verb was issued with synchronization level SYNCPT. 6 PS-HEADERNOT-SUPPTD A PS Header was received that is not supported by SNAX/APC.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-4. UOW Return Code Details (page 4 of 4) REP-RETURN-CODE REP-RETURN-CODEDETAIL Value Value Label Meaning 4 RCD-CHARMAPPINGFAILED The conversation was terminated because character translation failed. This return code detail could be returned to the MCSEND-DATA, MC-RECEIVEAND-WAIT, or MC-RECEIVEIMMEDIATE verbs. The conversation is automatically deallocated by SNAX/APC as the program abends.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-5 and Table 2-6 show which return codes can be returned for the different conversational verbs. Note. The CONFIRMED, FLUSH, GET-ATTRIBUTES, and REQUEST-TO-SEND do not return status codes and, thus, have been omitted. X The cells marked with the letter X indicate that the return code is returned in the verb reply message. D The cells marked with the letter D indicate that the return code is delayed from an earlier operation.
UOW Return Code Details Interprocess Communications and Units of Work Table 2-5. Return Codes for Conversational Verbs (page 2 of 2) Conversational Verbs Return Codes Alloc Conf Deall P-R PROGRAM-ERRORTRUNC R-W R-I X X S-D S-E RESOURCE-FAIL-NORETRY X X X X X X X RESOURCE-FAIL-RETRY X X X X X X X UNSUCCESSFUL X X Table 2-6 shows return codes that only apply to basic, not mapped, verbs. Table 2-6.
3 Verb Definitions This section describes the request and reply formats for the SNAX/APC verbs (UOWs). The verbs are presented in the following groups: • • • • • Control verbs—intended for use by control-operator TPs, that is, programs that assist the control operator in performing functions related to the control of an LU. Basic conversation verbs—intended for use by LU services programs.
Control Verbs Verb Definitions Control Verbs Control, or Control-operator, verbs are intended for use by control-operator TPs, that is programs that assist the control operator in performing functions related to the control of an LU. ACTIVATE-SESSION Verb Use the ACTIVATE-SESSION verb to activate a session explicitly. This verb does not start a conversation; it simply initiates an LU-LU session through sending or requesting a BIND. To use ACTIVATE-SESSION, a TP must have session-control authorization.
ACTIVATE-SESSION Verb Verb Definitions AS-MODENAME This field specifies the PTNR-MODE under which the session will be established. If the field contains blanks (spaces), the default MODE-NAME is implied. The MODE-NAME must have been configured under the partner LU name specified in the first field of this verb.
DEACTIVATE-SESSION Verb Verb Definitions DEACTIVATE-SESSION Verb Use the DEACTIVATE-SESSION verb to deactivate a session explicitly. DEACTIVATE-SESSION completes immediately; it does not wait for the deactivation to complete. A TP must have session-control authorization to use DEACTIVATE-SESSION. Session-control authorization is determined by the SESSION-CONTROL attribute of the TPN object that is configured using SCF.
Single Session Verb Definitions APC-DEACTIVATE-NORMAL (NO) SNAX/APC deactivates the session normally. If a conversation is active, deactivation waits until the conversation is deallocated. Deactivation occurs immediately if no conversation is active. APC-DEACTIVATE-CLEANUP (CL) SNAX/APC deactivates the session immediately, regardless of conversation status. An application can use cleanup to deactivate a hung conversation.
Parallel Sessions Verb Definitions Parallel Sessions For parallel-session LUs, the request format for DEACTIVATE-SESSION verb is as follows: Request Format ?SECTION DEACTIVATE-SESS-REQ,TANDEM 01 DEACTIVATE-SESS-REQ. 02 DA-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 DA-PARAMETERS. 03 DA-SESSION-ID 03 DA-PAD 03 DA-TYPE 88 APC-DEACTIVATE-NORMAL 88 APC-DEACTIVATE-CLEANUP PIC X(2). PIC 9(4) COMP. PIC X(4). PIC X(4). PIC X(2). VALUE IS "NO". VALUE IS "CL".
Basic Conversation Verbs Verb Definitions Basic Conversation Verbs The basic conversation verbs are intended for use by LU services programs. The LU services programs can provide end-user services or protocol boundaries for end-user application transaction programs. For example, the mapped conversation LU services component issues basic conversation verbs during its processing of mapped conversation verbs. Not all verbs from all the IBM option sets have been implemented.
ALLOCATE Verb Verb Definitions ALLOCATE Verb A TP uses the ALLOCATE verb to establish a conversation with a remote TP. ALLOCATE should be the first verb issued after a TP has locally attached itself to the SNAX/APC process (using a LOCAL TP-READY request). A TP can also allocate other TPs after being attached by a remote TP.
ALLOCATE Verb Verb Definitions The ALLOCATE verb has a separate request format for S3 or S5 version code requests. Request Format (IPC Version Code S1 or S2) ?SECTION ALLOCATE-REQ,TANDEM 01 ALLOCATE-REQ. 02 AL-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 AL-PARAMETERS. 03 AL-PARTNER-TP-TYPE 03 AL-SYNC-LEVEL 88 MC-AL-SYNC-LEVEL-CONFIRM 88 MC-AL-SYNC-LEVEL-NONE 03 AL-RET-CONTROL. 88 WHEN-SESSION-ALLOCATED 88 IMMEDIATE 03 AL-PARTNER-LUNAME 03 AL-MODENAME 03 AL-PARTNER-TPNAME PIC X(2). PIC 9(4) COMP. PIC X(1).
ALLOCATE Verb Verb Definitions Reply Format ?SECTION ALLOCATE-REP,TANDEM 01 ALLOCATE-REP. 02 ALR-HEADER. 03 REP-UOW-ID 03 REP-VERB-CODE 03 REP-RETURN-CODE 03 REP-RETURN-CODE-DETAIL PIC PIC PIC PIC X(2). 9(4) S9(4) S9(4) COMP. COMP. COMP. Request Details REQ-UOW-CODE This field must contain the value 1001, which identifies the ALLOCATE verb. AL-PARTNER-TP-TYPE This field indicates whether the remote TP can use mapped or basic conversational verbs.
ALLOCATE Verb Verb Definitions Allocation is successful if a session (established under the appropriate mode) is active, the session is not yet allocated to another conversation, and the local TP has control of the session. AL-PARTNER-LUNAME This field contains the name of the remote LU that supports the remote TP. The remote LU must be configured as a partner of the local LU. The remote LU name must be in uppercase letters.
ALLOCATE Verb Verb Definitions AL-PASSWORD This field contains the password when the SECURITY-TYPE field contains the letter P. This field is ignored when the SECURITY-TYPE field contains either the letter N or the letter S.
ALLOCATE Verb Verb Definitions • • • If an ALLOCATE verb is issued with the AL-RET-CONTROL field set to %H0000, two spaces, or AL, SNAX/APC waits for a session with the specified partner, using the specified mode, to become free. If an ALLOCATE verb is processing when SNAX/APC receives a CANCEL system message from the application program, SNAX/APC replies to the cancelled IPC immediately. The ALLOCATE verb is allowed to finish normally.
CONFIRM Verb Verb Definitions CONFIRM Verb The CONFIRM verb requests confirmation of receipt of data or completion of some function. This verb flushes the buffer of data waiting to be sent (sending the data to the remote TP) and requests an explicit confirmation from the remote TP when it has received the data. CONFIRM completes when SNAX/APC receives a confirmation or error reply from the remote TP. Request Format ?SECTION CONFIRM-REQ,TANDEM 01 CONFIRM-REQ. 02 CM-HEADER.
CONFIRM Verb Verb Definitions Return Codes The following return codes can be returned in the REP-RETURN-CODE field of the CMR-HEADER: RC-OK (remote TP replied with CONFIRMED) RC-ALLOCATION-ERROR RC-BACKOUT-RESYNC RC-BACKOUT-NO-RESYNC RC-DEALLOCATE-ABEND-PROG RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Consideration If a CONFIRM verb is processing when SNAX/APC receives a CANCEL system message from the application program, SNAX/APC deactivates the session and replies to the c
CONFIRMED Verb Verb Definitions CONFIRMED Verb A TP uses the CONFIRMED verb request to acknowledge receipt of data or completion of a function. When the local TP receives a CONFIRM indication in the WHAT-RECEIVED field of a RECEIVE-AND-WAIT or RECEIVE-IMMEDIATE reply, it must use CONFIRMED to acknowledge that the data has been received or processed correctly. CONFIRMED completes immediately; if the local TP chooses to reject the data, it can issue a SENDERROR verb.
DEALLOCATE Verb Verb Definitions DEALLOCATE Verb The local TP uses the DEALLOCATE verb to end a conversation with a remote TP. There are five types of deallocation requests: DEALLOCATE (FLUSH) DEALLOCATE (CONFIRM) DEALLOCATE (SYNC-LEVEL) DEALLOCATE (LOCAL) DEALLOCATE (ABEND-PROG) DEALLOCATE (FLUSH) completes when the SNAX/APC process’s internal buffer has been flushed and the local resources have been deallocated.
DEALLOCATE Verb Verb Definitions DE-TYPE The type of deallocation used is dependent on the state and synchronization level of the conversation. The following symbols are defined in the SNAX/APC DDL definitions: APC-DEALLOCATE-SYNC-LEVEL (SL) If the synchronization level is CONFIRM, the action is the same as for APC-DEALLOCATE-CONFIRM (CO). If the synchronization level is NONE, the action is the same as for APC-DEALLOCATE-FLUSH (FL).
DEALLOCATE Verb Verb Definitions Return Codes The following return codes can be returned in the REP-RETURN-CODE field of DER-HEADER: RC-OK RC-ALLOCATION-ERROR RC-DEALLOCATE-ABEND-PROG RC-IMPROPER-SYNCLEVEL-PARAM RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Considerations • • • • • If the local TP receives WR-CONFIRM-DEALLOCATE in the WHAT-RECEIVED field of a RECEIVE-AND-WAIT or RECEIVE-IMMEDIATE reply, it is in the CONFIRM state.
FLUSH Verb Verb Definitions FLUSH Verb The local TP uses the FLUSH verb to force the transmission of the local LU’s send buffer. The local LU transmits the contents of the send buffer to the partner LU. The verb completes when the contents of the buffer have been transmitted. If the send buffer is empty, nothing is transmitted and the verb completes immediately. Because SNAX/APC does not support the sync-point synchronization level, the FLUSH verb can be issued only when the local TP is in the Send state.
GET-ATTRIBUTES Verb Verb Definitions GET-ATTRIBUTES Verb The local TP uses the GET-ATTRIBUTES verb request to query the local SNAX/APC process for information about the conversation. GET-ATTRIBUTES has no impact on the remote TP or remote LU. Local TPs that wait for a remote attach or dispatch can issue GET-ATTRIBUTES immediately on startup to determine the synchronization level for the conversation. GET-ATTRIBUTES completes immediately.
GET-ATTRIBUTES Verb Verb Definitions Reply Details GAR-SYNC-LEVEL This field contains the synchronization level for the conversation. The three possible values are N for NONE, C for CONFIRM and S for SYNCPT. If the synchronization level is NONE, the confirm verb cannot be issued in the conversation. GAR-APC-LUNAME This field contains the name of the local LU, as described in the SNAX/APC configuration database.
PREPARE-TO-RECEIVE Verb Verb Definitions PREPARE-TO-RECEIVE Verb The local TP issues the PREPARE-TO-RECEIVE verb to change its state from the Send state to the Receive state. This prepares the local TP to receive data from the partner TP with a subsequent RECEIVE-AND-WAIT verb or RECEIVE-IMMEDIATE verb. The local TP must be in the Send state to issue the PREPARE-TO-RECEIVE verb. Request Format ?SECTION PREP-TO-RECEIVE-REQ,TANDEM 01 PREP-TO-RECEIVE-REQ. 02 PR-HEADER. 03 REQ-UOW-ID PIC X(2).
PREPARE-TO-RECEIVE Verb Verb Definitions Otherwise, the return code indicates the new state of the conversation. SNAX/APC rejects a CO request if the synchronization level of the conversation is NONE. FL This specifies that SNAX/APC is to transmit the contents of the local LU’s send buffer to the partner TP and then place the conversation in the Receive state. The PREPARE-TO-RECEIVE verb completes as soon as the local LU’s send buffer is transmitted; no confirmation is required.
PREPARE-TO-RECEIVE Verb Verb Definitions Return Codes If PREPARE-TO-RECEIVE is issued with PR-TYPE set to FL or PR-TYPE set to SL and the synchronization is NONE, the following return code is returned in REP-RETURN-CODE of PRR-HEADER: RC-OK If PREPARE-TO-RECEIVE is issued with PR-TYPE set to CO or PR-TYPE set to SL and the synchronization is CONFIRM, the following return codes can be returned in REP-RETURN-CODE of PRR-HEADER: RC-OK RC-ALLOCATION-ERROR RC-DEALLOCATE-ABEND-PROG RC-IMPROPER-SYNCLEVEL-PARAM R
RECEIVE-AND-WAIT Verb Verb Definitions RECEIVE-AND-WAIT Verb The local TP issues RECEIVE-AND-WAIT when it is ready to receive data or control information from the remote TP. The local TP can issue RECEIVE-AND-WAIT while in Send state to flush the data buffer and cause a transition to Receive state. Successful completion of the RECEIVE-AND-WAIT verb occurs when the local TP receives data or information from the remote TP. The WHAT-RECEIVED indicator informs the local TP of the type of information received.
RECEIVE-AND-WAIT Verb Verb Definitions 01 RWR-DATA-LENGTH 01 RWR-DATA-AREA. 02 RWR-DATA-TEXT PIC 9(4) COMP VALUE 0. PIC X OCCURS 0 TO N TIMES DEPENDING ON RWR-DATA-LENGTH. Request Details REQ-UOW-CODE This field must contain the value 1006, which identifies the RECEIVE-AND-WAIT verb. RESERVED-1 This field must contain the value 0 or a space (ASCII 32). RW-FILL This field indicates whether the data will be received one logical record at a time or when the receive buffer is full.
RECEIVE-AND-WAIT Verb Verb Definitions RWR-REQ-TO-SEND-IND This field indicates whether the remote TP issued a REQUEST-TO-SEND verb. If the field contains the letter Y, REQUEST-TO-SEND notification was received from the remote TP, which requests the local TP to enter Receive state. The local TP should use RECEIVE-AND-WAIT to enter Receive state as soon as possible. If the field contains the letter N, the remote TP did not issue a REQUEST-TO-SEND verb.
RECEIVE-AND-WAIT Verb Verb Definitions WR-CONFIRM-DEALLOCATE (6) The remote TP issued a DEALLOCATE verb with type CONFIRM or with type SYNC-LEVEL; the synchronization level is CONFIRM. The local TP can respond with either CONFIRMED or SEND-ERROR. If the local TP sends the CONFIRMED verb request, it enters Deallocate state. From Deallocate state, the local TP must issue a DEALLOCATE verb request specifying LOCAL. If the local TP sends the SEND-ERROR verb, it enters Send state.
RECEIVE-AND-WAIT Verb Verb Definitions Return Codes If the RECEIVE-AND-WAIT verb is issued in the Send state, the following return codes can be returned in REP-RETURN-CODE of RWR-HEADER: RC-OK RC-ALLOCATION-ERROR RC-BACKOUT-NO-RESYNC RC-BACKOUT-RESYNC RC-DEALLOCATE-ABEND-PROG RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY If the RECEIVE-AND-WAIT verb is issued in the Receive state, the following return codes can be returned in REP-RETURN-CODE of RWR-HEADER: RC-OK RC-ALLOCATION-E
RECEIVE-AND-WAIT Verb Verb Definitions • When the remote TP issues a DEALLOCATE FLUSH verb request, the local TP receives notification (RC-DEALLOCATE-NORMAL) in RWR-RETN-CODE (first the TP receives the flushed data with RC-OK; on the next RECEIVEAND-WAIT verb request, the local TP receives DEALLOCATE-NORMAL). Thus, a return code other than RC-OK does not necessarily indicate that an error occurred.
RECEIVE-IMMEDIATE Verb Verb Definitions RECEIVE-IMMEDIATE Verb The local TP issues the RECEIVE-IMMEDIATE verb to receive any data or control information that is immediately available from the partner TP. The RECEIVEIMMEDIATE verb does not wait for information to arrive from the partner TP. The information, if available, can be data, conversation status, or a request for confirmation.
RECEIVE-IMMEDIATE Verb Verb Definitions 01 RIR-DATA-LENGTH 01 RIR-DATA-AREA. 02 RIR-DATA-TEXT PIC 9(4) COMP VALUE 0. PIC X OCCURS 0 TO N TIMES DEPENDING ON RIR-DATA-LENGTH. Request Details REQ-UOW-CODE This field must contain the value 1011, which identifies the RECEIVEIMMEDIATE verb. RESERVED-1 This field must contain the value 0 or space (ASCII 32). RI-FILL This field specifies the unit of data to be returned to the local TP in the reply.
RECEIVE-IMMEDIATE Verb Verb Definitions Reply Details RESERVED-1 This field is not used by SNAX/APC and should be ignored by the TP. RIR-REQ-TO-SEND-IND This field indicates whether the remote TP issued a REQUEST-TO-SEND verb. If the field contains the letter Y, REQUEST-TO-SEND notification was received from the remote TP, which requests the local TP to enter the Receive state. The local TP can use RECEIVE-AND-WAIT or PREPARE-TO RECEIVE to enter the Receive state when ready.
RECEIVE-IMMEDIATE Verb Verb Definitions WR-CONFIRM (4) The remote TP issued a CONFIRM verb. The local TP enters Confirm state and can respond by issuing either CONFIRMED or SEND-ERROR. No data is received in this reply. WR-CONFIRM-SEND (5) The remote TP issued a PREPARE-TO-RECEIVE verb either with CONFIRM or with SYNC-LEVEL, and the synchronization level is CONFIRM. The local TP enters the Confirm state and can respond by issuing either CONFIRMED or SEND-ERROR. No data is received in this reply.
RECEIVE-IMMEDIATE Verb Verb Definitions RIR-DATA-AREA This field contains the data received. If the RECEIVE-IMMEDIATE request specified FILL-BUFFER (B), this field can include several logical records. If the RECEIVE-IMMEDIATE request specified FILL-LL (L) and the RIR-DATALENGTH field is less than the logical record length, the buffer can include all or part of a logical record.
Verb Definitions • RECEIVE-IMMEDIATE Verb When the remote TP issues a DEALLOCATE FLUSH verb request, the local TP receives notification (RC-DEALLOCATE-NORMAL) in RWR-RETN-CODE. (First the TP receives the flushed data with RC-OK; on the next RECEIVEAND-WAIT verb request, the local TP receives DEALLOCATE-NORMAL.) Thus, a return code other than RC-OK does not necessarily indicate that an error occurred.
REQUEST-TO-SEND Verb Verb Definitions REQUEST-TO-SEND Verb The REQUEST-TO-SEND verb informs the remote TP that the local TP wants to enter Send state. When the local TP is in Receive state and has data to send, it issues REQUEST-TOSEND to the remote TP. The verb completes immediately because it simply notifies the remote TP. However, the transition to Send state does not occur until the remote TP actually enters Receive state (by issuing a RECEIVE-AND-WAIT request or equivalent).
SEND-DATA Verb Verb Definitions SEND-DATA Verb The SEND-DATA verb sends data to the remote TP. The local TP moves data into the SNAX/APC send buffer by using SEND-DATA. Using this verb does not necessarily cause the data to be transmitted immediately. Subsequent SEND-DATA verbs cause the new data to be concatenated with the data already in the send buffer.
SEND-DATA Verb Verb Definitions Request Format ?SECTION SEND-DATA-REQ,TANDEM 01 SEND-DATA-REQ. 02 SD-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 01 SD-DATA-LENGTH 01 SD-DATA-AREA. 02 SD-DATA-TEXT PIC X(2). PIC 9(4) PIC 9(4) COMP. COMP. PIC X OCCURS 0 TO N TIMES DEPENDING ON SD-DATA-LENGTH. Reply Format ?SECTION SEND-DATA-REP,TANDEM 01 SEND-DATA-REP. 02 SDR-HEADER. 03 REP-UOW-ID 03 REP-VERB-CODE 03 REP-RETURN-CODE 03 REP-RETURN-CODE-DETAIL 02 SDR-PARAMETERS.
SEND-DATA Verb Verb Definitions Reply Details RESERVED-1 This field is not used by SNAX/APC and can be ignored by the TP. SDR-REQ-TO-SEND-IND This field indicates whether the remote TP issued a REQUEST-TO-SEND verb. If the field contains the letter Y, REQUEST-TO-SEND notification was received from the remote TP, which requests the local TP to enter Receive state. If the field contains the letter N, the remote TP did not issue a REQUEST-TO-SEND verb.
SEND-ERROR Verb Verb Definitions SEND-ERROR Verb The local TP uses the SEND-ERROR verb when it detects an application data error. SEND-ERROR can be issued in either Send or Receive state. If the local TP is in Receive state, it uses SEND-ERROR to notify the remote TP that the received data cannot be processed. If the local TP is in Send state, it can use SEND-ERROR to notify the remote TP that recently sent data was not usable. SEND-ERROR does not terminate the conversation.
SEND-ERROR Verb Verb Definitions SE-TYPE This specifies the type of error; the SEND-ERROR verb request supports three error types: PROGRAM-TYPE BACKOUT-NO-RESYNC BACKOUT-RESYNC Reply Details SER-REQ-TO-SEND-IND This field indicates whether the remote TP issued a REQUEST-TO-SEND verb. If the field contains the letter Y, a REQUEST-TO-SEND notification was received from the remote TP, which requests the local TP to enter Receive state.
SEND-ERROR Verb Verb Definitions to the cancelled IPC. SNAX/APC frees the internal resources after finishing the processing of the verb.
Mapped Conversation Verbs Verb Definitions Mapped Conversation Verbs The mapped conversation verbs are intended for use by application transaction programs. These verbs provide functions that are suitable for application programs that are written in high-level programming languages. Not all verbs from all the IBM option sets have been implemented. The table below shows a list of the mapped verbs currently supported by SNAX/APC.
MC-ALLOCATE Verb Verb Definitions MC-ALLOCATE Verb This verb allocates a mapped conversation connecting the local transaction program (TP) to a remote TP. A unique resource ID is assigned to the mapped conversation. This verb is issued prior to any verbs that refer to the mapped conversation. SNAX/APC has conversation security through the support of a program-supplied user ID and password when a SNAX/APC transaction program allocates a conversation.
MC-ALLOCATE Verb Verb Definitions The format for the MC-ALLOCATE request is: Request Format (IPC Version Code S1 or S2) 01 MC-ALLOCATE-REQ. 02 MC-AL-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 MC-AL-PARAMETERS. 03 RESERVED-1 03 MC-AL-SYNC-LEVEL 88 MC-AL-SYNC-LEVEL-NONE 88 MC-AL-SYNC-LEVEL-CONFIRM 03 MC-AL-RET-CONTROL 88 MC-WHEN-SESSION-ALLOCATED 88 MC-IMMEDIATE 03 MC-AL-PARTNER-LUNAME 03 MC-AL-MODENAME 03 MC-AL-PARTNER-TPNAME PIC X(2). PIC 9(4) COMP. PIC X(1). PIC X(1). VALUE IS "N". VALUE IS "C".
MC-ALLOCATE Verb Verb Definitions Reply Format 01 MC-ALLOCATE-REP. 02 MC-ALR-HEADER. 03 REP-UOW-ID 03 REP-VERB-CODE 03 REP-RETURN-CODE 03 REP-RETURN-CODE-DETAIL PIC PIC PIC PIC X(2). 9(4) S9(4) S9(4) COMP. COMP. COMP. Request Details MC-AL-HEADER This is a template containing the REQ-UOW-ID and the REQ-VERB-CODE. This is the standard SNAX/APC request header and is defined at the beginning of this section. RESERVED-1 This is a field reserved for future use.
MC-ALLOCATE Verb Verb Definitions MC-AL-PARTNER-TPNAME This field indicates the name of the remote TP to be used in the ATTACH request that is sent to the remote LU. The remote TP name must be known to the remote LU. MC-AL-SECURITY-TYPE This field in an MC-ALLOCATE request format with IPC version code S3 and above indicates the type of conversational security to be used when allocating the conversation with the remote partner. The field must contain one of the uppercase letters N, P, or S.
MC-ALLOCATE Verb Verb Definitions Return Codes The following return code can be returned in HEADER-RETURN-CODE of the IPC HEADER: OUT-OF-RESOURCES The following return codes can be returned in REP-RETURN-CODE of ALR-HEADER: RC-OK RC-UNSUCCESSFUL RC-ALLOCATION-ERROR (with one of the following detail codes) RCD-ALLOC-FAIL-NO-RETRY RCD-ALLOC-FAIL-RETRY RCD-SYNC-LEVL-NOT-SUPPTD RC-PARAMETER-ERROR (with one of the following detail codes) RCD-INVALID-PARTNER-NAME RCD-INVALID-MODENAME RCD-SYNCLVL-NOT-SUPPTD RCD-
MC-ALLOCATE Verb Verb Definitions SNAX/APC finishes processing the verb, SNAX/APC deallocates the conversation and frees the internal resources. • The type of security that an LU supports is indicated in the BIND request and BIND response when an LU-LU session is established. If the remote LU does not accept any security parameters from the local LU and the local ATP specifies ALSECURITY-TYPE-PGM or AL-SECURITY-TYPE-SAME, the local LU downgrades the specification to AL-SECURITY-TYPE-NONE.
MC-CONFIRM Verb Verb Definitions MC-CONFIRM Verb The MC-CONFIRM verb requests confirmation of receipt of data or completion of some function. This verb flushes the buffer of data waiting to be sent (sending the data to the remote TP) and requests an explicit confirmation from the remote TP when it has received the data. MC-CONFIRM completes when SNAX/APC receives a confirmation or error reply from the remote TP. The format for MC-CONFIRM request is: Request Format 01 MC-CONFIRM-REQ. 02 MC-CM-HEADER.
MC-CONFIRM Verb Verb Definitions Return Codes The following return codes can be returned in the REP-RETURN-CODE field of the MC-CMR-HEADER: RC-OK (remote TP replied with MC-CONFIRMED) RC-ALLOCATION-ERROR RC-BACKOUT-RESYNC RC-BACKOUT-NO-RESYNC RC-DEALLOCATE-ABEND-PROG RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY MAPPING-NOT-SUPPORTED MAP-EXECUTION-FAILURE Consideration If an MC-CONFIRM verb is processing when SNAX/APC receives a CANCEL system message from the application progr
MC-CONFIRMED Verb Verb Definitions MC-CONFIRMED Verb A TP uses the MC-CONFIRMED verb request to acknowledge receipt of data or completion of a function. When the local TP receives a CONFIRM indication in the WHAT-RECEIVED field of a MC-RECEIVE-AND-WAIT or MC-RECEIVE-IMMEDIATE reply, it must use MCCONFIRMED to acknowledge that the data has been received or processed correctly. MC-CONFIRMED completes immediately; if the local TP chooses to reject the data, it can issue a MC-SEND-ERROR verb.
MC-DEALLOCATE Verb Verb Definitions MC-DEALLOCATE Verb The local TP uses the MC-DEALLOCATE verb to end a conversation with a remote TP. There are five types of deallocation requests: • • • • • MC-DEALLOCATE (FLUSH) MC-DEALLOCATE (CONFIRM) MC-DEALLOCATE (SYNC-LEVEL) MC-DEALLOCATE (LOCAL) MC-DEALLOCATE (ABEND) MC-DEALLOCATE (FLUSH) completes when the SNAX/APC process’s internal buffer has been flushed and the local resources have been deallocated.
MC-DEALLOCATE Verb Verb Definitions DE-TYPE The type of deallocation used is dependent on the state and synchronization level of the conversation. The following symbols are defined in the SNAX/APC DDL definitions: MC-DE-SYNC-LEVEL (SL) If the synchronization level is CONFIRM, the action is the same as for APC-DEALLOCATE-CONFIRM (CO). If the synchronization level is NONE, the action is the same as for APC-DEALLOCATE-FLUSH (FL).
MC-DEALLOCATE Verb Verb Definitions Return Codes The following return codes can be returned in the REP-RETURN-CODE field of MC-DER-HEADER: RC-OK RC-ALLOCATION-ERROR RC-DEALLOCATE-ABEND RC-IMPROPER-SYNCLEVEL-PARAM RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Considerations • If the local TP receives WR-CONFIRM-DEALLOCATE in the WHAT-RECEIVED field of a MC-RECEIVE-AND-WAIT or MC-RECEIVE-IMMEDIATE reply, it is in the CONFIRM state.
MC-FLUSH Verb Verb Definitions MC-FLUSH Verb The local TP uses the MC-FLUSH verb to force the transmission of the local LU’s send buffer. The local LU transmits the contents of the send buffer to the partner LU. The verb completes when the contents of the buffer have been transmitted. If the send buffer is empty, nothing is transmitted and the verb completes immediately.
MC-GET-ATTRIBUTES Verb Verb Definitions MC-GET-ATTRIBUTES Verb The local TP uses the MC-GET-ATTRIBUTES verb request to query the local SNAX/APC process for information about the conversation. MC-GET-ATTRIBUTES has no impact on the remote TP or remote LU. Local TPs that wait for a remote attach or dispatch can issue MC-GET-ATTRIBUTES immediately on startup to determine the synchronization level for the conversation. MC-GETATTRIBUTES completes immediately.
MC-GET-ATTRIBUTES Verb Verb Definitions Reply Details MC-GAR-SYNC-LEVEL This field contains the synchronization level for the conversation. The three possible values are N for NONE, C for CONFIRM and S for SYNCPT. If the synchronization level is NONE, the confirm verb cannot be issued in the conversation. MC-GAR-LOCAL-LUNAME This field contains the name of the local LU, as described in the SNAX/APC configuration database.
MC-PREPARE-TO-RECEIVE Verb Verb Definitions MC-PREPARE-TO-RECEIVE Verb This verb changes the mapped conversation from Send state to Receive state in preparation to receive data. A SEND indication is sent to the remote program. The remote program’s end of the mapped conversation changes to Send state when the program receives the SEND indication. The format for MC-PREPARE-TO-RECEIVE request is: Request Format 01 MC-PREP-TO-RECEIVE-REQ. 02 MC-PR-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 MC-PR-PARAMETERS.
MC-PREPARE-TO-RECEIVE Verb Verb Definitions state. Otherwise, the return code indicates the new state of the conversation. SNAX/APC rejects a CO request if the synchronization level of the conversation is NONE. FL specifies that SNAX/APC is to transmit the contents of the local LU’s send buffer to the partner TP and then place the conversation in the Receive state. The MC-PREPARE-TO-RECEIVE verb completes as soon as the local LU’s send buffer is transmitted; no confirmation is required.
MC-PREPARE-TO-RECEIVE Verb Verb Definitions Return Codes If MC-PREPARE-TO-RECEIVE is issued with MC-PR-TYPE set to FL or MC-PRTYPE set to SL and the synchronization is NONE, the following return code is returned in REP-RETURN-CODE of MC-PRR-HEADER: RC-OK If MC-PREPARE-TO-RECEIVE is issued with MC-PR-TYPE set to CO or MC-PRTYPE set to SL and the synchronization is CONFIRM, the following return codes can be returned in REP-RETURN-CODE of MC-PRR-HEADER: RC-OK RC-ALLOCATION-ERROR RC-DEALLOCATE-ABEND-PROG RC-I
MC-RECEIVE-AND-WAIT Verb Verb Definitions MC-RECEIVE-AND-WAIT Verb The local TP issues MC-RECEIVE-AND-WAIT when it is ready to receive data or control information from the remote TP. The local TP can issue MC-RECEIVE-ANDWAIT while in Send state to flush the data buffer and cause a transition to Receive state. Successful completion of the MC-RECEIVE-AND-WAIT verb occurs when the local TP receives data or information from the remote TP.
MC-RECEIVE-AND-WAIT Verb Verb Definitions Request Details The MC-RECEIVE-AND-WAIT verb request has two parameters in addition to the standard SNAX/APC request header. RESERVED-2 reserved for future use, and must contain either two zeros or two spaces. MC-RW-MAX-DATA-LENGTH indicates the maximum amount of data the TP is to receive. Reply Details The MC-RECEIVE-AND-WAIT verb reply has four parameters in addition to the standard SNAX/APC reply header. RESERVED-1 is reserved, and should be ignored.
MC-RECEIVE-AND-WAIT Verb Verb Definitions MC-WR-CONFIRM (4) The remote TP issued an MC-CONFIRM verb. The local TP enters the Confirm state and can respond by issuing either CONFIRMED or SEND-ERROR. No data is received in this reply. MC-WR-CONFIRM-SEND (5) The remote TP issued an MC-PREPARE-TO-RECEIVE verb either with CONFIRM or with SYNC-LEVEL, and the sync level is CONFIRM. The local TP enters Confirm state and can respond by issuing either MC-CONFIRMED or MC-SEND-ERROR.
MC-RECEIVE-AND-WAIT Verb Verb Definitions If the MC-RECEIVE-AND-WAIT verb is issued in the Receive state, the following return codes can be returned in REP-RETURN-CODE of RWR-HEADER: RC-OK RC-ALLOCATION-ERROR RC-BACKOUT-NO-RESYNC RC-BACKOUT-RESYNC RC-DEALLOCATE-ABEND-PROG RC-DEALLOCATE-NORMAL RC-PROGRAM-ERROR-NO-TRUNC RC-PROGRAM-ERROR-PURGING RC-PROGRAM-ERROR-TRUNC RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Considerations • REQUEST-TO-SEND notification is usually received in the Send state but ca
MC-RECEIVE-IMMEDIATE Verb Verb Definitions MC-RECEIVE-IMMEDIATE Verb The local TP issues the MC-RECEIVE-IMMEDIATE verb to receive any data or control information that is immediately available from the partner TP. The MC-RECEIVEIMMEDIATE verb does not wait for information to arrive from the partner TP. The information, if available, can be data, conversation status, or a request for confirmation.
MC-RECEIVE-IMMEDIATE Verb Verb Definitions Request Format 01 MC-RECEIVE-IMMEDIATE-REQ. 02 MC-RI-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 MC-RI-PARAMETERS. 03 RESERVED-2 03 MC-RI-MAX-DATA-LENGTH PIC X(2). PIC 9(4) COMP. PIC X(2). PIC 9(4) COMP. Reply Format 01 MC-RECEIVE-IMMEDIATE-REP. 02 MC-RIR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) COMP. 03 REP-RETURN-CODE PIC S9(4) COMP. 03 REP-RETURN-CODE-DETAIL PIC S9(4) COMP. 02 MC-RIR-PARAMETERS. 03 RESERVED-1 PIC X(1).
MC-RECEIVE-IMMEDIATE Verb Verb Definitions MC-RI-MAX-DATA-LENGTH, specifies the maximum amount of data that the local TP can receive in one reply. The value specified here must be such that the size of the reply from SNAX/APC is less than or equal to the size specified in MAXAPPLIOSIZE when SNAX/APC was started. Reply Details The MC-RECEIVE-IMMEDIATE verb reply has four parameters in addition to the standard SNAX/APC reply header.
MC-RECEIVE-IMMEDIATE Verb Verb Definitions The local TP enters the Confirm state and can respond by issuing either MCCONFIRMED or MC-SEND-ERROR. No data is received in this reply. After issuing the CONFIRMED or SEND-ERROR verb, the local TP enters the Send state. MC-WR-CONFIRM-DEALLOCATE (6) The remote TP issued an MC-DEALLOCATE verb with CONFIRM or with SYNC-LEVEL, and the synchronization level is CONFIRM. The local TP can respond by issuing either MC-CONFIRMED or MC-SEND-ERROR.
MC-RECEIVE-IMMEDIATE Verb Verb Definitions Considerations • REQUEST-TO-SEND notification is usually received in the Send state but can be received in Receive state under one of the following conditions: • • • • • The local TP just entered Receive state, and the remote TP issued REQUESTTO-SEND. The remote TP issued PREPARE-TO-RECEIVE and then issued REQUESTTO-SEND before the local program entered Send state.
MC-REQUEST-TO-SEND Verb Verb Definitions MC-REQUEST-TO-SEND Verb The MC-REQUEST-TO-SEND verb informs the remote TP that the local TP wants to enter Send state. When the local TP is in Receive state and has data to send, it issues MC-REQUEST-TOSEND to the remote TP. The verb completes immediately because it simply notifies the remote TP; however, the transition to Send state does not occur until the remote TP actually enters Receive state (by issuing a RECEIVE-AND-WAIT request or equivalent).
MC-SEND-DATA Verb Verb Definitions MC-SEND-DATA Verb The MC-SEND-DATA verb sends data to the remote TP. The local TP moves data into the SNAX/APC send buffer by using MC-SEND-DATA. Using this verb does not necessarily cause the data to be transmitted immediately. Subsequent MC-SEND-DATA verbs cause the new data to be concatenated with the data already in the send buffer.
MC-SEND-DATA Verb Verb Definitions Request Format 01 MC-SEND-DATA-REQ. 02 MC-SD-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) COMP. 02 MC-SD-PARAMETERS. 03 RESERVED-1 PIC X(1). 88 BLANK-1 VALUE IS " ". 03 RESERVED-2 PIC X(1). 88 BLANK-2 VALUE IS " ". 03 MC-SD-PS-HEADER-IND PIC X(1). 88 MC-SD-PS-HEADER-PRESENT VALUE IS "Y". 88 MC-SD-PS-HEADER-NOT-PRESENT VALUE IS "N". 88 BLANK-3 VALUE IS " ". 03 MC-SD-MAP-NAME-IND PIC X(1). 88 MC-SD-MAP-NAME-PRESENT VALUE IS "Y".
MC-SEND-DATA Verb Verb Definitions MC-SD-PS-HEADER-IND must contain either “Y” or “N.” Any other value causes the IPC to be rejected with a return code of INVALID-UOW-HEADER and a detail return code of INVALIDINDICATOR. MC-SD-MAPNAME-IND must contain “N.” Any other value causes the IPC to be rejected with a return code of INVALID-UOW-HEADER and a detail return code of INVALID-INDICATOR. MC-SD-MAP-NAME must be empty.
MC-SEND-DATA Verb Verb Definitions RC-BACKOUT-RESYNC RC-BACKOUT-NO-RESYNC RC-DEALLOCATE-ABEND-PROG RC-PARAMETER-ERROR RC-PROGRAM-ERROR-PURGING RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Considerations • • If an MC-SEND-DATA verb is processing when SNAX/APC receives a CANCEL system message from the application program, SNAX/APC deactivates the session and replies to the cancelled IPC. SNAX/APC frees the internal resources after finishing the processing of the verb.
MC-SEND-ERROR Verb Verb Definitions MC-SEND-ERROR Verb The local TP uses the MC-SEND-ERROR verb when it detects an application data error. MC-SEND-ERROR can be issued in either Send or Receive state. If the local TP is in Receive state, it uses MC-SEND-ERROR to notify the remote TP that the received data cannot be processed; if the local TP is in Send state, it can use MC-SEND-ERROR to notify the remote TP that recently sent data was not usable. MC-SEND-ERROR does not terminate the conversation.
MC-SEND-ERROR Verb Verb Definitions Request Details The MC-SEND-DATA verb request has one parameter in addition to the standard SNAX/APC request header. SE-TYPE This specifies the type of error; the SEND-ERROR verb request supports three error types: PROGRAM-TYPE BACKOUT-NO-RESYNC BACKOUT-RESYNC Reply Details The MC-SEND-ERROR verb reply has two parameters in addition to the standard SNAX/APC reply header. These are as follows: RESERVED-1 is reserved, and is not used by SNAX/APC.
Type-Independent Verbs Verb Definitions If the MC-SEND-ERROR verb is issued in the Confirm state, the following return codes can be returned in REP-RETURN-CODE of SER-HEADER: RC-OK RC-RESOURCE-FAIL-NO-RETRY RC-RESOURCE-FAIL-RETRY Consideration If an MC-SEND-ERROR verb is processing when SNAX/APC receives a CANCEL system message from the application program, SNAX/APC deactivates the session and replies to the cancelled IPC. SNAX/APC frees the internal resources after finishing the processing of the verb.
GET-TYPE Verb Verb Definitions Request Details The GET-TYPE verb request has no parameters other than the standard SNAX/APC request header. Reply Details The GET-TYPE verb reply has two parameters in addition to the standard SNAX/APC reply header. These are as follows: RESERVED-1 This field is reserved, and is not used by SNAX/APC. It may be ignored by the TP. GTR-TYPE The types are “B” for basic conversations, and “M” for mapped conversations.
Verbs Specific to Tandem Products Verb Definitions Verbs Specific to Tandem Products The following verbs have been created exclusively for the use of SNAX/APC. There is no functional equivalent in the IBM option sets. DISPATCH-TP Verb The SNAX/APC Dispatcher sends a DISPATCH-TP request to the newly created TP to inform it of a request for a conversation from a remote TP. A TP server receives the DISPATCH-TP request from the SNAX/APC Dispatcher through $RECEIVE.
DISPATCH-TP Verb Verb Definitions SNAX/APC. A COBOL TP must use the dynamic assign facility before opening this SNAX/APC process. DT-DISPATCHING-LUNAME contains the name of the local SNAX/APC LU name that received the attach. The TP server uses this LU name in the TP-READY request. DT-TPNAME contains the name of this TP server. This parameter is used in the TP-READY request. Considerations • The DISPATCH-TP request is preceded by an IPC header.
DISPATCHER-READY Verb Verb Definitions DISPATCHER-READY Verb The SNAX/APC Dispatcher sends a DISPATCHER-READY request to the SNAX/APC process when the Dispatcher is first initialized; the DISPATCHER-READY request is queued. The SNAX/APC process sends a DISPATCHER-READY reply to the Dispatcher when the following is true: • • • The SNAX/APC process receives an ATTACH request from a remote TP. A DISPATCHER-READY request is already waiting on the DISPATCHER-READY queue.
DISPATCHER-READY Verb Verb Definitions Request Details REQ-UOW-CODE must contain the value 3003, which identifies the DISPATCHER-READY verb. Reply Details DRR-DISPATCHING-PROCESS is the process name of the SNAX/APC process handling the incoming ATTACH request from the remote TP. DRR-DISPATCHING-LUNAME is the name of the local LU handling the incoming ATTACH request. DRR-DISPATCHED-TPNAME is the name of the local TP requested by the remote TP.
DISPLAY-STATUS Verb Verb Definitions DISPLAY-STATUS Verb A local TP uses the DISPLAY-STATUS verb to request status of one or all of the local LUs controlled by a SNAX/APC process. The reply from DISPLAY-STATUS contains the state of the sessions or conversations. If the session is active, DISPLAY-STATUS returns the partner LUNAME. If there is an active conversation, DISPLAY-STATUS returns the local TP name, the count of verbs issued over the session, and the outstanding verb (if any).
DISPLAY-STATUS Verb Verb Definitions OCCURS 0 TO N TIMES DEPENDING ON DSR-NUM-RECORDS. 03 DSR-APC-LUNAME 03 DSR-SNAX-FILENAME 03 DSR-PARTNER-LUNAME 03 DSR-LOCAL-TP-NAME 03 DSR-TP-PROCESS-NAME 03 DSR-SESSION-POLARITY 03 DSR-FSM-STATES.
DISPLAY-STATUS Verb Verb Definitions DSR-NUM-RECORDS contains the number of status records present in the verb reply. If the request indicated a specific LU, this value is 1. If the request specified all LUs, this value can range from 0 to . DSR-APC-LUNAME contains the name of the local SNAX/APC LU to which this status record pertains.
DISPLAY-STATUS Verb Verb Definitions FSM-BIS This field indicates the Bracket Initiation Stopped (BIS) protocol. Use the DSRSESSION-POLARITY field to determine which BIS FSM is in use. The values are: 01 02 03 04 Reset BIS Sent BIS Received Closed FSM-BSM indicates the bracket states. The possible values are: 01 02 Between Brackets In Brackets FSM-CHAIN-RCV indicates the received chain states.
DISPLAY-STATUS Verb Verb Definitions FSM-ERROR-OR-FAILURE indicates errors or failures reported by other layers. The possible values are: 01 02 03 04 05 06 07 No Requests (initial state) Received Error Conversation Failure Protocol Error Conversation Failure Session Outage Notification Allocate Failure Retry Allocate Failure No Retry Synchronization Level Not Supported FSM-PAC-RQ-RCV indicates whether the LU can send a pacing response for receive pacing.
DISPLAY-STATUS Verb Verb Definitions FSM-RCV-PURGE indicates whether the LU maintains a purging state for received begin bracket (BB) chains. The possible values are: 01 02 reset Purge FSM-SCB-STATUS indicates the half-session status. The SESSION-POLARITY field determines which FSM-SCB-STATUS is in use. The possible values are: 01 02 03 04 05 Session Activation Free Pending Attach In Use Pending FMH-12 FSM-STATUS indicates the LU-LU session status.
DISPLAY-STATUS Verb Verb Definitions OUTSTANDING-VERB contains the verb request code if a conversation is active and SNAX/APC is processing a verb. If there is no active conversation or current verb, the field contains a zero. VERB-COUNT indicates the number of LU 6.2 conversation verbs issued over this LU since the session was activated. The count of verbs excludes all operator verbs and service UOWs. When the verb count exceeds 65,535, SNAX/APC resets the value to zero.
GET-TP-PROPERTIES Verb Verb Definitions GET-TP-PROPERTIES Verb The GET-TP-PROPERTIES verb returns information pertaining to the TP issuing the verb. Request Format ?SECTION GET-TP-PROPERTIES-REQ,TANDEM 01 GET-TP-PROPERTIES-REQ. 02 GTP-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) COMP. Reply Format ?SECTION GET-TP-PROPERTIES-REP,TANDEM 01 GET-TP-PROPERTIES-REP. 02 GTP-HEADER. 03 REP-UOW-ID PIC 03 REP-VERB-CODE PIC 03 REP-RETURN-CODE PIC 03 REP-RETURN-CODE-DETAIL PIC 02 GTP-PARAMETER.
GET-TP-PROPERTIES Verb Verb Definitions GTP-TP-INSTANCE contains the identifier of the instance of the local TP that issued the verb. GTP-LUNAME contains, if known, the network-qualified name of the LU servicing the TP that issued the verb. If the LUNAME is unknown, this field contains blanks. GTP-UNPROT-LUWID if the session allocation sync level was NONE or CONFIRM, this field contains the unprotected LUWID for the current logical unit of work.
GET-TP-PROPERTIES Verb Verb Definitions INST-NUM For sync support only, this component of the protected LUWID contains the transaction instance number that is unique to the LU that created it. SEQ-NUM For sync support only, this component of the protected LUWID contains a sequence number that starts at 1 and is incremented by 1 following each commit or backout operation.
TP-END Verb Verb Definitions TP-END Verb The TP-END verb releases all resources allocated under one TP-READY, essentially canceling the TP-READY. When a TP successfully issues a TP-READY request, it associates the TP with a SNAX/APC LU. A TP-END verb request breaks this association. When a local TP issues a TP-READY request, SNAX/APC allocates a transaction control block (TCB) to that TP. The TCB associates the TP with the SNAX/APC LU. The TP-END verb request deallocates the TCB.
TP-END Verb Verb Definitions • • A TP can concatenate TP-END with other UOWs in an IPC message. However, TPEND must be the last UOW in the IPC message. (The only UOW that a TP can request after a TP-END is TP-READY; TP-READY must be sent in its own IPC message.) If a TP-END verb is processing when SNAX/APC receives a CANCEL system message from the application program, the TP-END verb is allowed to finish normally.
TP-READY Verb Verb Definitions TP-READY Verb A local TP uses the TP-READY request to initiate communication with the SNAX/APC process. The TP-READY request must be the only UOW in the IPC message; it cannot be concatenated with other UOWs. When a local TP issues a TP-READY request, it should set the RESOURCE-ID field in the IPC request header to all 0s (in COBOL, use LOW-VALUES). The RESOURCE-ID field in the IPC reply header contains the new resource ID.
TP-READY Verb Verb Definitions Sync Point Support in the TP-READY Verb With the addition of sync point support, SNAX/APC has added three new attributes and a new IPC header version code to the TP-READY verb. The new attributes are: • • • SYNCSUPPORT - this TP-READY request attribute specifies whether the Transaction Program requires sync point support for its transactions.
TP-READY Verb Verb Definitions Request Format (IPC Version Code S5) ?SECTION TP-READY-REQ,TANDEM 01 TP-READY-REQ. 02 TR-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE 02 TR-PARAMETERS. 03 TR-LOCAL-ATTACH-INDICATOR 03 TR-DISPATCHED-INDICATOR 03 TR-APC-LUNAME 03 TR-LOCAL-TPNAME 02 TR-SYNC-SUPPORT-INDICATOR PIC X(2). PIC 9(4) PIC PIC PIC PIC PIC X(1). X(1). X(8). X(16). X(1). PIC PIC PIC PIC X(2). 9(4) S9(4) S9(4) COMP. Reply Format (IPC Version Code S5) ?SECTION TP-READY-REP,TANDEM 01 TP-READY-REP.
TP-READY Verb Verb Definitions TR-APC-LUNAME is the name of the local LU. If the TP was dispatched, the LU name is contained in the DISPATCH-TP request. If a TP is not dispatched, the TP programmer can write the TP such that it reads an LU name as a process-startup PARAM message. The LU name can be up to eight characters long; the LU name must be in uppercase letters and must be in the configuration database.
TP-READY Verb Verb Definitions INST-NUM For sync support only, this component of the LUWID contains the a transaction instance number that is unique to the LU that created it. SEQ-NUM For sync support only, this component of the LUWID contains a sequence number that starts at 1 and is incremented by 1 following each commit or backout operation.
4 Application Prototype Simulator This section describes the SNAX/APC Application Prototype Simulator (APS) and provides the following information: • • • • An overview of APS and how to use it Information on how to set up and run APS Descriptions of the SNAX/APC verbs that APS supports Descriptions of the utility functions available in APS APS Overview APS is a program that enables you to submit verbs to SNAX/APC interactively, and thus carry on a conversation with a partner TP.
APS User Interface Application Prototype Simulator APS User Interface APS presents SNAX/APC verbs to you by using full-screen forms, one form for each verb. The following example shows the general layout of an APS form.
APS User Interface Application Prototype Simulator APS Function Key Definitions Table 4-1 and Table 4-2 describe the unshifted and shifted function keys used by APS for basic and mapped verbs. Table 4-1. Unshifted APS Function Keys Key Label Function F1 TPR Selects the TP-READY verb. F2 Aloc or MAI Selects the ALLOCATE or MC-ALLOCATE verb. F3 Deal or MDal Selects the DEALLOCATE or MC-DEALLOCATE verb. F4 TPE Selects the TP-END verb.
Using APS Application Prototype Simulator Table 4-2. Shifted APS Function Keys Key Label Function SF1 ActS Selects the ACTIVATE-SESSION verb. SF2 Dact Selects the DEACTIVATE-SESSION verb. SF3 Not used. SF4 PRcv or MPrc Selects the PREPARE-TO-RECEIVE or MC-PREPARE-TO-RECEIVE verb. SF5 Rcvl or MRcl Selects the RECEIVE-IMMEDIATE or MC-RECEIVE-IMMEDIATE verb. SF6 Flsh or MFls Selects the FLUSH or MC-FLUSH verb.
Setting Up and Running APS Application Prototype Simulator 4. After SNAX/APC has completed the execution of the verb request, APS displays the verb reply in the reply fields. Examine the reply fields to determine whether or not the verb executed successfully. Repeat these steps for each verb that you want to execute. Setting Up and Running APS APS is a SCREEN COBOL program and must run in a PATHMON environment under the control of a terminal control process (TCP).
Application Prototype Simulator APS and the SNAX/APC Configuration Database APS and the SNAX/APC Configuration Database The SNAX/APC server process should be configured in the usual way before using APS. Refer to the SNAX/APC Planning and Configuration Manual. When configuring SNAX/APC, note that APS is not defined as a TP: APS can simulate any TP you want. The TP that APS is simulating is identified to SNAX/APC when APS sends a TP-READY verb to SNAX/APC for execution.
Verb Descriptions Application Prototype Simulator Verb Descriptions This subsection describes the form, or screen, that APS presents for each SNAX/APC verb. The verbs are divided into five types (Control, Tandem, Basic, Type-Independent, and Mapped). Within each type, the verbs are presented in alphabetical order. Within the description of each screen, the descriptions of the individual fields are presented in the order that the fields appear on the screen, from left to right and from top to bottom.
Control Verbs Application Prototype Simulator Control Verbs Control (or Control-operator) verbs are intended for use by control-operator TPs, which are programs that assist the control operator to control an LU. ACTIVATE-SESSION (SF1) The ACTIVATE-SESSION verb activates a session explicitly. This verb does not start a conversation: it initiates an LU-LU session by sending or requesting a Bind Even for parallel-session LUs, each occurrence of the ACTIVATE-SESSION verb activates only one session.
Application Prototype Simulator ACTIVATE-SESSION (SF1) Mode Name specifies the name of the mode that the partner LU will use to access a BIND image. If you leave this field blank, the default mode entry will be used. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS).
DEACTIVATE-SESSION (SF2) Application Prototype Simulator DEACTIVATE-SESSION (SF2) The DEACTIVATE-SESSION verb deactivates an LU-LU session. DEACTIVATE-SESSION completes immediately; it does not wait for the deactivation to complete. As noted earlier, the form of the verb used is that applicable to an IPC with a version code of S2 or S3. To use the DEACTIVATE-SESSION verb, the TP that APS represents must have session control authorization.
Application Prototype Simulator DEACTIVATE-SESSION (SF2) CL specifies that the session is to be deactivated immediately, regardless of conversation status. You can use CL (cleanup) to deactivate a conversation that has stopped in an error state and cannot be deallocated. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply.
Basic Conversation Verbs Application Prototype Simulator Basic Conversation Verbs The basic conversation verbs are intended for use by LU services programs. LU services programs can provide end-user services or protocol boundaries for end-user application transaction programs. For example, the mapped conversation LU services component issues basic conversation verbs during its processing of mapped conversation verbs. ALLOCATE (F2) The ALLOCATE verb establishes a conversation with a partner TP.
Application Prototype Simulator ALLOCATE (F2) Request Fields Partner LU Name specifies the name of the partner LU that supports the partner TP. The partner LU name must be configured as a partner to the local LU specified in the last TP-READY verb. Partner TP Name specifies the name of the partner TP with which you want to establish a conversation. SNAX/APC uses the partner TP name in the ATTACH request that it sends to the partner LU.
Application Prototype Simulator ALLOCATE (F2) User ID specifies user identification sent with this allocation request. Password specifies the password sent with this allocation request. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS).
CONFIRM (F9) Application Prototype Simulator CONFIRM (F9) The CONFIRM verb requests confirmation of receipt of data or completion of a function. This verb sends any data and requests in the SNAX/APC buffer to the partner TP and requests an explicit confirmation from the partner TP that it has received the data. When you issue CONFIRM, the partner TP receives CONFIRM in the WHATRECEIVED field of a RECEIVE-AND-WAIT reply.
Application Prototype Simulator CONFIRM (F9) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. Request to Send Ind indicates whether or not the partner TP issued a REQUEST-TO-SEND verb. If the field contains Y, the partner TP issued a REQUEST-TO-SEND verb, which requests APS to enter the Receive state. If the field contains N, the partner TP did not issue a REQUEST-TO-SEND verb.
CONFIRMED (F10) Application Prototype Simulator CONFIRMED (F10) The CONFIRMED verb acknowledges receipt of data or the completion of a function. When you receive a CONFIRM indication in the WHAT-RECEIVED field of a RECEIVE-AND-WAIT reply, you should use CONFIRMED to acknowledge that data has been received or processed correctly. If you need to indicate an error in the data to the partner TP, issue a SEND-ERROR verb. CONFIRMED completes immediately.
Application Prototype Simulator CONFIRMED (F10) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
DEALLOCATE (F3) Application Prototype Simulator DEALLOCATE (F3) The DEALLOCATE verb ends a conversation with a partner TP. The DEALLOCATE verb supports the following types of deallocation requests: DEALLOCATE (SYNC-LEVEL) or (SL) DEALLOCATE (CONFIRM) or (CO) DEALLOCATE (FLUSH) or (FL) DEALLOCATE (ABEND-PROG) or (AP) DEALLOCATE (CONFIRM) or (AP) DEALLOCATE (LOCAL) or (LO) The type of deallocation that should be used depends on the state and synchronization level of the conversation.
Application Prototype Simulator DEALLOCATE (F3) AP specifies a DEALLOCATE ABEND-PROG request. The contents of the SNAX/APC buffer are sent to the partner TP and the conversation is terminated abnormally. APS can use this type of deallocation request when it is in either the Send or Receive state. Using it in the Send state could cause record truncation, but using it in the Receive state could cause loss of data. CO specifies a DEALLOCATE (CONFIRM) request. Confirmation is requested from the partner TP.
Application Prototype Simulator DEALLOCATE (F3) Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC.
FLUSH (SF6) Application Prototype Simulator FLUSH (SF6) The FLUSH verb transmits the contents of the local LU’s send buffer to the partner TP. The verb completes when the buffer has been transmitted. If no information is in the buffer, nothing is transmitted to the partner TP and the verb completes immediately.
GET-ATTRIBUTES (F11) Application Prototype Simulator GET-ATTRIBUTES (F11) The GET-ATTRIBUTES verb queries the SNAX/APC process for information about the specified conversation. This verb does not send anything to the partner LU; the returned information is retrieved locally. The GET-ATTRIBUTES verb completes immediately. The local TP (APS) must be in a conversation before it can issue the GETATTRIBUTES verb.
Application Prototype Simulator GET-ATTRIBUTES (F11) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. APC LU Name displays the name of the local LU. Partner LU Name displays the name of the partner LU in session with the local LU. Partner Uninterpreted Name displays the SNANAME name of the partner LU in session with the local LU.
PREPARE-TO-RECEIVE (SF4) Application Prototype Simulator PREPARE-TO-RECEIVE (SF4) The PREPARE-TO-RECEIVE verb changes the conversation from the Send state to the Receive state in preparation to receive data. The local TP (APS) must be in the Send state to issue this verb request.
Application Prototype Simulator PREPARE-TO-RECEIVE (SF4) conversation. This is functionally equivalent to a PREPARE-TO-RECEIVE request with request type set to CO (Confirm). FL specifies that SNAX/APC is to transmit the contents of the local LU’s send buffer to the partner TP and then place the conversation in the Receive state. The PREPARE-TO-RECEIVE verb completes as soon as the local LU’s send buffer is transmitted; no confirmation is required.
Application Prototype Simulator PREPARE-TO-RECEIVE (SF4) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
RECEIVE-AND-WAIT (F5) Application Prototype Simulator RECEIVE-AND-WAIT (F5) The RECEIVE-AND-WAIT verb receives data or control information from the partner TP. If a TP issues the RECEIVE-AND-WAIT verb while in the Send state, SNAX/APC transmits any data in the local LU’s send buffer and then places the conversation in the Receive state. The RECEIVE-AND-WAIT verb completes when the local TP receives data or control information from the partner TP.
Application Prototype Simulator RECEIVE-AND-WAIT (F5) record, you must issue one or more RECEIVE-AND-WAIT or RECEIVEIMMEDIATE verbs. Data Length (Max 480) specifies the maximum amount of data that the local TP (APS) can receive in one reply. This length includes the four bytes needed for a GDS variable header (the length and ID fields). The maximum length you can specify is 480 bytes. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply.
Application Prototype Simulator RECEIVE-AND-WAIT (F5) User Data displays the received data, including the GDS header. Nonprintable characters are displayed as tildes (~).
RECEIVE-IMMEDIATE (SF5) Application Prototype Simulator RECEIVE-IMMEDIATE (SF5) The RECEIVE-IMMEDIATE verb receives any data or control information that is immediately available from the partner TP. The information, if available, can be data, conversation status, or a request for confirmation. The RECEIVE-IMMEDIATE verb does not wait for information to arrive from the partner TP. The verb completes immediately with an indication of whether any information was received and, if any, the type of information.
Application Prototype Simulator RECEIVE-IMMEDIATE (SF5) Data Length specifies the maximum amount of data that the local TP (APS) can receive in one reply. This length includes the four bytes needed for a GDS variable header (the length and ID fields). The maximum length you can specify is 480 bytes. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply.
REQUEST-TO-SEND (F6) Application Prototype Simulator REQUEST-TO-SEND (F6) The REQUEST-TO-SEND verb informs the partner TP that the local TP (APS) requests to enter the Send state. The local TP does not enter the Send state until the partner TP changes its own state to the Receive state by issuing a RECEIVE-AND-WAIT verb (or any other verb that causes the partner TP to enter the Receive state).
Application Prototype Simulator REQUEST-TO-SEND (F6) UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
REQUEST-TO-SEND (F6) Application Prototype Simulator SEND-DATA (F7) SEND-DATA sends data to the partner TP by moving data into the SNAX/APC send buffer. The data is not necessarily transmitted immediately. Subsequent SEND-DATA verbs concatenate new data with the data already in the send buffer.
Application Prototype Simulator REQUEST-TO-SEND (F6) is mapped or not). SNAX/APC requires this two-byte length field. Note that the length must be entered in hexadecimal. The data does not have to end on a logical record boundary unless it is the last or only data to be sent. The data must be in a format recognizable to the partner TP. For example, if a CICS application is to receive the data, the data must be in EBCDIC. Use the hexadecimal editor to enter EBCDIC data (in hexadecimal).
SEND-ERROR (F8) Application Prototype Simulator SEND-ERROR (F8) The SEND-ERROR verb notifies the partner TP that the local TP has detected an error. The local TP can issue the SEND-ERROR verb in either the Send or Receive state. If the local TP is in the Receive state, the SEND-ERROR verb notifies the partner TP that the received data cannot be processed. If the local TP is in the Send state, the SENDERROR verb notifies the partner TP that recently sent data contains an error.
Application Prototype Simulator SEND-ERROR (F8) Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC.
Mapped Conversation Verbs Application Prototype Simulator Mapped Conversation Verbs The mapped conversation verbs are intended for use by application transaction programs. These verbs provide functions that are suitable for application programs that are written in high-level programming languages. Not all verbs from all the IBM option sets have been implemented. MC-ALLOCATE (F2) The MC-ALLOCATE verb establishes a conversation with a partner TP.
Application Prototype Simulator MC-ALLOCATE (F2) Request Fields Partner LU Name specifies the name of the partner LU that supports the partner TP. The partner LU name must be configured as a partner to the local LU specified in the last TP-READY verb. Partner TP Name specifies the name of the partner TP with which you want to establish a conversation. SNAX/APC uses the partner TP name in the ATTACH request that it sends to the partner LU.
Application Prototype Simulator MC-ALLOCATE (F2) User ID specifies user identification sent with this allocation request. Password specifies the password sent with this allocation request. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS).
MC-CONFIRM (F9) Application Prototype Simulator MC-CONFIRM (F9) MC-CONFIRM requests confirmation of receipt of data or completion of a function. This verb sends any data and requests in the SNAX/APC buffer to the partner TP and requests an explicit confirmation from the partner TP that it has received the data. When you issue MC-CONFIRM, the partner TP receives CONFIRM in the WHATRECEIVED field of an MC-RECEIVE-AND-WAIT reply.
Application Prototype Simulator MC-CONFIRM (F9) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. Request to Send Ind indicates whether or not the partner TP issued an MC-REQUEST-TO-SEND verb. If the field contains Y, the partner TP issued an MC-REQUEST-TO-SEND verb, which requests APS to enter the Receive state.
MC-CONFIRMED (F10) Application Prototype Simulator MC-CONFIRMED (F10) The MC-CONFIRMED verb acknowledges receipt of data or the completion of a function. When you receive a CONFIRM indication in the WHAT-RECEIVED field of an MC-RECEIVE-AND-WAIT reply, you should use MC-CONFIRMED to acknowledge that data has been received or processed correctly. If you need to indicate an error in the data to the partner TP, issue an MC-SEND-ERROR verb. MCCONFIRMED completes immediately.
Application Prototype Simulator MC-CONFIRMED (F10) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
MC-DEALLOCATE (F3) Application Prototype Simulator MC-DEALLOCATE (F3) The MC-DEALLOCATE verb ends a conversation with a partner TP. It supports the following types of deallocation requests: MC-DEALLOCATE (SYNC-LEVEL ) or (SL) MC-DEALLOCATE (CONFIRM) or (CO) MC-DEALLOCATE (FLUSH) or (FL) MC-DEALLOCATE (ABEND) or (AP) MC-DEALLOCATE (LOCAL) or (LO) The type of deallocation that should be used depends on the state and synchronization level of the conversation.
Application Prototype Simulator MC-DEALLOCATE (F3) AP specifies an MC-DEALLOCATE (ABEND) request. The contents of the SNAX/APC buffer are sent to the partner TP, and the conversation is terminated abnormally. APS can use this type of deallocation request when it is in either the Send or Receive state. Using it in the Send state could cause record truncation. Using it in the Receive state could cause loss of data. CO specifies an MC-DEALLOCATE (CONFIRM) request.
Application Prototype Simulator MC-DEALLOCATE (F3) APS must be in Send state to issue an MC-DEALLOCATE (SYNC-LEVEL) verb request. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1.
MC-FLUSH (F10) Application Prototype Simulator MC-FLUSH (F10) The MC-FLUSH verb transmits the contents of the local LU’s Send buffer to the partner TP. The verb completes when the buffer has been transmitted. If no information is in the buffer, nothing is transmitted to the partner TP, and the verb completes immediately.
Application Prototype Simulator MC-FLUSH (F10) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
MC-GET-ATTRIBUTES (F11) Application Prototype Simulator MC-GET-ATTRIBUTES (F11) The MC-GET-ATTRIBUTES verb queries the SNAX/APC process for information about the current, specified conversation This verb does not send anything to the partner LU; the returned information is retrieved locally. The MC-GET-ATTRIBUTES verb completes immediately. The local TP (APS) must be in a conversation before it can issue the MC-GETATTRIBUTES verb.
Application Prototype Simulator MC-GET-ATTRIBUTES (F11) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. APC LU Name displays the name of the local LU. Sync Level displays the synchronization level of the current conversation.
MC-PREPARE-TO-RECEIVE (SF4) Application Prototype Simulator MC-PREPARE-TO-RECEIVE (SF4) The MC-PREPARE-TO-RECEIVE verb changes the conversation from the Send state to the Receive state in preparation to receive data. The local TP (APS) must be in the Send state to issue this verb request.
Application Prototype Simulator MC-PREPARE-TO-RECEIVE (SF4) the partner TP responds to the request for confirmation. If the partner TP responds to the request for confirmation affirmatively, the conversation is placed in the Receive state; otherwise, the return code indicates the new state of the conversation. This is functionally equivalent to a MC-PREPARE-TO-RECEIVE request with Type set to CO (confirm).
Application Prototype Simulator MC-PREPARE-TO-RECEIVE (SF4) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
MC-RECEIVE-AND-WAIT (F5) Application Prototype Simulator MC-RECEIVE-AND-WAIT (F5) The MC-RECEIVE-AND-WAIT verb receives data or control information from the partner TP. If a TP issues the MC-RECEIVE-AND-WAIT verb while in the Send state, SNAX/APC transmits any data in the local LU’s send buffer and then places the conversation in the Receive state. The MC-RECEIVE-AND-WAIT verb completes when the local TP receives data or control information from the partner TP.
Application Prototype Simulator MC-RECEIVE-AND-WAIT (F5) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. Request to Send Ind indicates whether the partner TP issued an MC-REQUEST-TO-SEND verb. The value Y indicates that REQUEST-TO-SEND notification was received from the partner TP, which requests the local TP (APS) to enter the Receive state.
MC-RECEIVE-IMMEDIATE (SF5) Application Prototype Simulator MC-RECEIVE-IMMEDIATE (SF5) The MC-RECEIVE-IMMEDIATE verb receives any data or control information that is immediately available from the partner TP. The MC-RECEIVE-IMMEDIATE verb does not wait for information to arrive from the partner TP. The information, if available, can be data, conversation status, or a request for confirmation.
Application Prototype Simulator MC-RECEIVE-IMMEDIATE (SF5) UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. Request to Send Ind indicates whether the partner TP issued a MC-REQUEST-TO-SEND verb. The value Y indicates that REQUEST-TO-SEND notification was received from the partner TP, which requests the local TP (APS) to enter the Receive state.
MC-REQUEST-TO-SEND (F6) Application Prototype Simulator MC-REQUEST-TO-SEND (F6) The MC-REQUEST-TO-SEND verb informs the partner TP that the local TP (APS) wants to enter the Send state. The local TP does not enter the Send state until the partner TP changes its own state to the Receive state by issuing a MC-RECEIVE-ANDWAIT verb (or any other verb that causes the partner TP to enter the Receive state).
Application Prototype Simulator MC-REQUEST-TO-SEND (F6) IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
MC-SEND-DATA (F7) Application Prototype Simulator MC-SEND-DATA (F7) MC-SEND-DATA sends data to the partner TP by moving data into the SNAX/APC send buffer. The data is not necessarily transmitted immediately. Subsequent MCSEND-DATA verbs concatenate new data with the data already in the send buffer.
Application Prototype Simulator MC-SEND-DATA (F7) Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC.
MC-SEND-ERROR (F8) Application Prototype Simulator MC-SEND-ERROR (F8) The MC-SEND-ERROR verb notifies the partner TP that the local TP has detected an error. The local TP can issue the MC-SEND-ERROR verb in either the send or Receive state. If the local TP is in the Receive state, the MC-SEND-ERROR verb notifies the partner TP that the received data cannot be processed. If the local TP is in the Send state, the MC-SEND-ERROR verb notifies the partner TP that recently sent data contains an error.
Application Prototype Simulator MC-SEND-ERROR (F8) The value 3 specifies the type of error is BACKOUT-RESYNC. Resynchronization is possible after the Backout operation. Reply Fields IPC Return Code displays the value of HEADER-RETURN-CODE returned in the IPC header reply. IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1.
Application Prototype Simulator Type-Independent Verbs Type-Independent Verbs The type-independent verbs are intended for use with both mapped and basic conversations. These verbs provide functions that span both conversation types. SNAX/APC supports two type-independent verbs: GET-TYPE and GET-TPPROPERTIES.
GET-TYPE (SF7) Application Prototype Simulator GET-TYPE (SF7) This verb returns the type of resource to which the specific resource ID is assigned.
Application Prototype Simulator GET-TYPE (SF7) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. Resource Type displays either Basic or Mapped.
GET-TP-PROPERTIES (SF8) Application Prototype Simulator GET-TP-PROPERTIES (SF8) This verb returns the type of resource to which the specific resource ID is assigned.
Application Prototype Simulator GET-TP-PROPERTIES (SF8) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. TP Name displays the name of the local TP that issued the verb. TP-Instance displays the identifier of the instance of the local TP that issued the verb. Lu Name displays the network-qualified name of the LU servicing the TP that issued the verb. (Un)Protected LUWID Received displays the type (protected or unprotected) of LUWID that was received.
Verbs Specific to Tandem Products Application Prototype Simulator Verbs Specific to Tandem Products The following verbs have been created exclusively for the use of SNAX/APC. There is no functional equivalent in the IBM option sets. Note that the DISPLAY-STATUS verb is not supported in the APS because it cannot be used with IPC version code S3, which APS uses exclusively. TP-END (F4) The TP-END verb releases all resources allocated to the local TP by a previous TP-READY verb.
Application Prototype Simulator TP-END (F4) IPC Return Code Detail displays the value of HEADER-RETURN-CODE-DETAIL returned in the IPC header reply. UOWs In displays the number of UOWs in this IPC message (always 1 for APS). UOWs Out for APS, this value is always 1. UOWs Out indicates the number of reply UOWs contained in the reply from SNAX/APC. Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW.
TP-READY (F1) Application Prototype Simulator TP-READY (F1) The TP-READY verb identifies the local TP to SNAX/APC, associates the local TP with a SNAX/APC LU, and allocates the local resources required for a conversation.
Application Prototype Simulator TP-READY (F1) APC LU Name specifies the name of the local LU that you want to use. This local LU must be configured for use by the SNAX/APC process. If you specify N in the Local Attach field, you can enter an asterisk (*) instead of the name of a specific local LU. In this case, SNAX/APC queues the TP-READY request and waits for an incoming attach for the local TP on any local LU. The TP-READY request completes when a remote TP requests a conversation with the local TP.
Application Prototype Simulator TP-READY (F1) Header Return Code displays the value of REP-RETURN-CODE returned in the reply UOW. LUWID displays the contents of the LUWID. If the session allocation sync level was NONE or CONFIRM, this field displays an unprotected LUWID. If the session allocation sync level was SYNCPT, this field displays a protected LUWID. The fields of the LUWID are: • • • • the first two characters are the length of the Lu Name field which follows.
Utility Functions Application Prototype Simulator Utility Functions This subsection describes the utility functions provided by APS. These functions are not themselves verbs, but aid you in using APS.
Translate to ASCII (SF14) Application Prototype Simulator Table 4-3. Hexadecimal Editor Function Keys (page 2 of 2) Key Label Function F14 Rtn Returns to the verb screen from which you invoked the hexadecimal editor. F15 Rcov Displays the current screen again. F16 Rtn Returns to the verb screen from which you invoked the hexadecimal editor. The following example shows the appearance of the SEND-DATA verb screen when using the hexadecimal editor.
Application Prototype Simulator Print Screen (F13) needs to send EBCDIC data to its partner TP. To send the EBCDIC data, enter the data normally, which places ASCII data in the User Data field, and then press SF15 to translate the data from ASCII to EBCDIC. For basic verbs, note that this function does not translate the first two bytes of the User Data field because the first two bytes are normally the logical record length (LL) field.
A COBOL Definitions for SNAX/APC This appendix lists the COBOL definitions that are created from the DDL source file, APCDDL, that is shipped with SNAX/APC. Seven of the request UOWs contain fields that cannot be defined easily with DDL (they rely on the DEPENDING clause). You must define these fields yourself. The DDL COPYLIB includes examples on how these fields must be defined in COBOL and TAL.
COBOL Definitions for SNAX/APC COBOL Definitions ?Section ELEMENTARY-ITEMS,Tandem 01 DATA-LENGTH PIC 9(4) COMP. 01 DEACTIVATE-TYPE PIC X(2). 01 DEALLOCATION-TYPE PIC X(2). 01 DISPATCHING-PROCESS PIC X(6). 01 INDICATOR PIC X(1). 01 LOG-LEVEL PIC 9(4) COMP. 01 LUNAME PIC X(8). 01 MODENAME PIC X(8). 01 MAP-NAME PIC X(8). 01 NETNAME PIC X(34). 01 PREP-TO-RCV-TYPE PIC X(2). 01 PREP-TO-RCV-LOCKS PIC X(1). 01 PARTNER-UNINTERP-NAME PIC X(17). 01 PARTNER-TP-TYPE PIC X(1). 01 REP-CODE PIC S9(4) COMP.
COBOL Definitions for SNAX/APC COBOL Definitions 01 APC-NOT-DISPATCHED PIC X(1), VALUE IS "N". 01 APC-SYNC2-SUPPORTED PIC X(1), VALUE IS "Y". 01 APC-SYNC2-NOT-SUPPORTED PIC X(1), VALUE IS "N". 01 APC-FILL-BUFFER PIC X(1), VALUE IS "B". 01 APC-FILL-LL PIC X(1), VALUE IS "L". 01 APC-MAP-NAME-PRESENT PIC X(1), VALUE IS "Y". 01 APC-MAP-NAME-NOT-PRESENT PIC X(1), VALUE IS "N". 01 APC-LOCAL-ATTACH PIC X(1), VALUE IS "Y". 01 APC-NOT-LOCAL PIC X(1), VALUE IS "N".
COBOL Definitions for SNAX/APC COBOL Definitions 88 CS-CONFIRM-DEALLOCATE VALUE IS 8. 88 CS-DEALLOCATE VALUE IS 12. ?Section UOW-REQUEST-CODES,Tandem 01 UOW-ACTIVATE-SESS-REQ NATIVE-2 VALUE IS 2001. 01 UOW-ALLOCATE-REQ NATIVE-2 VALUE IS 1001. 01 UOW-CONFIRM-REQ NATIVE-2 VALUE IS 1002. 01 UOW-CONFIRMED-REQ NATIVE-2 VALUE IS 1003. 01 UOW-DEACTIVATE-SESS-REQ NATIVE-2 VALUE IS 2002. 01 UOW-DEALLOCATE-REQ NATIVE-2 VALUE IS 1004. 01 UOW-DISPATCHER-READY-REQ NATIVE-2 VALUE IS 3003.
COBOL Definitions COBOL Definitions for SNAX/APC 88 REQ-ERROR 02 VERSION-CODE 02 HEADER-RETURN-CODE 88 IPC-OK 88 INVALID-VERSION-CODE 88 INVALID-RESOURCE-ID 88 SERVICE-DENIED 88 INVALID-UOW-HEADER 88 REQ-TOO-LONG 88 REQ-TOO-SHORT 88 REP-TOO-LONG 88 INVALID-REQ-CODE 88 SNAX-FILE-ERROR 88 OUT-OF-RESOURCES 02 HEADER-RETURN-CODE-DETAIL 88 INVALID-INDICATOR 88 INVALID-TPNAME 88 INVALID-LUNAME 88 INVALID-SEND-LENGTH 88 INVALID-TYPE 88 INVALID-APC-VERB 88 TOO-MANY-UOWS 88 INVALID-RCVD-LENGTH 88 INVALID-SESSION-I
COBOL Definitions for SNAX/APC COBOL Definitions 88 CONFIRM-REQ-CODE VALUE IS 1002. 88 CONFIRMED-REQ-CODE VALUE IS 1003. 88 DEACTIVATE-SESS-REQ-CODE VALUE IS 2002. 88 DEALLOCATE-REQ-CODE VALUE IS 1004. 88 DISPATCHER-READY-REQ-CODE VALUE IS 3003. 88 DISPATCH-TP-REQ-CODE VALUE IS 3002. 88 DISPLAY-STATUS-REQ-CODE VALUE IS 3001. 88 FLUSH-REQ-CODE VALUE IS 1012. 88 GET-TYPE-REQ-CODE VALUE IS 1013. 88 GET-TP-PROPERTIES-REQ-CODE VALUE IS 1014. 88 GET-ATTRIBUTE-REQ-CODE VALUE IS 1005.
COBOL Definitions for SNAX/APC COBOL Definitions 88 RECEIVE-AND-WAIT-REP-CODE VALUE IS 1006. 88 RECEIVE-IMMEDIATE-REP-CODE VALUE IS 1011. 88 REQUEST-TO-SEND-REP-CODE VALUE IS 1007. 88 SEND-DATA-REP-CODE VALUE IS 1008. 88 SEND-ERROR-REP-CODE VALUE IS 1009. 88 TP-END-REP-CODE VALUE IS 3006. 88 TP-READY-REP-CODE VALUE IS 3005. 88 MC-ALLOCATE-REP-CODE VALUE IS 1101. 88 MC-CONFIRM-REP-CODE VALUE IS 1102. 88 MC-CONFIRMED-REP-CODE VALUE IS 1103. 88 MC-DEALLOCATE-REP-CODE VALUE IS 1104.
COBOL Definitions for SNAX/APC COBOL Definitions 88 RCD-ALLOC-FAIL-NO-RETRY VALUE IS 1. 88 RCD-ALLOC-FAIL-RETRY VALUE IS 2. 88 RCD-CONVERS-TYPE-MISMATCH VALUE IS 3. 88 RCD-SYNC-LEVL-NOT-SUPPTD VALUE IS 4. 88 RCD-TPNAME-NOT-RECOGNIZED VALUE IS 5. 88 RCD-TP-NOTAVAIL-NORETRY VALUE IS 6. 88 RCD-TP-NOTAVAIL-RETRY VALUE IS 7. 88 RCD-PIP-SPECIFIED-INCORRECTLY VALUE IS 8. 88 RCD-SECURITY-NOT-VALID VALUE IS 9. 88 RCD-PIP-NOT-ALLOWED VALUE IS 10.
COBOL Definitions COBOL Definitions for SNAX/APC 03 FILLER PIC X(34) VALUE "0010Out Of Resources". 03 FILLER PIC X(34) VALUE "9999Unknown Reply". 02 IPC-RETURN-CODE-TABR REDEFINES IPC-RETURN-CODE-TABLE. 03 IPC-RETURN-CODE-INFO OCCURS 12 TIMES. 04 IPC-MESSAGE-NUMBER PIC 9999. 04 IPC-MESSAGE-TEXT PIC X(30). ?SECTION IPC-RETURN-CODE-DETAIL-TAB,TANDEM 01 IPC-RETURN-CODE-DETAIL-TAB. 02 IPC-RETURN-CODE-DETAIL-TABLE. 03 FILLER PIC X(34) VALUE "0000IPC Ok". 03 FILLER PIC X(34) VALUE "0302Invalid Indicator".
COBOL Definitions COBOL Definitions for SNAX/APC 03 FILLER Supported". 03 FILLER 03 FILLER Stopped". 03 FILLER Stopped". 03 FILLER 03 FILLER 03 FILLER Mismatch". 03 FILLER 03 FILLER Buffer". 03 FILLER PIC X(34) VALUE "0405TP Request Not PIC X(34) VALUE "0406LU Stopped". PIC X(34) VALUE "0407Partner LU PIC X(34) VALUE "0408Partner Mode PIC X(34) VALUE "0409TPN Stopped". PIC X(34) VALUE "0410TPI Aborted". PIC X(34) VALUE "0411IPC Version PIC X(34) VALUE "0412Verb Not Allowed For PS LU".
COBOL Definitions COBOL Definitions for SNAX/APC Normal". 03 FILLER PIC X(32) VALUE "1006Parameter Error". 03 FILLER Purging". 03 FILLER Trunc". 03 FILLER 03 FILLER Retry". 03 FILLER Trunc". 03 FILLER Purging". 03 FILLER Trunc". 03 FILLER 03 FILLER Abend". 03 FILLER 03 FILLER Failure". 03 FILLER 03 FILLER Supported". 03 FILLER Supported". 03 FILLER Unsuccessful". 03 FILLER Check". 03 FILLER 03 FILLER VALUE "1007Program Error No Trunc".
COBOL Definitions COBOL Definitions for SNAX/APC Check". 03 FILLER 03 FILLER 03 FILLER No 03 FILLER Retry". 03 FILLER Limit 03 FILLER Violation". 03 FILLER PIC X(32) VALUE "1027Backout No Resync". PIC X(32) VALUE"1028Backout Resync". PIC X(32) VALUE "2001Activation Fail Retry". PIC X(32) VALUE "2002Activation Fail PIC X(32) VALUE "2004Mode Session Exceeded". PIC X(32) VALUE "3001State PIC X(32) VALUE "3002SNAX File Error". 03 FILLER PIC X(32) VALUE "9999Unknown Reply".
COBOL Definitions COBOL Definitions for SNAX/APC 03 FILLER PIC X(22) VALUE "0010PIP Not Allowed". 03 FILLER PIC X(22) VALUE "9999Unknown Reply". 02 ALLOCATION-ERROR-DETAIL-TABR REDEFINES ALLOCATION-ERRORDETAIL-TABLE. 03 ALLOCATION-ERROR-DETAIL-INFO OCCURS 11 TIMES. 04 ALLOC-ERROR-MESSAGE-NUMBER PIC 9999. 04 ALLOC-ERROR-MESSAGE-TEXT PIC X(18). ?SECTION DEALLOCATE-ABEND-DETAIL-TAB,TANDEM 01 DEALLOCATE-ABEND-DETAIL-TAB. 02 DEALLOCATE-ABEND-DETAIL-TABLE. 03 FILLER PIC X(22) VALUE "0000ABEND TP Remote".
COBOL Definitions COBOL Definitions for SNAX/APC 03 FILLER 03 FILLER 03 FILLER PIC X(22) VALUE "0000 ". PIC X(22) VALUE "0001Not SEND". PIC X(22) VALUE "0002Not SEND or RCV.". 03 FILLER PIC X(22) VALUE "9999Unknown Reply". 02 PROGRAM-STATE-DETAIL-TABR REDEFINES PROGRAM-STATE-DETAILTABLE. 03 PROGRAM-STATE-DETAIL-INFO OCCURS 4 TIMES. 04 PROGM-STATE-MESSAGE-NUMBER PIC 9999. 04 PROGM-STATE-MESSAGE-TEXT PIC X(18). ?SECTION DT-NAME-TAB,TANDEM 01 DT-NAME-TAB. 02 DT-NAME-TABLE.
COBOL Definitions for SNAX/APC COBOL Definitions 01 ALLOCATE-REQ-PARMS. 02 AL-PARTNER-TP-TYPE PIC X(1). 02 AL-SYNC-LEVEL PIC X(1). 02 RESERVED-2 PIC X(2). 02 AL-RET-CONTROL REDEFINES RESERVED-2 PIC X(2). 88 VALID-AL-RET-CONTROL VALUE IS "AL", " ", "IM". 88 WHEN-SESSION-ALLOCATED VALUE IS "AL", " ". 88 IMMEDIATE VALUE IS "IM". 02 AL-PARTNER-LUNAME PIC X(8). 02 AL-MODENAME PIC X(8). 02 AL-PARTNER-TPNAME PIC X(16). 02 AL-SECURITY-TYPE PIC X(1). 88 AL-SECURITY-TYPE-NONE VALUE IS "N".
COBOL Definitions for SNAX/APC 02 RESERVED-1 PIC X(1). 02 CMR-REQUEST-TO-SEND-IND PIC X(1). 88 CMR-RECEIVED VALUE IS "Y". 88 CMR-NOT-RECEIVED VALUE IS "N". ?SECTION CONFIRM-REP,TANDEM 01 CONFIRM-REP. 02 CMR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) 02 CMR-PARAMETERS. 03 RESERVED-1 PIC X(1). 03 CMR-REQUEST-TO-SEND-IND PIC X(1). 88 CMR-RECEIVED VALUE IS "Y". 88 CMR-NOT-RECEIVED VALUE IS "N".
COBOL Definitions for SNAX/APC 02 DE-TYPE PIC X(2). ?SECTION DEALLOCATE-REQ,TANDEM 01 DEALLOCATE-REQ. 02 DE-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) 02 DE-PARAMETERS. 03 DE-TYPE PIC X(2). ?SECTION DEALLOCATE-REP,TANDEM 01 DEALLOCATE-REP. 02 DER-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) ?SECTION DISPATCHER-READY-REQ,TANDEM 01 DISPATCHER-READY-REQ. 02 DR-HEADER. 03 REQ-UOW-ID PIC X(2).
COBOL Definitions for SNAX/APC 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) ?SECTION DISPLAY-STATUS-REQ-PARMS,TANDEM 01 DISPLAY-STATUS-REQ-PARMS. 02 DS-APC-LUNAME PIC X(8). ?SECTION DISPLAY-STATUS-REQ,TANDEM 01 DISPLAY-STATUS-REQ. 02 DS-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) 02 DS-PARAMETERS. 03 DS-APC-LUNAME PIC X(8). ?SECTION DISPLAY-STATUS-REP-PARMS,TANDEM 01 DISPLAY-STATUS-REP-PARMS. 02 DSR-APC-NETWORK-NAME PIC X(34).
COBOL Definitions for SNAX/APC 01 GET-ATTRIBUTES-REP. 02 GAR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) 02 GAR-PARAMETERS. 03 RESERVED-1 PIC X(1). 03 GAR-SYNC-LEVEL PIC X(1). 88 GAR-NO-SYNC-LEVEL VALUE IS "N". 88 GAR-CONFIRM-SYNC-LEVEL VALUE IS "C". 88 GAR-SYNCPT-SYNC-LEVEL VALUE IS "S". 03 GAR-APC-LUNAME PIC X(8). 03 GAR-PARTNER-LUNAME PIC X(8). 03 GAR-PARTNER-UNINTERP-NAME PIC X(17). 03 PAD PIC X(1). 03 GAR-MODENAME PIC X(8).
COBOL Definitions for SNAX/APC 03 REQ-UOW-CODE PIC 9(4) 02 PR-PARAMETERS. 03 PR-TYPE PIC X(2). 03 RESERVED-1 PIC X(1). 03 PR-LOCKS PIC X(1). ?SECTION PREP-TO-RECEIVE-REP,TANDEM 01 PREP-TO-RECEIVE-REP. 02 PRR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) ?SECTION RECEIVE-AND-WAIT-REQ-PARMS,TANDEM 01 RECEIVE-AND-WAIT-REQ-PARMS. 02 RESERVED-1 PIC X(1). 02 RW-FILL PIC X(1).
COBOL Definitions for SNAX/APC 03 RWR-WHAT-RECEIVED PIC 9(4) 88 WR-DATA VALUE IS 0. 88 WR-DATA-COMPLETE VALUE IS 1. 88 WR-DATA-INCOMPLETE VALUE IS 2. 88 WR-SEND VALUE IS 3. 88 WR-CONFIRM VALUE IS 4. 88 WR-CONFIRM-SEND VALUE IS 5. 88 WR-CONFIRM-DEALLOCATE VALUE IS 6. 88 WR-PS-HEADER-PENDING VALUE IS 8. 88 WR-PS-HEADER-COMPLETE VALUE IS 9. 88 WR-PS-HEADER-INCOMPLETE VALUE IS 10. ?SECTION RECEIVE-IMMEDIATE-REQ-PARMS,TANDEM 01 RECEIVE-IMMEDIATE-REQ-PARMS. 02 RESERVED-1 PIC X(1). 02 RI-FILL PIC X(1).
COBOL Definitions COBOL Definitions for SNAX/APC 88 WR-DATA 88 WR-DATA-COMPLETE 88 WR-DATA-INCOMPLETE 88 WR-SEND 88 WR-CONFIRM 88 WR-CONFIRM-SEND 88 WR-CONFIRM-DEALLOCATE 88 WR-PS-HEADER-PENDING 88 WR-PS-HEADER-COMPLETE 88 WR-PS-HEADER-INCOMPLETE ?SECTION REQUEST-TO-SEND-REQ,TANDEM 01 REQUEST-TO-SEND-REQ. 02 RS-HEADER. 03 REQ-UOW-ID 03 REQ-UOW-CODE ?SECTION REQUEST-TO-SEND-REP,TANDEM 01 REQUEST-TO-SEND-REP. 02 RSR-HEADER.
COBOL Definitions COBOL Definitions for SNAX/APC ?SECTION SEND-ERROR-REP-PARMS,TANDEM 01 SEND-ERROR-REP-PARMS. 02 RESERVED-1 02 SER-REQUEST-TO-SEND-IND 88 SER-RECEIVED 88 SER-NOT-RECEIVED ?SECTION SEND-ERROR-REP,TANDEM 01 SEND-ERROR-REP. 02 SER-HEADER. 03 REP-UOW-ID 03 REP-VERB-CODE 03 REP-RETURN-CODE 03 REP-RETURN-CODE-DETAIL 02 SER-PARAMETERS. 03 RESERVED-1 03 SER-REQUEST-TO-SEND-IND 88 SER-RECEIVED 88 SER-NOT-RECEIVED ?SECTION TP-END-REQ,TANDEM 01 TP-END-REQ. 02 TE-HEADER.
COBOL Definitions for SNAX/APC 03 REP-RETURN-CODE-DETAIL PIC S9(4) 02 TRR-PARAMETERS. 03 RESERVED-2 PIC X(2). ?SECTION S5-TP-READY-REQ,TANDEM 01 TP-READY-REQ. 02 TR-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) 02 TR-PARAMETERS. 03 TR-LOCAL-ATTACH-INDICATOR PIC X(1). 03 TR-DISPATCHED-INDICATOR PIC X(1). 03 TR-APC-LUNAME PIC X(8). 03 TR-LOCAL-TPNAME PIC X(16). 02 TR-SYNC-SUPPORT-INDICATOR PIC X(1). ?SECTION S5-TP-READY-REP,TANDEM 01 TP-READY-REP. 02 TRR-HEADER. 03 REP-UOW-ID PIC X(2).
COBOL Definitions COBOL Definitions for SNAX/APC 88 MC-AL-SYNC-LEVEL-NONE 88 MC-AL-SYNC-LEVEL-CONFIRM 02 MC-AL-RET-CONTROL 88 MC-VALID-AL-RET-CONTROL 88 MC-WHEN-SESSION-ALLOCATED 88 MC-IMMEDIATE 02 MC-AL-PARTNER-LUNAME 02 MC-AL-MODENAME 02 MC-AL-PARTNER-TPNAME 02 MC-AL-SECURITY-TYPE 88 MC-AL-SECURITY-TYPE-NONE 88 MC-AL-SECURITY-TYPE-SAME 88 MC-AL-SECURITY-TYPE-PGM 02 PAD 02 MC-AL-USER-ID 02 MC-AL-PASSWORD ?SECTION MC-ALLOCATE-REQ,TANDEM 01 MC-ALLOCATE-REQ. 02 MC-AL-HEADER.
COBOL Definitions for SNAX/APC 02 MC-CMR-REQUEST-TO-SEND-IND PIC X(1). 88 MC-CMR-RECEIVED VALUE IS "Y". 88 MC-CMR-NOT-RECEIVED VALUE IS "N". ?SECTION MC-CONFIRM-REP,TANDEM 01 MC-CONFIRM-REP. 02 MC-CMR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) 02 MC-CMR-PARAMETERS. 03 RESERVED-1 PIC X(1). 03 MC-CMR-REQUEST-TO-SEND-IND PIC X(1). 88 MC-CMR-RECEIVED VALUE IS "Y". 88 MC-CMR-NOT-RECEIVED VALUE IS "N".
COBOL Definitions for SNAX/APC 01 MC-FLUSH-REQ. 02 MC-FL-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) ?SECTION MC-FLUSH-REP,TANDEM 01 MC-FLUSH-REP. 02 MC-FLR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) ?SECTION MC-GET-ATTRIBUTES-REQ,TANDEM 01 MC-GET-ATTRIBUTES-REQ. 02 MC-GA-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) ?SECTION MC-GET-ATTRIBUTES-REP-PARMS,TANDEM 01 MC-GET-ATTRIBUTES-REP-PARMS.
COBOL Definitions for SNAX/APC 02 GAR-APC-LUNAME PIC X(8). 02 GAR-PARTNER-LUNAME PIC X(8). 02 GAR-PARTNER-UNINTERP-NAME PIC X(8). 02 GAR-MODENAME PIC X(8). ?SECTION S1-MC-GET-ATTRIBUTES-REP,TANDEM 01 S1-MC-GET-ATTRIBUTES-REP. 02 GAR-HEADER. 03 REP-UOW-ID PIC X(2). 03 REP-VERB-CODE PIC 9(4) 03 REP-RETURN-CODE PIC S9(4) 03 REP-RETURN-CODE-DETAIL PIC S9(4) 02 GAR-PARAMETERS. 03 RESERVED-1 PIC X(1). 03 GAR-SYNC-LEVEL PIC X(1). 88 GAR-NO-SYNC-LEVEL VALUE IS "N". 88 GAR-CONFIRM-SYNC-LEVEL VALUE IS "C".
COBOL Definitions for SNAX/APC ?SECTION MC-RECEIVE-AND-WAIT-REQ,TANDEM 01 MC-RECEIVE-AND-WAIT-REQ. 02 MC-RW-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) 02 MC-RW-PARAMETERS. 03 RESERVED-2 PIC X(2). 03 MC-RW-MAX-DATA-LENGTH PIC 9(4) ?SECTION MC-RECEIVE-WAIT-REP-PARMS,TANDEM 01 MC-RECEIVE-WAIT-REP-PARMS. 02 RESERVED-1 PIC X(1). 02 MC-RWR-REQUEST-TO-SEND-IND PIC X(1). 88 MC-RWR-RECEIVED VALUE IS "Y". 88 MC-RWR-NOT-RECEIVED VALUE IS "N". 02 MC-RWR-WHAT-RECEIVED PIC 9(4) 88 MC-WR-DATA VALUE IS 0.
COBOL Definitions for SNAX/APC 03 MC-RI-MAX-DATA-LENGTH PIC 9(4) ?SECTION MC-RECEIVE-IMMED-REP-PARMS,TANDEM 01 MC-RECEIVE-IMMED-REP-PARMS. 02 RESERVED-1 PIC X(1). 02 MC-RIR-REQUEST-TO-SEND-IND PIC X(1). 88 MC-RIR-RECEIVED VALUE IS "Y". 88 MC-RIR-NOT-RECEIVED VALUE IS "N". 02 MC-RIR-WHAT-RECEIVED PIC 9(4) 88 MC-WR-DATA VALUE IS 0. 88 MC-WR-DATA-COMPLETE VALUE IS 1. 88 MC-WR-DATA-INCOMPLETE VALUE IS 2. 88 MC-WR-SEND VALUE IS 3. 88 MC-WR-CONFIRM VALUE IS 4. 88 MC-WR-CONFIRM-SEND VALUE IS 5.
COBOL Definitions for SNAX/APC COBOL Definitions 02 MC-SD-PS-HEADER-IND PIC X(1). 88 MC-SD-PS-HEADER-PRESENT VALUE IS “Y”. 88 MC-SD-PS-HEADER-NOT-PRESENT VALUE IS "N". 88 BLANK-3 VALUE IS " ". 02 MC-SD-MAP-NAME-IND PIC X(1). 88 MC-SD-MAP-NAME-PRESENT VALUE IS "Y". 88 MC-SD-MAP-NAME-NOT-PRESENT VALUE IS "N". 02 MC-SD-MAP-NAME PIC X(8). ?SECTION MC-SEND-DATA-REQ,TANDEM 01 MC-SEND-DATA-REQ. 02 MC-SD-HEADER. 03 REQ-UOW-ID PIC X(2). 03 REQ-UOW-CODE PIC 9(4) COMP. 02 MC-SD-PARAMETERS. 03 RESERVED-1 PIC X(1).
COBOL Definitions COBOL Definitions for SNAX/APC 02 RESERVED-1 02 MC-SER-REQUEST-TO-SEND-IND 88 MC-SER-RECEIVED 88 MC-SER-NOT-RECEIVED ?SECTION MC-SEND-ERROR-REP,TANDEM 01 MC-SEND-ERROR-REP. 02 MC-SER-HEADER. 03 REP-UOW-ID 03 REP-VERB-CODE 03 REP-RETURN-CODE 03 REP-RETURN-CODE-DETAIL 02 MC-SER-PARAMETERS. 03 RESERVED-1 03 MC-SER-REQUEST-TO-SEND-IND 88 MC-SER-RECEIVED 88 MC-SER-NOT-RECEIVED PIC X(1). PIC X(1). VALUE IS "Y". VALUE IS "N". PIC PIC PIC PIC X(2). 9(4) S9(4) S9(4) PIC X(1). PIC X(1).
B Request and Return Code This appendix summarizes the verb request codes and return codes defined in the DDL file that is shipped with SNAX/APC. Table B-1. IPC Request Codes (REQ-CODE) Request Code Decimal Hexadecimal STOP-ON-ERROR -2 FFFE Table B-2. IPC Reply Codes (REP-CODE) Request Code Decimal Hexadecimal ALL-UOWS-OK 0 0000 UOWS-WITH-ERROR 2 0002 REQ-ERROR 3 0003 Table B-3.
Request and Return Code Table B-4.
Request and Return Code Table B-5.
Request and Return Code Table B-5. Verb Request Code Summary (REQ-UOW-CODE) (page 2 of 2) Verb Request Decimal Hexadecimal MC-REQUEST-TO-SEND 1107 0453 MC-SEND-DATA 1108 0454 MC-SEND-ERROR 1109 0455 Table B-6.
Request and Return Code Table B-7. ALLOCATION-ERROR Return Code Detail (REP-RETURN-CODEDETAIL) Return Code Detail Decimal Hexadecimal RCD-ALLOC-FAIL-NO-RETRY 1 0001 RCD-ALLOC-FAIL-RETRY 2 0002 RCD-CONVERS-TYPE-MISMATCH 3 0003 RCD-SYNC-LEVL-NOT-SUPPTD 4 0004 RCD-TPNAME-NOT-RECOGNIZED 5 0005 RCD-TP-NOTAVAIL-NO-RETRY 6 0006 RCD-TP-NOTAVAIL-RETRY 7 0007 RCD-PIP-NOT-SPECIFIED-CORRECTLY 8 0008 RCD-SECURITY-NOT-VALID 9 0009 Table B-8.
Request and Return Code Table B-11.
C Conversation-State Matrix This conversation-state matrix (CSM) represents the state transitions that can occur for a TP when verbs are issued in a particular state. This CSM was adapted from the Conversation-State Matrices documented in Appendix E of the IBM Transaction Programmer’s Reference Manual for LU Type 6.2. The states depicted in this CSM are more precise than the states used in the main body of this manual.
Conversation-State Matrix Table C-1.
Conversation-State Matrix Table C-1.
Conversation-State Matrix Table C-1.
Conversation-State Matrix Table C-1.
Conversation-State Matrix The DEALLOCATE parameter abbreviations, delimited by parentheses, have the following meanings: Symbol Meaning AB Type ABEND-PROGRAM CO Type CONFIRM or type SYNC-LEVEL when synchronization level is CONFIRM FL Type FLUSH LO Type LOCAL SL If SYNCH-LEVEL is NONE, see DEALLOCATE (FL). If SYNCH-LEVEL is CONFIRM, see DEALLOCATE (CO).
Conversation-State Matrix The PREPARE-TO-RECEIVE parameter abbreviations, delimited by parentheses, have the following meanings: Symbol Meaning CO Type CONFIRM or type SYNC-LEVEL when synchronization level is CONFIRM FL Type FLUSH SL If SYNC-LEVEL is NONE, see DEALLOCATE (FL). If SYNC-LEVEL is CONFIRM, see DEALLOCATE (CO).
Conversation-State Matrix SNAX/APC Application Programming Manual—138786 C- 8
Glossary This glossary includes several definitions taken from the IBM Dictionary of Computing, IBM Network Program Products: General Information, VTAM Programming for LU 6.2, and SNA Type 2.1 Node Reference Please refer to these IBM manuals for IBM terms not included in this glossary. access method. An I/O process that allows applications running on a NonStop system to communicate with other systems or devices.
backup CPU Glossary attribute is sometimes called a modifier. (2) For the Tandem Service Management (TSM) package, a data item associated with a resource. All attributes can be viewed and some can be modified. backup CPU. The central processing unit (CPU) number of the Tandem processor on which the backup process will run. See backup process. backup process. In a Tandem NonStop system, a process that is identical to the primary process and is created at the same time as the primary process.
CNOS verbs Glossary CNOS verbs. Verbs that a control operator program uses to control the number of sessions between a pair of LUs. command file. An EDIT file that contains a series of commands and serves as a source of command input. configuration. (1) The arrangement of enclosures, system components, and peripheral devices into a working unit. (2) The definition or alteration of characteristics of an object. control operator program. For LU 6.
Distributed Systems Management (DSM) Glossary Distributed Systems Management (DSM). A set of tools used to manage Tandem NonStop systems and Expand networks. domain. A set of objects over which control or ownership is maintained. Types of domains include power domains and service processor (SP) domains. DOUT. Data transmitted from SNAX/APC. DSM. See Distributed Systems Management (DSM). dynamic.
finite state machine Glossary NonStop systems. If the network is properly designed, communication paths are constantly available even if there is a single line failure or component failure. finite state machine. An algorithm that controls the transition of an object—for example, a SNA session—between a finite number of states, each state transition being generated by one of a finite number of events. first speaker.
independent verbs Glossary independent verbs. Verbs that can be used in either basic or mapped conversations. SNAX/APC supports only GET-TYPE. interprocessor communications (IPC). The exchange of messages between processors. I/O process. A system process to manage I/O hardware. Applications use the operating system to send requests to I/O processes. IPC. See interprocessor communications (IPC). IPC version code.
LU-LU session Glossary LU-LU session. The creation of a temporary data path consisting of a physical and a logical connection between two LUs in separate domains for information exchange. To establish a data path between two LUs in separate domains for data exchange, four types of sessions must exist: SSCP-SSCP, SSCP-PU, SSCP-LU, and LU-LU. (LU, mode) pair. A specific combination of partner LU and mode. mapped conversation. In SNA, an LU 6.
NonStop operation Glossary NonStop operation. A Tandem system behavior characterized by continued operation even when a component fails, when equipment is being repaired or replaced, or while new processors or peripheral devices are being added to the system. Legally used only to describe the Tandem Nonstop system or its features, such as NonStop process pairs. Obey file. See command file. object.
PATHMON environment Glossary PATHMON environment . The servers, server classes, TCPs, terminals, SCREEN COBOL programs, and tell messages that run together under the control of one PATHMON process. Pathway. A group of software tools for developing and monitoring OLTP (on-line transaction processing) applications that use the requester/server model.
request unit Glossary request unit. In SNA, a message unit that contains control information such as a request code, or function management headers, end-user data or both. resource control block (RCB). A control block that represents the connection of a transaction program to a half-session. response unit. In SNA, a message unit that acknowledges a request unit. It may contain additional information in response to the request. return code (RC).
service transaction program (STP) Glossary service transaction program (STP). A transaction program that provides only a limited specific network function. session. In SNA, a temporary logical connection between two network addressable units for the purpose of exchanging data and control information in accordance with ground rules that have been agreed upon for that exchange. A session can be activated, tailored to provide various protocols, and deactivated, as requested. SLU.
SNALU Glossary SNALU. A SNAX/XF, SNAX/APN and SNAX/CDF programmatic interface that provides the functions of the lower two SNA layers (data link control and path control) and some functions of the transmission control layer. SNAXLink. A Tandem product comprised of both hardware and software that provides a direct channel link between a Tandem system and several types of IBM systems. SNAXLink can also be used with IBM channel-compatible systems that contain VTAM and SNA support. SPI.
SYSGEN Glossary SYSGEN. Tandem system generation program used to tailor the operating system for a specific hardware and software configuration. SYSGEN is a subset of Install that creates a system image only. The SYSGEN process can be divided into three phases: configuring the system, generating the operating system, and installing the operating system. Synchronization.
TCP Glossary TCP. See terminal control process (TCP). terminal control process (TCP). A process responsible for terminal management and transaction control, provided by Tandem as part of the Pathway/TS product. A TCP is a multithreaded process that interprets the SCREEN COBOL requester programs in the user’s application, executing the appropriate instructions for each I/O device or process the TCP is configured to handle.
VTAM Glossary VTAM. Virtual Telecommunications Access Method. WAN subsystem. See wide area network (WAN). WAN subsystem manager process. A process named $ZZWAN provided as part of the wide area network (WAN) subsystem that starts and manages the WAN subsystem objects, the WAN product process, and device objects. Subsystem Control Facility (SCF) commands are directed to the WAN subsystem manager process for configuring and managing the WAN subsystem and the ServerNet wide area network (SWAN) concentrator.
$ZZWAN Glossary SNAX/APC Application Programming Manual—138786 Glossary -16
Index A ACTIVATE-SESSION verb 3-2/3-4 APS screen 4-8 ALLOCATE verb 3-8/3-14 APS screen 4-12 APCRUN setting up APS with 4-5 APS function keys 4-3/4-4 hexadecimal editor 4-76 how to use 4-4 loop-back configuration 4-6 overview 4-1 PATHMON configuration 4-5 print screen function 4-78 recover screen function 4-78 setting up with APCRUN 4-5 starting 4-6 translate to ASCII function 4-77 translate to EBCDIC function 4-77 user interface 4-2 verb screens ACTIVATE-SESSION 4-8 ALLOCATE 4-12 CONFIRM 4-15 CONFIRMED 4-17
D Index CANCEL processing (continuation) MC-GET-ATTRIBUTE 3-60 MC-ALLOCATE 3-50 MC-DEALLOCATE 3-57 MC-PREPARE-TO-RECEIVE 3-63 MC-RECEIVE-AND-WAIT 3-67 MC-RECEIVE-IMMEDIATE 3-71 MC-REQUEST-TO-SEND 3-72 MC-SEND-DATA 3-76 MC-SEND-ERROR 3-79 PREPARE-TO-RECEIVE 3-25 RECEIVE-AND-WAIT 3-31 RECEIVE-IMMEDIATE 3-37 REQUEST-TO-SEND 3-38 SEND-DATA 3-41 SEND-ERROR 3-43 TP-END 3-96 TP-READY 3-101 Checking return codes 1-23 COBOL READ WITH PROMPT statement 2-3 TPs written in 2-3 Completion codes See Return codes Concurr
H Index General Data Stream See GDS GET-ATTRIBUTES verb 3-21/3-23 APS screen 4-23 GET-TP-PROPERTIES verb 3-92/3-95 APS screen 4-69 GET-TYPE verb 3-79/3-81 APS screen 4-67 LUs local establishing communication with 111 LUWID 1-34 Protected 3-93 Unprotected 3-93 LUWs 1-31 H M Hexadecimal editor, APS 4-76 Mapped verbs use of 1-3 MC-ALLOCATE verb 3-46/3-52 APS screen 4-39 MC-CONFIRM verb 3-52/3-54 APS screen 4-42 MC-CONFIRMED verb 3-54 APS screen 4-44 MC-DEALLOCATE verb 3-55/3-58 APS screen 4-46 MC-FLUSH
O Index Messages, IPC See IPC messages Mixed mode conversations use of 1-3 O Opening SNAX/APC from a TP 1-7 P Parsing replies 1-23 PATHMON environment APS configuration 4-5 starting APS 4-6 PREPARE-TO-RECEIVE verb 3-23/3-26 APS screen 4-25 Presentation Services Headers See PS Headers Programming TPs allowed languages 1-2 changing between Send and Receive 125 error handling 1-7 handing RECEIVE-AND-WAIT replies 1-23 in SCREEN COBOL 1-6 qualified opens 1-7 responding to state change request 1-26 PS Headers
T Index SEND-ERROR verb 3-42/3-44 APS screen 4-37 SNAX/APC COBOL data definitions A-1/A-31 NonStop operation of 1-10 qualified opens 1-7 replies to TP requests 2-4 Starting conversations 1-14 local TP initiates 1-14 States changing between Send and Receive 125 defined 1-22 responding to request for change of 126 Sync Point Resynchronization 1-32 Services 1-31 Support 1-32 T TAL TPs written in 2-3 TPs allowed programming languages 1-2 conversation states 1-22 data required GDS format 1-28 multi-threaded 1
V Index UOWs (continuation) MC-DEALLOCATE 3-55/3-58 MC-FLUSH 3-58 MC-GET-ATTRIBUTES 3-59/3-61 MC-PREPARE-TO-RECEIVE 3-61/364 MC-RECEIVE-AND-WAIT 3-64/3-68 MC-RECEIVE-IMMEDIATE 3-68/372 MC-REQUEST-TO-SEND 3-72 MC-SEND-DATA 3-73/3-77 MC-SEND-ERROR 3-77/3-79 PREPARE-TO-RECEIVE 3-23/3-26 RECEIVE-AND-WAIT 3-26/3-32 RECEIVE-IMMEDIATE 3-32/3-38 replies 2-4 parsing 1-23 reply header individual field descriptions 2-17 structure of 2-15/2-17 request header individual field descriptions 2-14 structure of 2-14 REQUES
W Index Verbs (continuation) TP-READY 3-97/3-101 queuing of requests 1-12 request types 1-11 using APS to execute See APS Version codes for IPC header 1-4, 2-6, 4-6 W WRITEREAD system procedure 2-3 SNAX/APC Application Programming Manual—138786 Index- 7
W Index SNAX/APC Application Programming Manual—138786 Index- 8
