Switch to standard view 
  Sybase logo
 
 
 



This white paper examines SNA LU6.2 and APPC communications concepts. In additon to it's conceptual content it provides a detailed discussion of the protocol and provides SNA trace examples detailing the data flow between a Sybase gateway and the mainframe. It is a complementary white paper to the LU6.2 vs. TCP/IP white paper. The original document this white paper is derived from "TROUBLESHOOTING APPC AND THE SYBASE GATEWAY FOR DB2" is also available.

Table of Contents

Introduction *

A Brief History of SNA and APPC *

APPC Conceptual Overview *

APPC Building Blocks: SNA *

SNA LU6.2 in the OSI Seven-Layer Network Model *

Physical Layer *

Data Link Layer *

Network Layer *

Transport Layer *

Session Layer *

Presentation Layer *

Application Layer *

Example Physical and Data Link Connections *

Building Blocks of an APPC Connection *

Physical Units (PU) *

Logical Units (LU) *

Sessions *

Session Establishment *

Request Units (RU's) *

Mode *

Contention Winners and Losers *

Change Number of Sessions (CNOS) *

Exchange ID's (XID's) and Control Points *

APPC and LU 6.2 *

Transaction Programs (TP's) *

APPC Software Version Requirements *

APPC Conversation Basics *

Setting Up An APPC Connection *

VTAM Definitions *

PU and LU Definition *

MODE Definition *

APPL Definition *

CICS Definitions *

CICS Connection Definition *

Gateway Server SNA Configuration *

Testing the APPC Connection *

Testing SNA Session-Level Connectivity *

Checking Session-Level Connectivity from CICS *

Checking Session-Level Connectivity from the Gateway Server *

Testing APPC Connectivity *

Using SNAPING to Test APPC Connectivity *

Using APPCTEST to Test APPC Connectivity *

Troubleshooting APPC Connectivity *

Creating an SNA Trace *

Reading an SNA Trace *

Step 1: Exchange ID (XID) Negotiation *

Step 2: Activate Physical Unit (ACTPU) *

Step 3: Activate Logical Unit (ACTLU) *

Step 4: Binding SNASVCMG Sessions between LU's *

Step 5: CNOS Negotiation *

Step 6: APPC Conversation Initiation *

SNA Tracing Conclusion *

Common SNA Problems and Solutions *

SNA Sense Data Errors *

References *

Introduction

Advanced Program to Program Communication, also known as APPC, was initially released in 1982 by IBM Corporation. APPC was intended to be the "next generation" protocol in IBM's Systems Network Architecture (SNA), which previously did not support peer-type connections between machines.

A Brief History of SNA and APPC

SNA was originally released in the 1970's by IBM to provide a uniform method for various peripherals to access mainframe computers. Initially only cathode ray tube (CRT) terminals and printers were supported for on-line data processing.

APPC Conceptual Overview

Advanced Program to Program Communication (APPC) was developed by IBM for the purpose of providing enhanced SNA support for distributed processing. The theory behind this is to allow any device on the LAN to communicate and access any application and/or data on the LAN regardless of its operating system software or hardware. This is what IBM refers to as "any-to-any" communications or in other words "peer-to-peer" communications. The logical unit type used to accomplish this task is LU6.2. Logical Units are the end users interface to the SNA network. Logical Units are attached to the path control network which is responsible for the addressing and routing of data packets. Path control for these LU6.2s come from PU Type 2.1 devices. VTAM and NCP support for these T2.1 nodes came in VTAM V3R2 and NCP V4R3(3725) and NCP V5R2(3720,3745). Together VTAM and NCP act as a T2.1 node refereed to as a "composite" T2.1 node. T2.1 nodes incorporate what is refereed to as a Co ntrol Point (CP). The CP could be likened to System Services Control Point (SSCP) found in VTAM. A couple of the CPs major functions are to initiate the activation and deactivation of the link , initiation and termination of LU to LU sessions. The session capabilities of the LU6.2 in a T2.1 node allows the LU to initiate sessions by sending a bind request to another LU6.2 node in the network. This allows the LU to be either a primary logical unit (PLU) the one sending the bind request for the session(s), or a secondary logical unit (SLU), the one receiving the bind request for the session. The capability of session establishment has eliminated the need for SSCP in VTAM to establish an SSCP-PU session with the T2.1 node. The T2.1 node only needs the SSCP-PU session for network management data flows.

APPC Building Blocks: SNA

Before attempting to understand APPC, it is important to have an understanding of the underlying protocol upon which APPC is built: SNA. Once SNA terminology and concepts are understood, APPC is relatively easy to comprehend.

SNA, like all networking protocols, adheres to the OSI 7-layer networking standard. Below is the OSI 7 layer model (left most column), with the columns to the right identifying specific components and functions as related to a three tier client/server "middleware" model.

SNA LU6.2 in the OSI Seven-Layer Network Model

 

 

Host

Gateway

Client

Function

         

Application

VSAM/DB2,etc.

Gateway

Power Builder/etc.

 

Presentation

Open Server/ CICS

Open Server

Open Client

Data Formatting/Conversion

Session

CPI-C

CPI-C

Sockets

Negotiation/Connection Establishment

Transport

APPC

APPC

TCP

End-to-End delivery of data

Network

SNA

SNA

IP

Routing across multiple networks

Data Link

(DLC) Token Ring

(DLC)Token Ring

TR / Ethernet

Token Ring Packet Size

Physical

802.5

802.5

802.5/802.3

IEEE Electrical Spec. "copper"

 

Figure 1. SNA/LU6.2 in the OSI Seven-Layer Network Model in a Three-Tier, Middleware Solution

 

 

The following discussion focuses on the left most column of the above chart, beginning at the bottom physical layer of SNA and works "upward" in the conceptual model until the application layer is reached. APPC always assumes that there are two programs "conversing" with one another via an underlying SNA connection. Each layer communicates with the layers that neighbor it via an application programming interface (API).

 

Physical Layer

The physical layer in a network specifies the actual electrical standard that any two nodes in a network will use for communication. The "official" definition of the physical layer is defined as "transmission of binary data over a communications medium."

The four most common physical layer electrical standards are as follows:

  • Token Ring Network
  • Ethernet Network
  • Synchronous Data Link Control (SDLC)
  • Channel (SCON) Attachment

Token Ring and Ethernet are "standard" Local Area Network cards, and SDLC is generally a dial-up, or leased line type of serial connection. SCON channel attachment allows a device to be attached directly to the mainframe's "bus", and all other devices except the SCON connection requires an additional hardware device to be channel attached to the mainframe to provide physical connectivity. These devices are variously known as Front End Processors (FEP's), cluster controllers, or communications controllers.

Data Link Layer

The official definition of the Data Link Layer is "transfer of addressable units of information, frames, and error checking." What this means is that the data link layer controls the characteristics of the network packets that are sent to the physical layer, including addressing and error control information. In an SNA network, these packets are variously known as "I Frames" or Basic Transmission Units (BTUs). The size of this packet is very important in relation to the overall system performance, particularly if large quantities of data are planning on being passed between the APPC applications.

Technically, the data link layer is comprised of the network interface card (NIC); the Token Ring NIC, for example, comprises the DLC layer.

Network Layer

The official definition of the network layer is "routing of packets of information across multiple networks." The primary responsibility of this layer is to ensure that network packets get from one local area network to another-in other words, the network layer is responsible for negotiating wide area networks.

Transport Layer

The definition of the transport layer is "provision for reliable end-to-end delivery of data", and this layer comprises the bulk of SNA's responsibilities. To put it another way, the transport layer communicates with the network layer, which in turn communicates with the physical layer, and the transport layer is the core of the services that SNA performs. Anything below the transport layer is really hardware related, and anything above the transport layer becomes more and more application related.

Think of SNA as a reliable Mack truck that may haul various types of data reliably from point "A" to point "B". While SNA may not know much about what it's hauling, it is very efficient and very reliable.

Session Layer

With SNA providing the reliable end-to-end delivery mechanism, APPC comes into the picture at the session layer. The definition of this layer is "negotiation and establishment of a connection with another node", and this is exactly what APPC was intended to do. Keep in mind that in the APPC world, both nodes are actually programs. Also realize that APPC actually "rides on top of" SNA-this understanding will be very important later on when we discuss configuration of an SNA network.

When APPC was first released, programs that wanted to use APPC as their communications vehicle had to interface directly with the APPC API, bypassing the presentation layer below. IBM realized pretty quickly how onerous this was and released a simpler API, which comprises the presentation layer below.

Presentation Layer

The presentation layer provides "data formatting, character code conversion, and data encryption." In general, this layer provides a fairly user-friendly way to interface client applications to the rest of the network, and in APPC this is known as CPI-C. Two CPI-C programs "converse" with one another using APPC "verbs" that comprise the APPC API, and this conversation occurs across the underlying network layers (including SNA).

Application Layer

The application layer was designed to be the end-user layer, although in a middleware environment this layer is typically gateway or communications software. For example, the application layer might be a Sybase DirectConnect gateway on one end of the APPC connection and CICS on the other.

Example Physical and Data Link Connections

As previously described, the physical layer is the electrical specification used between two network nodes. This is usually a token ring, Ethernet, SDLC, or SCON connection, and the data link is simply the card that interfaces with the physical medium.

Figure 2: Token Ring Gateway to FEP Connection

 

 

Building Blocks of an APPC Connection

Once physical connectivity has been defined and established, definition of the actual APPC connection may occur. Before the APPC connection may be established, the underlying SNA connection must be defined. An understanding of the building blocks of an APPC connection is therefore critical to the process.

Physical Units (PU)

In SNA parlance, the two machines depicted above (the gateway server and the FEP) are known as "Physical Units", commonly referred to as "PU's". PU's represent the physical and data link layers in the OSI model and as such form the basis of an SNA connection.

PU's are referred to by a version number, which indicates what type of functionality they are capable of supporting. PU type 2.0 is the minimum requirement for supporting APPC type connections, and PU type 2.1, the latest and greatest, is required to support the most common form of APPC.

Logical Units (LU)

When IBM originally designed SNA, it became apparent that there would commonly be more than one use for each type of Physical Unit (PU). Since PU's typically have the capability to handle a large amount of bandwidth for different types of uses (for example, it was desirable to use a single PU for terminal, printer, and other types of communications), the concept of a Logical Unit (LU) was introduced.

LU's allow a single PU to be logically separated into different types of communications functions; for example, a PU may be separated into as many as 256 different LU's. There are many different types of LU's, starting with LU type 0 and ending with LU type 6. The type of the LU refers to what sort of communications will be carried across it; for example, an LU type 2 is a 3270 CRT terminal.

The most important type of LU that we are concerned about is the last type: LU 6. LU type 6 was introduced with APPC with the idea that type 6 LU's would be used to carry APPC type traffic, much the same way that the former LU types were used to carry other types of SNA traffic.

The latest and greatest "version" of LU 6 is known as "LU 6.2", also known as "LU type 6, version 2". This is the most commonly used LU type for APPC traffic, and is the only type supported for use with Sybase middleware products.

Not coincidentally, a PU type of 2.0 is required as a minimum for LU 6.2 connections; the combination of a PU type 2.0 and an LU 6.2 supports what is known as a "Dependent LU", and the combination of a PU 2.1 and LU 6.2 supports an "Independent LU". The difference between these types is illustrated in the following chart.

 

 

Dependent LUs vs. Independent LUs
DEPENDENT LUsINDEPENDENT LUs
Single LU-LU sessionMultiple/parallel sessions
Cannot initiate a bind(SLU)Can initiate a bind (PLU)
SSCP to LU session requiredNo SSCP to LU session required
Supported by T2.1 and T2.0 nodesSupported by T2.1 nodes only

 

 

Much the same as two PU's communicate with one another, two LU's also communicate with one another using their associated PU's. As you might guess, the two PU's that communicate with one another must be of the same type (for example, a Token Ring PU cannot "speak" to an SDLC PU-they are not compatible at the physical level). The same holds true for LU's-only LU's of the same type may "speak" with one another. For example, a type 6.2 LU may only speak with another type 6.2 LU.

An example of the LU to LU connection is shown below:

 

Figure 3: LU to LU connection

Sessions

The interconnection between LU's is known as a "session". Sessions are an extremely important concept to understand, as all SNA traffic is carried on them. Regardless of the type of LU or PU in use, all SNA traffic is always carried on a session.

Starting with PU type 2.1, LU 6.2, the ability to establish more than one session between two LU's was introduced. Prior to this point, only "single session" traffic between LU's was supported-this was a function of dependent LU's. PU type 2.1 supports "independent LU's" which in turn support multiple "parallel sessions". The primary advantage of parallel sessions occurs in a classic client/server environment, where multiple client applications need to connect between a gateway and the mainframe.

In a single session environment as depicted in Figure 3, only one client could send or receive data between LU pairs. In order to support multiple clients, multiple LU's would need to be defined between the gateway and the mainframe, which involves quite a bit of work and significant overhead. Parallel sessions simplify this considerably, as up to 256 parallel sessions may be established between two LU's. This implies that up to 256 concurrent users may send and receive data using the same LU's. The vast majority of Sybase middleware products are installed using parallel sessions, although single sessions are supported. The primary reason for a single session installation is that parallel session support was added to the Front End Processors (FEP's) and VTAM only at a certain version, and some mainframe installations are still running down-level software.

Figure 4: Parallel Sessions

 

In addition to parallel sessions, the capability exists for one LU to establish connections with one or more partner LU's. For example, a single LU defined on a gateway may establish connections with multiple CICS regions. The following diagram depicts this situation:

Figure 5: Multiple Parallel Sessions

 

Session Establishment

The establishment of a session is known as a "bind"-in other words, a session is "bound" between two LU's. One of the primary differences between parallel and single session APPC is the ability of the underlying LU on either side to initiate this bind process-in single session APPC this was not a requirement since there was only one session.

When two partners begin communicating, a certain number of sessions are "auto started". This means that the sessions are automatically bound at start time, ready for use by either partner. At a point in the future, if all currently bound sessions are in use and additional are required, they may be dynamically bound up to the total session limit defined in both partners. Once a session becomes bound, it stays bound until either partner is recycled.

The partner that establishes the session bind is known as the "Primary Logical Unit" (PLU), and the partner that receives the bind request is known as the "Secondary Logical Unit" (SLU).

Request Units (RU's)

Request Units (RU's) are used as the vehicle for transporting data between SNA LU's. The RU size is specified at the time of the session bind (in bytes) and is subject to negotiation. When a bind occurs, both partners specify a requested RU size, and the actual size is determined by taking the lesser of the two. For example, if one partner requests an RU size of 256 bytes, and the other partner requests an RU size of 1024 bytes, the smaller of the two becomes the actual "negotiated" RU size. RU size may vary between 256 bytes and 32 kilobytes. Once a RU is ready to be sent across the LU to LU session, it is handed down to the lower networking layers. These layers in turn encapsulate the RU inside of a DLC packet (also known as the Basic Transmission Unit (BTU) or the I-Frame), which in turn is encapsulated inside of a packet native to the physical medium (i.e. a token ring frame).

As you might guess, the size of the negotiated RU can be paramount in performance tuning considerations where large quantities of data are being transmitted across the network. Always keep in mind that an adequately tuned SNA environment not only includes the optimal RU size but also takes into account the accompanying DLC packet sizes as well as the underlying network limitations. For example, even though a large RU and DLC packet size have been specified, some routers have a maximum packet size limitation that will result in the RU/DLC packet being broken down into something smaller anyway-a situation that is not desirable as additional overhead is required to accomplish this. A thorough analysis of the end-to-end network architecture is required to determine the optimal RU and DLC packet sizes.

Mode

The description of the characteristics of how two LU's establish a session with one another is contained in a definition known as the "mode". Think of the mode definition as a template for intra-LU communications, which may be re-used repeatedly. The mode defines characteristics such as the size of SNA packets that are passed between LU's as well as the type of communications that occur; the mode defines the type of LU, for example.

Contention Winners and Losers

In a peer to peer environment, it sometimes becomes necessary for either "partner" to be able to "speak" across a session-thus the capability for either partner to be able to bind a session became crucial. Therefore, sessions may be "owned" by one partner or the other; this concept of ownership is known as "contention winners". Sessions that are not owned by each partner are known as "contention losers". Therefore, one partner's contention winners become the other partner's contention losers.

Sessions that are not owned by a partner may still be used if needed; the process for a partner to request the use of a contention loser is known as "bidding". In other words, a non-owned session may be "bid for"; if available, the partner relinquishes the contention winner for use by the other partner. As you might guess, this is not an optimal situation, as some overhead is required to accomplish this.

In the context of the Sybase middleware world, client sessions that connect from the LAN to the mainframe should be contention winners from the gateway's perspective, and mainframe programs that need connections to the LAN (i.e. Open ClientConnect transactions in CICS) should be contention winners from the mainframe perspective.

Change Number of Sessions (CNOS)

During the process of session establishment, several session related items must be negotiated, including the maximum number of sessions and the contention winners and losers for each partner. This process is known as "Change Number of Sessions", or CNOS.

In order to execute CNOS functions IBM has implemented a special mode name called SNASVCMG (SNA Service Management) which is reserved for use of the CNOS program. Recall that all sessions are established with modes, which describe the characteristics of the sessions.

Prior to actual "user" parallel sessions being established, there will be two sessions established (bound) with mode name SNASVCMG. Once the SNASVCMG sessions have been established, the CNOS process may commence.

Exchange ID's (XID's) and Control Points

In order for one physical unit (PU) to communicate with another, it must have a unique method of identifying itself and its' partner across the SNA network. The method used to do this is known as the Exchange ID (XID) or Control Point (CP). This is very similar to a TCP/IP network in which you may refer to a machine either by its' TCP/IP address (i.e. 206.247.74.120) or by it's logical host name (i.e. "scapa"). In an SNA network, the equivalent of the TCP/IP address is the XID, and the equivalent of the host name is the control point (CP).

The XID is actually the concatenation of two parameters: the ID Block (IDBLK) and the ID Number (IDNUM). The IDBLK is a three-digit integer, and the IDNUM is a 5-digit integer; the XID is therefore an 8-digit combination of the two. The CP name is an alphanumeric definition, up to 8 characters long. These parameters are coded in the PU definition, as you will see later.

APPC and LU 6.2

A common misconception is that APPC and LU 6.2 are the same thing-this is absolutely not the case. Remember in the OSI 7 layer model that SNA comprises the network and transport layers, and APPC is responsible for the session layer. Sitting on top of APPC is CPI-C, or the APPC API, which comprises the presentation layer. Communicating with CPI-C is a program that directs the desired communications using the CPI-C API.

Much the same as in TCP/IP, people often refer to "APPC/LU62" as one term, and it is important to realize that APPC uses LU62 as its protocol for transportation across the network. LU62 in turn relies on the underlying layers to accomplish its' communications requirements as well.

Transaction Programs (TP's)

Communication between two LU 6.2 nodes is accomplished using the CPI-C API and APPC. This type of communications, being a peer to peer (officially known as "program to program") method, assumes that there is also an APPC program on the other end of the network to communicate with.

The two programs on either end of the APPC link as known as "Transaction Programs", commonly referred to as "TP's". Two TP's establish an APPC "conversation", which then flows across the SNA "session". Thorough understanding of these terms is critical to the overall understanding of how APPC works. The following diagram depicts two TP's conversing with one another over an SNA session:

 

 

 

 

 

Note that once an APPC conversation is allocated across a session, that session is unavailable for use until the two partners finish conversing. Once the conversation de-allocates, the session again becomes available for use.

Depending on the gateway configuration, it is possible to support more concurrent client connections to the gateway than the number of currently available SNA sessions. The golden rule is that the total number of available SNA sessions must be greater than or equal to the total number of anticipated concurrent client requests executing at any given time.

APPC Software Version Requirements

In order for APPC parallel sessions to be established, the proper minimum software versions must be installed on the various components. The primary areas of concern are mainframe-related, as to date nearly all gateway-related SNA packages support parallel sessions out of the box.

The primary mainframe components of concern are as follows:

  • Channel Attached 3174 Cluster Controllers
  • VTAM 3.4 or above;
  • MVS/ESA (any version)
  • Microcode Level "C" and the APPN LIC feature
  • 3725/3745 Front End Processors (FEP's)

Note that FEP's have their own control software that run independent of the mainframe; this software is known as "Network Control Program", or NCP.

  • 3725's: NCP version 4.5 or above;
  • 3745's: NCP version 5.2 or above.
  • Customer Control Information System (CICS): Version 2.1 or above
  • Virtual Telecommunications Access Method (VTAM): version 3.2 or above (unless a 3174 is in use; see above for more information).

APPC Conversation Basics

Once the base SNA connectivity has been established, APPC communications may commence. While an understanding of APPC commands is not specifically required in order to install a connection between the gateway and mainframe, a basic understanding can be invaluable in a troubleshooting context.

APPC is an API and therefore an APPC conversation taking place between two transaction programs (TP's) takes place using a sequence of APPC verbs. In APPC 2 types of conversation verbs can be used: Basic and Mapped.

Mapped conversation verbs use the CPI-C API and are less complex to implement than basic conversation verbs because they shield the programmer from certain complexities in the structure of the underlying data stream.

Mapped verbs are intended for use by high-level language transaction programs and include optional support for data mapping. All of the verbs have a number of fields associated with them wherein specific parameters for the verb are specified (i.e. TP_ID, CONV_ID, etc.). For a more detailed breakdown of these verbs refer to the IBM APPC Programming Reference, publication number S01F-0263-00.

The Sybase middleware product architecture uses mapped conversation verbs so this discussion will be focused on the mapped verbs.

The MC_ALLOCATE verb is built by the gateway it is passed across the "protocol boundary" to the LU. The LU in this case being the communications package on the gateway. The LU then builds an FMH Type 5 ATTACH request which contains the MC_ALLOCATE parameters, the attach is sent from the gateway machine across the link to the host to start the requested transaction program. You can see the attach by doing a link level trace from the communications package or a VTAM trace.Note, however, that if the trace is run from the communications package, due to security concerns, some fields in the attach will not be displayed, for example the userid field.

Shown below is an abbreviated format for the attach. For more detail see the SNA Formats manual.

Byte(s)BitContent
0Length field
1x '05' (FMH Type 5)
2-3x'02FF' Attach Command Code
4Security indicator
1xxx xxxx - User id already verified
x01x xxxx - Persistent verification sign on request
x10x xxxx - Persistent verification already signed on
xxxx 1xxx - PIP following FMH5
5Length of fixed length parameters
6x'D0' (mapped conversation) x'D1' (Basic Conversation) Note: SYBASE is always mapped
7Reserved
8Sync Level
00xx xxxx - None
01xx xxxx - Confirm
10xx xxxx - Sync point
9Length of Transaction Program (TP) Name
10 (= i)i - xxxx Transaction Program Name
i + 1Length of Access Security Info Subfield (This is an optional parameter)
i + 2Length of Subfield
i + 3Subfield Type
x'00' - Profile
x'01' - Password
x'02' - User id
i + 4 - xxxx Data (This field contains the user id, password, etc as specified by the subfield type)
jLength of Logical Unit of Work ID
j + 1Length of LU Net Name
j + 2LU Net Name
kPIP Variable or GDS field beginning with the length byte
>kRefer to the SNA formats manual

For rules on FMH "conversation security support" see byte 23 of the bind request in the SNA Formats manual.

Below, is an actual example of an ATTACH.

 

TH: 033D00020033

RH: 0B9220

RU: 200502FF 0003D100 0004D7C3 E2D81108 02E9F2F7 F1D4C4F3 0701C1E2

C4C1E2C4 002112FF D7C3E2D8 D340C1C3 E3D4D9C5 E2C5E35D 40D9E3D9

4D5D40C4 C2C74DD5 5D

What follows the attach in the same frame is PIP data if present (as defined in byte 4) or a GDS ID which defines the structure for the remainder of the field. Generally what we see at the end of the attach is a GDS id that identifies the remaining data to be application data x'12FF'. This GDS id also delimits data records. We will not attempt to discuss this in any further detail (in the scope of this document). For more information on GDS IDs see the IBM publication entitled Format and Protocol Reference: Architecture Logic For LU Type 6.2.

Now lets dissect the ATTACH using the format information provided above.

 

ByteBitMeaning
0Length x'20' Decimal 32 Includes the length byte. If you count out 32 bytes you will be at the length field for the GDS ID that we discussed earlier. x'0021'
1x'05' Indicates this frame as a FMH-5
2-3x'02FF' This is the Attach Command Code
4x'00' (This breaks down to binary 0000 0000)
0Bit 0 = 0 0 indicates user id is not already verified
1 - 2Bit 1 and 2 = 00 00 indicates persistent verification not supported or needed
3Bit 3 = 0 This bit is reserved so its value has no meaning
4Bit 4 = 0 Indicates that PIP is not present in this FMH-5
5 - 7Bits 5, 6, and 7 = 000 These bits are reserved therefore their value has no meaning
5x'03' Length of fixed length parameters in binary (including this field). In the current architecture, 03 is the only allowed value for this field.
In other words bytes 5 - 8 make up the fixed length parameters.
6x'D1' Indicates that this is a Mapped Conversation (SYBASE is always Mapped)
7x'00' This field is reserved so its value has no meaning
8x'00' This breaks down to binary 0000 0000) meaning that Sync Level = None
9x'04' This indicates the length of the transaction program name.This field is 5 bytes in length 0 - 4.
10 (= i)Transaction Program Name x'D7' = P, x'C3' = C, x'E2' = S, x'D8' = Q, (PCSQ)
i + 1Length of Access Security Info Subfield x'11'
i + 2Length of Subfield x'08' Byte 0 - 8 = 9 bytes which include the length byte
i + 3x'02' Subfield Type indicates user id.
i + 4User id
x'E9' = Z, x'F2' = 2, x'F7 = 7, x'F1 - 1, x'D4' = M, x'C4' = D, x'F3' = 3 (Z271MD3)
j + 1Length of Subfield x'07' Bytes 0 - 7 = 8 bytes which include the length byte
j + 2x'01' Subfield Type indicates password
j + 3x'C1' = A, x'E2' = S, x'C4' = D, x'C1' = A, x'E2' = S, x'C4' = D, (ASDASD)
k 1 - 2x'0021' (33 bytes) Length of the data defined by the GDS ID of 12FF. More on the GDS IDs to follow.

 

In addition to the Attach described above which flows as the result of the Allocate verb, which invokes an application transaction program (PCSQ in the above example), there are attaches that flow for other reasons too. For example the LU itself can provide transaction programs to be invoked, refereed to as Service Transaction Programs. These are SNA-defined transaction programs within the LU that provide utility services to application transaction programs or that manage the LUs. In such cases these are identified by the TP name field in the Attach. There are a number of these, however two of the common Service Transaction Programs you may see are:

x'06F1' - CNOS

x'06F2' - Sync Point Resync

I will not attempt to further define any of these Service Transaction Programs because it would take a separate document in and of itself to describe. For additional information on these Service Transaction Programs refer to appendix D of the Transaction Programmers Reference Manual or see the SNA Format and Protocol Reference Manual; Architecture Logic for LU Type 6.2.

GDS Variables

 

For full connectivity among programs, transaction programs must interpret the data records the same way. To facilitate this uniform transfer of data, LU 6.2 uses what is called the General Data Stream architecture (GDS for short). The GDS variable consists of a GDS Header (LLID) followed by the data. The header contains a two byte length field (LL) followed by the GDS ID that indicates the format of the data. The length cannot exceed 32767 bytes including the length field. The length fields (LL), also serve to identify the boundaries of the data while the IDs identify the data itself. The length field, GDS ID, and the data that follows is refereed to as a Logical Record. Some common GDS IDs are listed below;

x'1210' Change Number of Sessions (CNOS)

x'1211' Change Log Name

x'1213' Compare States

x'12A0' Workstation Display Passthrough

x'12E1' Error Log

x'12E2' PIP Subfield Data

x'12F1' Null Structured Data

x'12F2' User Control Data

x'12F3' Map Name

x'12F4' Error Data

x'12F5' PIP

x'12FF' Application Data

 

There are a number of GDS IDs defined for LU6.2, for a full listing of them refer to the SNA Formats manual. In the Sybase middleware world the most common GDS ID we see is x' 12FF, which is Application Data. For example in the above Attach, you can see that the data identified as "application data" by the GDS ID x'12FF', is "PCSQL ACT(RESET) RTR() DBG(N). This data actually serves to invoke the host access server software on the host.

 

You will also see GDS IDs in transfers and selects to identify data records. Each record is preceded by the two length bytes and the GDS ID. In Sybase terminology we refer to a record as a "row" of data.

 

When this data is passed say from the host to the gateway, the communications package will look at the length byte of this application data and pass it off to the gateway. This length is reflected in the receive_wait verb as the received length. For example if the length bytes and GDS Id are as follows x'0247', the received length in the receive_wait verb will be 579. x'0247' is decimal 583. 583 minus the two length bytes and two bytes of GDS Id is 579.

For APPC test to run successfully, the host and the communications package on the LAN must be configured properly and the OS/2 machine must be able to communicate over the LAN.

 

Of the above verbs there are four that comprise the bulk of what is necessary to understand. Below is a brief description of the verbs function along with its' associated hexadecimal operational code.

MC_ALLOCATE, X' 0100' is issued by a TP to establish a conversation with a remote TP. Included with the MC_ALLOCATE are the name of the remote TP that the local TP wishes to communicate with, along with optional security information (user ID and password). When the ALLOCATE is issued it causes the logical unit to build an SNA Function Management Header Type 5 (FMH5) Attach. In an SNA trace, you will typically see the TP name, user ID, and password (password may be suppressed or encrypted) encapsulated in the SNA FMH5 record.

In Sybase gateway terms, you will typically see an MC_ALLOCATE verb when a client issues a request to be executed against the remote database. This occurs in the Net Gateway by definition and in the SYBASE Gateway and Sybase DirectConnect Gateway when the ALLOCATE parameter in the gateway is set to REQUEST. Less frequently you will see the MC_ALLOCATE verb immediately when a client connects to the gateway (if the ALLOCATE parameter is set to CONNECT on the SYBASE Database Gateway or Sybase DirectConnect gateway).

The difference in the time that the MC_ALLOCATE occurs has to do with response time and overhead concerns-if the APPC conversation begins immediately upon client connection to the gateway and remains allocated until the client disconnects (ALLOCATE on CONNECT), the end result will be faster response time (no ALLOCATE overhead for each request). The other consideration with this mode is that each client concurrently connected to the gateway will use one SNA session and one host TP (i.e. one CICS task) for the duration of the client connection, regardless of whether the client is active or not. This equates to much higher SNA and host requirements.

If the APPC conversation only allocates when a client request is issued, then an SNA session and host transaction are only active for the duration of the request. This setting is the only option on the Net Gateway and is a result of the ALLOCATE on REQUEST setting in the Database Gateway and DirectConnect Gateway. In practice the additional response time from this setting equates to approximately second-this is due to the overhead of allocating a conversation each time.

MC_SEND_DATA, X '0F00' is used to send data between two TP's involved in a conversation. MC_SEND_DATA sends one data record at a time across the protocol boundary (from the APPC TP to the logical unit). The LU puts the data record(s) in its buffer, the size of which is defined by the SNA Request Unit (RU) size. When the LU's buffer is full it is then placed in the RU of the SNA frame and sent off to its destination across the network.

From the gateway perspective, you will generally see MC_SEND_DATA in a trace when client requests are sent to the mainframe; from the mainframe perspective, you will generally see this verb when result information is returned to the client.

MC_RECEIVE_AND_WAIT, X'0B00' places the TP in receive state (if necessary), waits for information to arrive from the partner TP, and then receives the information. If in the event there is already information the buffer, it receives it immediately.

The gateway uses this verb after it has used the MC_SEND_DATA verb to issue a command to the mainframe to wait for data to be returned.

MC_DEALLOCATE, X'0500' terminates the conversation. Several actions can be performed when terminating the conversation, which are specified in the TYPE field of the verb.

 

Below is an illustration of a two-way conversation between two TP's. Between the TP and LU is the protocol boundary where the APPC protocol is passed to the SNA LU function. The LU then places the APPC verbs into SNA frames and passes them via the LU 6.2 protocol to its destination over the network.

 

Figure 7 APPC Conversation Flow

 

Setting Up An APPC Connection

Now that a basic understanding of the building blocks of an SNA and APPC connection has been achieved, it is time to apply this to a real world example. In this case, a Sybase AIX DirectConnect server running on AIX 4.2 will be connected to a CICS 2.1.2 region.

The recommended method for establishing APPC connectivity is to start with VTAM/NCP followed by CICS, with the AIX server being the last configured. The reason for this is that there are generally more constraints in the mainframe definitions (i.e. naming conventions) that are much easier to deal with on the gateway server than on the mainframe. If you can get a reasonably close set of VTAM and CICS definitions to work with, it is relatively easy to match the AIX definition to the existing parameters. Another reason is that VTAM is the most mature SNA platform in existence, and chances are that any mainframe installation has a VTAM system programmer experienced in setting up LU 6.2 connections.

VTAM Definitions

PU and LU Definition

The PU and LU are defined in a VTAM or NCP macro in a standard format that looks like this:

 

RS62COMVBUILDTYPE-SWNET
COM6000PUADDR=04(PU Name = RS62COM, Polling address=04)
IDBLK=072(ID Block=072)
IDNUM=68084(ID Number=68084)
NOTE: XID is IDBLK+IDNUM=07268084)
DISCNT=NO
PUTYPE=2(PU type 2 required)
MAXDATA=2057(Max RU size = 2048 + 9 byte header = 2057)
MAXOUT=7
USSTAB=USSTABS
SSCPFM=FSS
PASSLIM=7
PACING=7
CPNAME=SYBASCP(Control Point Name = SYBASCP)
VPACING=7
RS0ALU(LU Name = RS0A)
LOCADDR=0(LOCADDR = 0 required for parallel sessions)
DLOGMOD = SYBMCGV(Mode Name = SYBMCGV)
MODETAB = ISTINCLM
RESSCB = 10(Reserved Session Control Blocks; should be 1 per session anticipated)
LOGAPPL=CICSSIMU

 

Figure 8: VTAM PU/LU Definition

 

 

Note that there may be more than one LU defined under each PU (up to 256, in fact). The LOCADDR and DLOGMOD parameters dictate what type of LU is defined; a LOCADDR of 0 dictates an independent logical unit (ILU) and is required for parallel session support. A non-zero LOCADDR defines either a dependent logical unit or a non-LU 6.2 device (i.e. a terminal or printer). The DLOGMOD is the name of the mode entry in the mode table (MODETAB), and this mode entry must exist in this table. The mode is described in the next section.

 

MODE Definition

As described earlier in this document, the mode definition defines the characteristics of the LU to LU session. The mode (also known as the MODEENT) is defined in a mode table (known as a MODETAB), and both the MODETAB and MODEENT must be defined in the PU and/or LU definition as well. A sample mode definition follows:

SYBMCGV MODEENT LOGMODE=SYBMCGV, (Mode name = SYBMCGV)

TYPE=0,

FMPROF=X'13',

TSPROF=X'07',

PRIPROT=X'B0',

SECPROT=X'B0',

COMPROT=X'78A5',

SSNDPAC=X'05',

SRVCPAC=X'05',

RUSIZES=X'8888', (Request Unit send/receive frame size)

PSNDPAC=X'05',

PSERVIC=X'060200000000000000002F00' (See note below)

 

Figure 9: VTAM Mode Entry

 

 

Calculating RU Sizes

 

The RU size defined in the mode is calculated using the following formula:

 

RUSIZES = abcd where:

Send size = a * 2b

Receive size = c * 2d

 

For example, 8888 translates to 8*28 send and receive = 2048 bytes.

 

If you don't feel like manually calculating the RU size to determine its' size, it is very easy to memorize the RU sizes based on the values in the following table:

 

Mode Table RU Size

Actual RU Size

85

256

86

512

87

1024

88

2048

89

4096

90

8192

 

Figure 10: RU Size Chart

 

Note that the formula shown above falls apart after 89 (9*20 = 9), but the sequence continues as far as VTAM is concerned (e.g. 91 = 16384, etc).

The 'PSERVIC' Entry

The PSERVIC entry in the mode table has two very important items of note: the first 4 bytes must be 0602 for an LU 6.2 type connection, and the 21st and 22nd bytes should be "2F" in order for parallel SNA sessions to be supported (a value of 2C supports only single session whereas 2F will support single or parallel sessions).

 

APPL Definition

The APPL is the name of the MVS application as it is known to VTAM. In other words, every program running under MVS will have a unique APPL, including all CICS regions. The APPL definition defines the characteristics of the MVS application to VTAM and has several very important parameters. An example APPL definition is as follows:

CICSAPPL VBUILD TYPE=APPLAPPLICATION MAJOR NODE
*
CICSSIMU APPL AUTH=(ACQ,VPACE)(APPL ID = CICSSIMU)
PARSESS=YES(Parallel session support enabled)
SONSCIP=YES
VPACOMG=5
EAS=50
APPC=NO(No VTAM APPC support (see below)
ACBNAME=CICSSIMU
MODETAB=ISTINCLM(Mode Table (must match PU/LU))

 

Figure 11: VTAM APPL Definition

 

 

** Important Note **

One of the most common mistakes when defining an APPC connection is made when the APPC= parameter in the APPL definition is coded to YES. This will not work unless the connection uses DRDA. The reason for this is that coding APPC=YES tells VTAM to provide APPC support; when CICS is involved, CICS provides APPC support. As a result, coding APPC=NO results in VTAM trapping the APPC verbs, and since they don't get passed to CICS (where the TP resides), the connection doesn't work!

 

CICS Definitions

Once the VTAM/NCP definitions are in place, CICS definitions must be coded to match. There are two separate CICS definitions for parallel sessions: the "connection" definition and the "session" definition. The connection definition provides basic connection information to CICS: the VTAM LU that should be used, what type of protocol to use (i.e. APPC), etc. The session definition then provides more session-specific information, such as the number of sessions, contention winners, etc. The session definition also must contain the name of the associated connection definition.

The connection and session name is a 4 digit alphanumeric. The connection and session definitions are generally created in CICS using the RDO facility; the CICS transaction name for RDO is usually 'CEDA'. The status of an existing connection or session definition may be checked using the CICS CEMT transaction.

All CICS definitions exist in a CICS "group" which may contain connections, sessions, programs, transactions, and a host of other items, usually related. It is highly recommended that all gateway-related items be placed into a dedicated CICS group, which may be altered and re-installed at will without impacting other CICS applications.

CICS Connection Definition

The CICS connection definition provides the link between CICS and the VTAM LU. An example CICS connection definition is as follows. NOTE: the CEDA command used to add the connection is shown at the beginning:

CEDA ADD CONN(SMCA) GROUP(SYBCONN)

Connection : SMCA (Connection definition name)

Group : SYBCONN (CICS group)

CONNECTION IDENTIFIERS

Netname : RS0A (Must match the LU name)

INDsys :

CONNECTION PROPERTIES

Accessmethod : Vtam (Must specify Vtam)

Protocol : Appc (Must specify Appc)

Singlesess : No (Must be No for parallel session support)

Datastream : User

Recordformat : U

OPERATIONAL PROPERTIES

Autoconnect : All (Connect to all partner LU's at startup)

Inservice : Yes (Very important)

SECURITY

Securityname : CICSSIMU

Attachsec : Verify (Specifies that userid/password is verified)

 

Figure 12: CICS Connection Definition

 

 

CEDA ADD SESS(RS0A) GROUP(SYBCONN)

Sessions : RS0A (Session definition name)

Group : SYBCONN (CICS group)

SESSION IDENTIFIERS

Connection : SMCA (Must match CICS connection name)

Sessname :

Netnameq :

Modename : SYBMCGV (Must match VTAM MODEENT value)

SESSION PROPERTIES

Protocol : Appc

Maximum : 10,5 (Max # of sessions, # of CICS contention winners)

Receivepfx :

Receivecount : No

Sendpfx :

Sendcount : No

Sendsize : 2057 (RU send size + 9 bytes)

Receivesize : 2057 (RU receive size + 9 bytes)

 

Figure 13: CICS Session Definition

 

 

Gateway Server SNA Configuration

Once the VTAM and CICS definitions have been coded and checked, the gateway's SNA software must be configured to match. The biggest challenge to this process is the fact that no two versions of SNA software use the same terminology as VTAM and CICS for the same parameters!

A highly recommended document to use as an aid to configuration of the server-side SNA connection is the Sybase DirectConnect Connectivity Guide. This publication, which is constantly updated by Sybase, provides specific configuration information for all supported SNA server software. The document has a table that you fill in with the CICS and VTAM configuration values; it then walks you through the server configuration, screen by screen, specifying which field in which to enter each value.

Note that the Sybase Connectivity Guide will work for any software package that needs to make a CICS connection from a LAN-based server, including the DirectConnect, Net Gateway, and SYBASE Database Gateway products. Simply follow the instructions and replace the DirectConnect configuration parameters with that from the gateway you are planning on using. SYBASE Database Gateway users may also refer to the APPC Guidelines publication which is very similar to the Sybase Connectivity Guide but contains directions specific to the SYBASE Database Gateway. Note that Sybase is no longer updating the APPC Guidelines document-the Sybase DirectConnect Connectivity Guide is now the only supported document.

This section of the document assumes that you have the Sybase DirectConnect Connectivity Guide for the appropriate vendor and version of SNA software that you are planning on using, and will describe the process for configuration using the Sybase guide as a tool.

The following steps are recommended for configuring the gateway server SNA software in order to have the best chance of winding up with a functional link:

  1. Complete the VTAM configuration as described previously in this document;
  2. Complete the CICS configuration as previously described;
  3. Fill out the APPC configuration table that is located in the beginning of the Sybase DirectConnect Configuration Guide. This table contains codes for all of the relevant VTAM and CICS settings that you will supply to the gateway server SNA software.
  4. Locate the section in the Sybase Connectivity Guide that is applicable to the SNA software version that you are planning to use.
  5. Follow the instructions in the guide to configure your SNA software. Make sure after the configuration is complete that all SNA services have been started.

Testing the APPC Connection

Once the VTAM, CICS, and gateway server SNA software is configured, some simple tests may be performed to test the level of functionality of the APPC connection.

Testing an APPC link is comprised of several steps. First, basic SNA session-level connectivity must be tested. If the session-level connectivity is working, then it is possible to progress to actual APPC testing using a test application supplied by Sybase. Lastly, the gateway itself may be used as the "acid test" of APPC connectivity.

Testing SNA Session-Level Connectivity

Before any further testing can commence, it is a good idea to ensure that basic SNA session-level connectivity has been established. Keep in mind that since APPC relies upon SNA as the foundation upon which to carry its' conversations, verifying this connectivity is very important.

There are several ways to test base SNA connectivity; the most common ways are either to check connectivity from CICS or from the gateway server's SNA software. The easiest is generally from CICS, but both methods will be described.

Checking Session-Level Connectivity from CICS

To check SNA connectivity from CICS, log in to the region with a 3270 terminal and type the following command:

CEMT I CONN(NNNN)

Where 'NNNN' is the four alphanumeric letters that represent the CICS connection definition name. This is generally documented in the DirectConnect Connectivity Guide configuration matrix, parameter 'NNNN'. If you are not sure what this value should be, ask your CICS Systems Programmer or try the SNA test from the gateway server instead.

A successful CEMT screen will look like this:

CEMT I CONN(SMCA)

SMCA Connection Ins Acq

The key status indicators to look for in the CEMT screen are the 'Ins' and 'Acq' indicators. The 'Ins' indicates that the connection is "In Service", and the 'Acq' indicates that the connection is "Acquired." An acquired connection means that sessions have been bound between CICS and the gateway server's SNA software.

If the 'Ins' shows as 'Out', check the CICS connection definition to make sure that the 'Inservice' parameter shows 'Yes'. If the 'Acq' indicator shows a 'Rel', this is a bad sign-it indicates that no sessions are bound between CICS and the gateway server's SNA software.

** Tip: If the 'acquired' indicator shows 'Rel', you can try to 'jump start' the SNA sessions by manually starting the bind. To do this, tab over to the 'Rel' field and type an 'A' over the 'R', followed by the [Enter] key. Press [Enter] a few more times, and if the 'Rel' changes to an 'Acq', sessions have bound. If not, then refer to the troubleshooting section of this document.

Checking Session-Level Connectivity from the Gateway Server

An alternate method to checking to see if sessions are bound is to use the gateway server's SNA software. Since the method for checking this varies from package to package, it is not possible to describe the exact process for doing so, but rather to give you some hints so that you can find the screens yourself, "hacking" around if necessary.

Find the SNA software documentation for your server and look for a way to check the status of the SNA server. For example, in SNA Server on the IBM RS/6000, you select the "Display the Status of SNA" option from the 'smit' menu. You can drill down to the session level and check to see if sessions have been started; if the SNA software has been started and no sessions are bound, refer to the troubleshooting section in this document for more information.

Testing APPC Connectivity

Once you have verified that SNA session-level connectivity is established, you can attempt to allocate an APPC conversation over the link. To do so, use one of the supplied Sybase utilities for this:

  • Sybase DirectConnect or Net Gateway: SNAPING
  • SYBASE Database Gateway: APPCTEST

Both of these utilities perform the same basic test: they attempt to allocate a conversation to a transaction program (TP) in CICS using SNA configuration information that you will supply. This information is coincidentally the same type of connectivity information you need to supply to the gateway software in order for it to establish APPC connectivity.

Before you attempt either of these tests, ensure that the partner "ping" transaction has been installed into the CICS region that you are attempting to connect to. The default CICS transaction names for each test is listed below:

  • SNAPING: SYI1
  • APPCTEST: ATST

It is possible to name these transactions differently, but if at all possible try to keep the names as default. One way to check to see if the transaction has been loaded in the CICS region is to log into the region as a 3270 user and simply type the transaction ID from the CICS command line. If you don't get an 'Unidentified Transaction' type of error message, the transaction is probably installed.

Using SNAPING to Test APPC Connectivity

To invoke SNAPING, first install it on the gateway server. If you have previously loaded the Net Gateway or DirectConnect gateway software, you will probably find it in the 'bin' directory under the $SYBASE root directory. If you have not installed it, the easiest way to get it is to install the gateway software.

SNAPING is a command-line utility that takes arguments that specify the SNA connectivity parameters that it needs to establish the APPC conversation. These parameters are defined in the gateway server's SNA software and are usually as follows:

  • Local LU Alias (Side Information Profile name on AIX)
  • Partner LU Alias (Partner LU Profile Name on AIX)
  • SNA Mode Name
  • Valid host User ID and Password

Since the SNAPING command-line arguments tend to change depending on version, the safest approach is to refer to the Sybase DirectConnect Connectivity Guide for the arguments that are germane to your particular version.

Once you have entered the appropriate arguments, SNAPING will attempt to allocate an APPC conversation to the specified CICS region using the specified user ID and password. If the test is successful, a message will be printed indicating that the program was able to successfully connect to the 'SYI1' transaction and that a certain number of bytes were received. If the test was not successful, an APPC error code will be received. In the event of an error, refer to this document's "Troubleshooting" section for details on how to progress.

Using APPCTEST to Test APPC Connectivity

APPCTEST is nearly identical to SNAPING; the primary difference is that APPCTEST was distributed with the SYBASE Database Gateway. Both programs perform exactly the same test; in terms of APPC, the only difference with APPCTEST is the CICS transaction ID: ATST is used instead of SYI1. Please read the preceding section for further details on the test.

The same parameters as SNAPING are supplied to APPCTEST; refer to the APPC Guidelines document for specific details on the command line arguments required.

Troubleshooting APPC Connectivity

In establishing an APPC connection, there are many areas where mistakes may easily be made. Unfortunately, there are not that many error messages, and they are invariably generic.

The most common APPC error message is the "ALLOCATION FAILURE" message. Nearly all APPC error messages begin with this error, and its' meaning is fairly self-evident: the APPC transaction program attempted to allocate a conversation with a remote TP, and it failed. Regardless of the reason.

The good news is that there is generally an accompanying "secondary message" that contains further details on what went wrong. For instance, you may receive an error message that looks something like this:

Primary RC: AP_ALLOCATION_FAILURE_NO_RETRY

Secondary RC: AP_SECURITY_NOT_VALID

In this case, reading the secondary error message gives us a clue: security was not valid. It can be assumed at this point that the receiving CICS region's security package did not like the supplied user ID or password for a variety of reasons.

The main thing that you need to keep in mind when troubleshooting an APPC connection is that often times the first error message is very generic-the secondary return code is where the actual information lies.

In many cases, the secondary return code still does not provide adequate information. In this case, the next step is to generate an SNA trace. Once the trace has been created, knowing what to look for in terms of the logical progression of steps in a successful SNA connection will help you determine where the problem lies.

Creating an SNA Trace

There are two places where an SNA trace may be easily generated: from VTAM and from the gateway's SNA software. VTAM traces are fairly easy to obtain, as VTAM system programmers generate them frequently for troubleshooting purposes. All gateway server SNA packages have tracing facilities, although the verbiage used to describe the traces vary. The best source to refer to for information on generating the trace from the gateway is to refer to the Sybase DirectConnect Connectivity Guide. Regardless of whether you decide to take a trace from VTAM or from the gateway's SNA software, the trace is the same-one side is merely the mirror image of the other. In some cases, it is useful to take both sides of the equation to shed additional light on what step in the process a failure occurred.

An alternate method to capture SNA information is to use a network "Sniffer" or "Lanalyzer". These products are PC's that are able to monitor a network and capture LAN traffic independent of VTAM or the gateway. One of the most useful aspects to this approach is the fact that these devices usually do a spectacular job of interpreting the trace, making the job of troubleshooting that much easier.

When generating an SNA trace, keep in mind that it is possible to trace different "depths" of the connection. Recall from the OSI 7 layer model that there are multiple API's involved, all interacting with one another. The depth of trace that you take is somewhat dependent on where the anticipated problem lies; if you do not know, then start with as much tracing as you can get. Also keep in mind that the higher level API's get encapsulated inside of the lower traces; as a result, the lower level traces contain the higher level traces by definition. The main reason for generating different levels of tracing is that the SNA software may do a better job of interpreting the different API's than you will.

As mentioned previously, there are multiple levels of tracing, each generally equivalent to one or two layers in the OSI model. Typical traces that match the OSI model layers are depicted below-keep in mind that some SNA packages will use different terminology, but it's usually possible to make an educated guess based on knowledge of the OSI layers.

OSI Level SNA Component Typical SNA Trace

Physical Token Ring, Ethernet, SDLC Card N/A (Sniffer/Lanalyzer required)

Data Link Data Link Control DLC or SDLC

Network Data Link Control DLC or SDLC

Transport SNA Protocol SNA

Session APPC APPC

Presentation CPI-C CPI-C

Application Transaction Program (TP) N/A (Gateway trace)

To take an SNA trace, follow these steps:

  1. Stop the gateway's SNA processes from running.
  2. Enable to SNA trace facility (either from the gateway SNA software or from VTAM)
  3. Start the gateway SNA software
  4. Wait for a few minutes for everything to quiesce
  5. Save the SNA trace to disk

It is very important that the trace be started prior to the SNA software, as it is impossible to capture the session level bind information otherwise.

Reading an SNA Trace

Once an SNA trace has been created, the next challenge is to interpret it. Keep in mind that before an APPC conversation may take place, basic SNA session-level connectivity must be established. As a result, this section will first describe how to interpret the SNA trace in terms of basic session establishment, and will end with interpreting an APPC conversation.

The following section describes the steps that a "healthy" SNA connection takes in the process of establishing sessions, followed by an APPC conversation.

The traces that follow were taken from DCA Communications Workstation running on OS/2 communicating with VTAM and CICS. You will note that the actual hex EBCDIC bytes that were exchanged are listed in addition to the ASCII representation and the actual SNA verb for each frame. An example trace frame is shown below; remember however that traces vary from SNA package to SNA package, and your trace results will probably be different:

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

In the above trace, note that the second column has "SNA" in it; this indicates that this is an SNA level trace. The ">>SEND>>" flag indicates that the platform generating the trace sent this frame, and the SNA verb that was sent was "EXCHANGE ID". If the frame had been received from the other SNA partner, the flag would have indicated "<< RCVE <<".

The "TH" entry indicates the 6 byte transmit header and the "---- Data ----" indicates the actual EBCDIC data that was sent in the SNA Request Unit (RU). To the right of the hex data is the text interpretation of that data.

Step 1: Exchange ID (XID) Negotiation

The first step in establishing an SNA connection is for both partner PU's to identify themselves to one another to determine what type they are, followed by activation of the Physical Unit (ACTPU). The process of PU identification is known as Exchange ID (XID) negotiation. The XID carries information about the SNA PU's characteristics; if the other side has the same characteristics, the process of establishing sessions may continue with the next step.

PU Types

The PU type is coded in the VTAM PU definition under the 'PUTYPE=' parameter. In the example outlined in the beginning of the document, the PU was coded as a 'PUTYPE=2'. If the partner with which VTAM is negotiating is not a PU type 2, then the negotiation fails and the trace stops with a negative response to the "ACTPU" verb.

Recall that there are two types of PU 2: 2.0 and 2.1, which indicates whether the PU will support dependent or independent LU 6.2 sessions, respectively. Since the PU definition is only 'PUTYPE=2', this begs the question of how is it determined which specific PU type will be used (2.0 or 2.1)? The answer is that the XID negotiation process determines this depending on other parameters that have been coded.

XID Types

Before we launch into the details of the negotiation process, a bit of a historical perspective may help. XID negotiation has been around for quite a while known as an 'XID1' or 'XID2', depending on the type of device. Do not confuse the XID type with the PU type; they are different.

Starting with the concept of PU type 2 (and consequently LU 6.2), an additional XID type (XID3) was introduced to support LU 6.2 parallel sessions (PU type 2.1). Do not confuse the XID3 discussed here with the XID that is comprised of the IDBLK and IDNUM parameter in the PU definition; that is the XID2 and is used so that the PU can identify itself to the Front End Processors' Network Control Program (NCP). In addition to the PUTYPE parameter in the PU, the 'XID=YES' parameter specifies that an XID3 negotiation will take place. Note that XID=YES is the default, and as such it need not be coded in the PU definition.

XID Negotiation

When VTAM issues an ACTPU command to the NCP for this node, XID=YES tells the NCP to contact the node by first sending a "null" XID3 command . If the PU responds to the XID3, VTAM considers it to be a PU type 2.1, and otherwise it assumes it to be a type 2.0. Note that while the ACTPU command technically is issued first, the XID negotiation occurs first in the trace, followed by the ACTPU.

After receiving the response, NCP sends another XID command which contains a number of values, some of which are defined on the PU definition statement (i.e. the control point name). This process is referred to as XID3 negotiation. If the partner PU responds negatively to the "null" XID the NCP will issue an ACTPU and consider the PU to be a Type 2.0.

When you look at the trace below the first item you will see is VTAM sending a "null" XID3 (Trace 1) to the device. The PU responds (Trace 2) and several XID3 frames are exchanged. You will then typically see a number of exchanges before the XID3 negotiation is completed (Trace 3). . Note in the response frames that the Net ID ("DCA MS COMM WKSTA" and "UUNET") for both partners and the PU name ("SPU602" and "PU633" ) are passed back and forth.

Trace 1: NULL XID3 Exchange

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

Trace 2: Positive XID3 Response

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

Trace 3: Remaining XID Negotiation

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

|

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0080000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 3478FFFF FFFD0000 10884000 00000000 <4x.......h@.....>

| 25.01 SNA 00010B10 00135A00 00000007 000E0EF4 <......Z........4>

| 25.01 SNA E4E4D5C5 E34BE4E3 C1C8D9C5 E20E08F1 <UUNETKUTAHRES..1>

| 25.01 SNA E2C1F6D5 C3D7C10E 06F7D7E4 F6F3F310 <SA6NCPA..7PU633.>

| 25.01 SNA 37001611 01130011 F3F7F2F5 F0F0F0F0 <7.......37250000>

| 25.01 SNA F0F0F0F0 F7F2F3F8 2011040E 02F5F6F6 <00007238 ....566>

| 25.01 SNA F8F8F5F4 F0F1F3F1 F00804F0 F4F0F3F0 <885401310..04030>

| 25.01 SNA F1070992 01631216 <1..k.c.. >

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0040000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 3478FFFF FFFD0000 10844000 00000000 <4x.......d@.....>

| 25.01 SNA 00010B10 00135A00 00000007 000E0EF4 <......Z........4>

| 25.01 SNA E4E4D5C5 E34BE4E3 C1C8D9C5 E20E08F1 <UUNETKUTAHRES..1>

| 25.01 SNA E2C1F6D5 C3D7C10E 06F7D7E4 F6F3F310 <SA6NCPA..7PU633.>

| 25.01 SNA 37001611 01130011 F3F7F2F5 F0F0F0F0 <7.......37250000>

| 25.01 SNA F0F0F0F0 F7F2F3F8 2011040E 02F5F6F6 <00007238 ....566>

| 25.01 SNA F8F8F5F4 F0F1F3F1 F00804F0 F4F0F3F0 <885401310..04030>

| 25.01 SNA F1070992 01631216 <1..k.c.. >

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 0d0000000200

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0040000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

| 25.01 SNA <<RCVE<< EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 3478FFFF FFFD0000 10844000 00000000 <4x.......d@.....>

| 25.01 SNA 00010B10 00135A00 00000007 000E0EF4 <......Z........4>

| 25.01 SNA E4E4D5C5 E34BE4E3 C1C8D9C5 E20E08F1 <UUNETKUTAHRES..1>

| 25.01 SNA E2C1F6D5 C3D7C10E 06F7D7E4 F6F3F310 <SA6NCPA..7PU633.>

| 25.01 SNA 37001611 01130011 F3F7F2F5 F0F0F0F0 <7.......37250000>

| 25.01 SNA F0F0F0F0 F7F2F3F8 2011040E 02F5F6F6 <00007238 ....566>

| 25.01 SNA F8F8F5F4 F0F1F3F1 F00804F0 F4F0F3F0 <885401310..04030>

| 25.01 SNA F1070992 01631216 <1..k.c.. >

 

| 25.01 SNA >>SEND>> EXCHANGE ID

| 25.01 SNA

| 25.01 SNA TH: 000000000000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 326305D3 27030000 B0040000 00000000 <2c.L'...........>

| 25.01 SNA 00010B00 00010900 00000007 00103B00 <..............;.>

| 25.01 SNA 27110C08 04F0F1F0 F1F0F013 06C4C3C1 <'....010100..DCA>

| 25.01 SNA 61D4E240 C3D6D4D4 40E6D2E2 E3C10908 <aMS@COMM@WKSTA..>

| 25.01 SNA F0F0F0F0 F0F0F013 11031000 10F0F0F0 <0000000......000>

| 25.01 SNA F0F0F0F0 F0F0F0F0 F0F00E07 F4E2D7E4 <0000000000..4SPU>

| 25.01 SNA F6F0F2 <602 >

 

End of XID Negotiation

As mentioned above, the XID3 is used for other things besides merely a means by which the PU identifies itself as a type 2.1. The format of the XID3 contains a number of fields that specify a variety of characteristics; for example, the link station role, I-frame size, and node id.

The value of the node Id is of some interest because the higher value indicates who will be the winner of the negotiation. The node id is represented by bytes 2-5 of the XID. In this example the value for these bytes from the host are FFFFFFFD, and the value coming from the server communications subsystem is 05D32703. The highest value indicates the winner of the negotiation. In this example the host won the negotiation. The fields in the XID3 format provide negotiable values for what were static parameters in previous versions of the XID. For example, several parameters on the PU definition statement, i.e. MAXDATA, MAXOUT, MODULO, and DATMODE, are used during the initial contact but are subject to negotiation by the PU. For a detailed breakdown of the XID3, refer to IBM's SNA formats manual.

Step 2: Activate Physical Unit (ACTPU)

After a successful XID3 negotiation, the next step is an ACTPU ("Activate PU") exchange. In this trace example, after the XID exchange, NCP sends an ACTPU, which is then followed by a positive response sent by the gateway server SNA software (Trace 4).

Note in the traces that a code of "+RSP" indicates a positive response, and a "-RSP" indicates a negative response.

Trace 4: ACTPU Request and ACTPU Positive Response

| 25.01 SNA <<RCVE<< DAF:00 OAF:00 ODAI:OFF Expedited

| 25.01 SNA ACTPU RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000000d6e

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 11020105 00000000 05 <......... >

 

| 25.01 SNA >>SEND>> DAF:00 OAF:00 ODAI:OFF Expedited

| 25.01 SNA ACTPU +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000000d6e

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 11114040 40404040 40400000 07010000 <..@@@@@@@@......>

| 25.01 SNA 00000000 <.... >

 

Step 3: Activate Logical Unit (ACTLU)

Once the PU has been activated with an ACTPU verb, VTAM/NCP can activate the LU's on the PU. In the example there are four LU's defined. For clarification an example of VTAM's LU definition statement for this PU follows:

SLU602A LU LOCADDR=0, DLOGMOD=LU62, RESSCB=20

SLU6020 LU LOCADDR=3, DLOGMOD=S3180M2

SLU6021 LU LOCADDR=4, DLOGMOD=S3180M2

SLU6022 LU LOCADDR=5, DLOGMOD=S3180M2

 

Figure 14: VTAM LU Definitions

In this trace example you will see NCP attempt to activate all 4 of the LU's. Note that it is not a requirement to have all 4 LU's defined on the gateway's SNA server-only 1 is required in order to bind sessions and conduct an APPC conversation.

One very important note, however: only the first LU defined above is capable of supporting parallel sessions, as it is the only entry with a LOCADDR of zero. In fact, if you were to examine the MODE entry for the other LU's (S3180M2), you would discover that these LU's are in fact 3270 LU2 devices. This entry illustrates that it is possible to mix different LU types within a PU-in fact, it is possible to have up to 256 different LU's within a single PU. Non-zero LOCADDR=0 entries must be unique in the PU definition, but multiple LOCADDR=0 entries may exist providing the LU names are unique.

It is in fact a common practice to code multiple LU's this way-in this example, not only can this PU be used for LU 6.2 type traffic, but for 3270 terminals as well. This is extremely useful, as it makes it possible to start a 3270 session to the host from the gateway server platform rather than having to try to find a terminal should the need arise to sign on to the host (and it will!).

The following trace frame is the ACTLU for LU 03 which is a LU Type 2 (3270) that is found in the same VTAM LU definition with the parallel session LU. You know which LU it is by looking at the destination address field (DAF) in the Transmission Header. In this example it is x'03' which is LU LOCADDR 03 in VTAM's LU definition statement.

Trace 5: ACTLU

| 25.01 SNA <<RCVE<< DAF:03 OAF:00 ODAI:OFF Expedited

| 25.01 SNA ACTLU RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0003000d6f

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D0201 <... >

 

Note that it is normal to see a separate ACTLU request from NCP for each LU defined in the PU. In the example LU definitions found in figure 13, you would normally see a separate ACTLU request for each of the four LU's defined. It is not necessary for all four LU's to have positive responses in order for communications to continue. In this case, a positive response to the SLU602A logical unit would be required in order for APPC/LU6.2 communications to commence, as it is the only independent logical unit coded (LOCADDR=0). Note that the positive response frame (with the '+RSP') is not shown in this trace, but it is implied.

Step 4: Binding SNASVCMG Sessions between LU's

This is a significant point in the trace, as the communications between PU's and LU's have been established. Next, the two partners will begin "binding" sessions between the LU's. Before any user data may flow between LU's, one or two "housekeeper" session(s) must be established. These housekeepers are known by their mode name: SNASVCMG (SNA Service Manager). These sessions are responsible for carrying all of the session management information for the user sessions, including session bind and negotiation information.

At this point in the trace the server communications subsystem sends the host a bind request to request a session with mode SNASVCMG. Note that the bind may be detected in a couple of different ways: by the keyword "BIND" in the trace as well as by the '3100' code in the first 4 bytes of the data block.

In addition to the bind request, several negotiated parameters are passed in the bind request. One of the more significant items is the send and received request unit (RU) size, which governs the packet size that will be exchanged across the session. Note that these sizes are shown in the data block, bytes 11 and 12. In this example, the server is requesting a send and receive size of '8585', which indicates 256 bytes.

Recall that the formula for translating the hexadecimal RU size to decimal is as follows: hexadecimal 'ab' = decimal a x 2b (256 = 8 * 25). Note that while this formula falls apart after '89' (4096), the values continue on; for example, hexadecimal '90' equals 8192, 91 equals 16384, etc.

Trace 6: Bind Request for mode SNASVCMG

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON Expedited

| 25.01 SNA BIND RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0000020000

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B1 01018585 81010602 <1.....P...eea...>

| 25.01 SNA 00000000 00000010 2300000D E4E4D5C5 <........#...UUNE>

| 25.01 SNA E34BE2D3 E4F6F0F2 C1240009 02E2D5C1 <TKSLU602A$...SNA>

| 25.01 SNA E2E5C3D4 C70903F0 00000000 0000010E <SVCMG..0........>

| 25.01 SNA 04E4E4D5 C5E34BE2 D3E4F6F0 F2C1000E <.UUNETKSLU602A..>

| 25.01 SNA E4E4D5C5 E34BC3C9 C3E2F5C4 E6E3 <UUNETKCICS5DWT >

 

 

Trace 7: Receive ACTLU to 04

Note that many of the events in an SNA trace occur asynchronously. In other words, one partner may be requesting a bind of the SNASVCMG session (as witnessed in trace 6), while the other partner (NCP, in this case) is passing an ACTLU request, in this case for LOCADDR number 4.

| 25.01 SNA ---------------------------------------------- 10:08:36.84

| 25.01 SNA <<RCVE<< DAF:04 OAF:00 ODAI:OFF Expedited

| 25.01 SNA ACTLU RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0004000d70

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D0201 <... >

| 25.01 SNA ---------------------------------------------- 10:08:37.03

 

Trace 8: Positive Response to ACTLU 03

| 25.01 SNA ---------------------------------------------- 10:08:37.03

| 25.01 SNA >>SEND>> DAF:00 OAF:03 ODAI:OFF Expedited

| 25.01 SNA ACTLU +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000030d6f

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D020100 85800000 0C060100 01000000 <....e...........>

| 25.01 SNA ---------------------------------------------- 10:08:37.25

 

Trace 9: Notify

| 25.01 SNA >>SEND>> DAF:00 OAF:03 ODAI:OFF

| 25.01 SNA NOTIFY RQD FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0000030000

| 25.01 SNA RH: 0b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 8106200C 06010001 000000 <a. ........ >

 

Trace 10: Receive ACTLU for LU 05

| 25.01 SNA <<RCVE<< DAF:05 OAF:00 ODAI:OFF Expedited

| 25.01 SNA ACTLU RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0005000d71

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D0201 <... >

 

Trace 11: Send Positive Response to ACTLU 04

| 25.01 SNA >>SEND>> DAF:00 OAF:04 ODAI:OFF Expedited

| 25.01 SNA ACTLU +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000040d70

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D020100 85800000 0C060100 01000000 <....e...........>

 

Trace 12: Send Notify for LU 04

| 25.01 SNA >>SEND>> DAF:00 OAF:04 ODAI:OFF

| 25.01 SNA NOTIFY RQD FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0000040000

| 25.01 SNA RH: 0b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 8106200C 06010001 000000 <a. ........ >

 

Trace 13: Positive Response to Bind request for mode SNASVCMG

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON Expedited

| 25.01 SNA BIND +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0002000000

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B1 01018585 81010602 <1.....P...eea...>

| 25.01 SNA 00000000 00000010 23000000 25000902 <........#...%...>

| 25.01 SNA E2D5C1E2 E5C3D4C7 0903F000 00000000 <SNASVCMG..0.....>

| 25.01 SNA 00010F05 E4E4D5C5 E34BC3C9 C3E2F5C4 <....UUNETKCICS5D>

| 25.01 SNA E6E30000 <WT.. >

 

At this point the first successful session with mode SNASVCMG is established. One SNASVCMG session, however in not enough-a second SNASVCMG session must be established next.

Trace 14: Positive Response to ACTLU 05

| 25.01 SNA >>SEND>> DAF:00 OAF:05 ODAI:OFF Expedited

| 25.01 SNA ACTLU +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000050d71

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D020100 85800000 0C060100 01000000 <....e...........>

 

Trace 15: Notify sent for LU 05

| 25.01 SNA >>SEND>> DAF:00 OAF:05 ODAI:OFF

| 25.01 SNA NOTIFY RQD FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0000050000

| 25.01 SNA RH: 0b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 8106200C 06010001 000000 <a. ........ >

 

Trace 16: Positive Response to Notify for 03 and 04

| 25.01 SNA <<RCVE<< DAF:03 OAF:00 ODAI:OFF

| 25.01 SNA NOTIFY +RSP FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0003000000

| 25.01 SNA RH: 8b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 810620 <a. >

 

| 25.01 SNA <<RCVE<< DAF:04 OAF:00 ODAI:OFF

| 25.01 SNA NOTIFY +RSP FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0004000000

| 25.01 SNA RH: 8b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 810620 <a. >

 

Trace 17:

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON

| 25.01 SNA RQE FMD FI BC DR1 PI

| 25.01 SNA

| 25.01 SNA TH: 2e0000020001

| 25.01 SNA RH: 0a9100

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 0D0502FF 0003D000 000206F1 00 <...........1. >

 

Trace 18: Positive Response to Notify for 05

| 25.01 SNA <<RCVE<< DAF:05 OAF:00 ODAI:OFF

| 25.01 SNA NOTIFY +RSP FMD FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2c0005000000

| 25.01 SNA RH: 8b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 810620 <a. >

 

Trace 19: Pacing Response

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Step 5: CNOS Negotiation

If you recall our discussion above on CNOS, once the initial SNASVCMG sessions are established the two LU's negotiate the number of sessions using CNOS (Change Number Of Sessions) negotiation.

In this trace, CNOS is not explicitly indicated so it is necessary to find it by looking at the 'Data' frame, bytes 3 and 4. These two bytes are known as the GDS variable, and CNOS is indicated by a GDS value of 1210. The maximum number of sessions is 254 indicated by hex 'FE' indicated in byte 11. The maximum number of contention winners are 127 (hex 7F) and the maximum number of contention losers is 127 (hex 7F), indicated in bytes 13 and 15 respectively.

Remember that since this trace was taken from the gateway SNA software package, the contention winners and losers indicated are from the gateway perspective. A copy of the VTAM trace would show the same type of response except that the VTAM contention winners and losers translate into gateway SNA contention losers and winners, respectively.

Trace 20: CNOS Negotiation Initiation

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON

| 25.01 SNA RQE FMD EC DR1 PI CD

| 25.01 SNA

| 25.01 SNA TH: 2e0000020002

| 25.01 SNA RH: 019120

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 00191210 02000000 0000FE00 7F007F00 <..............>

| 25.01 SNA 08D3E4F6 F2404040 40 <.LU62@@@@ >

 

Below is the bind request from VTAM requesting the second session with mode SNASVCMG.

Trace 21: Receive Bind Request from VTAM for mode SNASVCMG

| 25.01 SNA <<RCVE<< DAF:00 OAF:02 ODAI:OFF Expedited

| 25.01 SNA BIND RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0000020d73

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B3 00808585 80000602 <1.....P...ee....>

| 25.01 SNA 00000000 00000010 4F00000E E4E4D5C5 <........O...UUNE>

| 25.01 SNA E34BC3C9 C3E2F5C4 E6E32500 0902E2D5 <TKCICS5DWT%...SN>

| 25.01 SNA C1E2E5C3 D4C70903 0021784B 606EAD03 <ASVCMG...!xK`n..>

| 25.01 SNA 0F04E4E4 D5C5E34B C3C9C3E2 F5C4E6E3 <..UUNETKCICS5DWT>

| 25.01 SNA 000DE4E4 D5C5E34B E2D3E4F6 F0F2C160 <..UUNETKSLU602A`>

| 25.01 SNA 16DF934A A616063A A00DE4E4 D5C5E34B <..lJw..:..UUNETK>

| 25.01 SNA E4E3C1C8 D9C5E22C 0A010840 40404040 <UTAHRES,...@@@@@>

| 25.01 SNA 404040 <@@@ >

 

Trace 22: Pacing Response

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Trace 23: Positive Response for Bind for mode SNASVCMG

| 25.01 SNA >>SEND>> DAF:02 OAF:00 ODAI:OFF Expedited

| 25.01 SNA BIND +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2d0002000d73

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B3 00018585 81000602 <1.....P...eea...>

| 25.01 SNA 00000000 00000010 23000000 24000902 <........#...$...>

| 25.01 SNA E2D5C1E2 E5C3D4C7 09030021 784B606E <SNASVCMG...!xK`n>

| 25.01 SNA AD030E05 E4E4D5C5 E34BE2D3 E4F6F0F2 <....UUNETKSLU602>

| 25.01 SNA C100 <A. >

 

At this point we have reached a milestone in the trace analysis. To recap, NCP recognizes this node as a PU type 2.1 and has activated it. NCP has attempted to activate the LU2 sessions, but as you will see later in the trace, they were unavailable when the communications subsystem was started, and it will send DACTLUs for the LU type 2's. The parallel session (LU6.2) is active and the two required sessions with SNASVCMG are active. After this point you should expect to see CNOS wherein the CNOS exchange negotiates the number of sessions. Below you will see the first CNOS exchange. At this point there are now the two required sessions with mode SNASVCMG.

Trace 24: CNOS Response

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA RQE FMD BC EC DR1 PI CEB

| 25.01 SNA

| 25.01 SNA TH: 2e0002000001

| 25.01 SNA RH: 039101

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 00191210 0A040000 00000800 00000000 <................>

| 25.01 SNA 08D3E4F6 F2404040 40 <.LU62@@@@ >

 

Trace 25: Pacing Response

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2e0000020000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Trace 25: LUSTAT

| 25.01 SNA <<RCVE<< DAF:00 OAF:02 ODAI:OFF

| 25.01 SNA LUSTAT RQE DFC FI BC EC DR1 PI CEB

| 25.01 SNA

| 25.01 SNA TH: 2c0000020001

| 25.01 SNA RH: 4b9101

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 04000600 00 <..... >

 

Trace 26: Pacing Response

| 25.01 SNA >>SEND>> DAF:02 OAF:00 ODAI:OFF

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2c0002000000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Trace 27: BIS

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON

| 25.01 SNA BIS RQE DFC FI BC EC DR1 PI

| 25.01 SNA

| 25.01 SNA TH: 2e0000020003

| 25.01 SNA RH: 4b9100

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 70 <p >

 

Trace 28: Pacing Response

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Trace 29: Positive Response to BIS

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA BIS RQE DFC FI BC EC DR1 DR2 PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000002

| 25.01 SNA RH: 4bb100

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 70 <p >

 

Trace 30: Unbind

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON Expedited

| 25.01 SNA UNBIND RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0000020031

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 3201 <2. >

 

Trace 31: Positive Response to Unbind

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON Expedited

| 25.01 SNA UNBIND +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0002000031

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 32 <2 >

 

 

This is another milestone in the trace analysis. At this point the server communications subsystem is requesting a session with mode LU62. Recall earlier that LU6.2 sessions are established with modes. Only one session with mode LU62 is required for APPCTEST, DGTEST, or SNAPING to work successfully. In this case it's APPCTEST. Remember this mode is the one that was defined in the communications configuration and has to match the name of VTAM's MODEENT.

Another area to note in the trace below; the server is requesting a higher RU size (8787, or 1024 send and receive, respectively). Also note the negotiated RU size of 256 (8585) in the bind response frame (33). This indicates that the CICS region's session definition has been set to 265 (256 plus the 9 byte header), and both partners therefore negotiate down to the lowest value.

Trace 32: Bind Request for Mode LU62

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON Expedited

| 25.01 SNA BIND RQD SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0000020000

| 25.01 SNA RH: 6b8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B1 08088787 88080602 <1.....P...ggh...>

| 25.01 SNA 00000000 00000010 2300000D E4E4D5C5 <........#...UUNE>

| 25.01 SNA E34BE2D3 E4F6F0F2 C1240009 02D3E4F6 <TKSLU602A$...LU6>

| 25.01 SNA F2404040 400903F0 00000000 0000020E <2@@@@..0........>

| 25.01 SNA 04E4E4D5 C5E34BE2 D3E4F6F0 F2C1000E <.UUNETKSLU602A..>

| 25.01 SNA E4E4D5C5 E34BC3C9 C3E2F5C4 E6E3 <UUNETKCICS5DWT >

 

Trace 33: Positive Response to Bind Request for Mode LU62

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON Expedited

| 25.01 SNA BIND +RSP SC FI BC EC DR1

| 25.01 SNA

| 25.01 SNA TH: 2f0002000000

| 25.01 SNA RH: eb8000

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 31001307 B0B050B1 08038585 83080602 <1.....P...eec...>

| 25.01 SNA 00000000 00000010 23000000 21000502 <........#...!...>

| 25.01 SNA D3E4F6F2 0903F000 00000000 00020F05 <LU62..0.........>

| 25.01 SNA E4E4D5C5 E34BC3C9 C3E2F5C4 E6E30000 <UUNETKCICS5DWT..>

 

Step 6: APPC Conversation Initiation

At this point, the SNA portion of the trace is complete and we begin to see an APPC conversation flowing. The program used to initiate the conversation in this trace was the APPCTEST utility, which does a simple allocate, exchanges a message with the remote transaction program (TP), and then terminates.

The gateway SNA software takes input from APPCTEST via CPI-C verbs and builds an ALLOCATE (conversation) verb. The ALLOCATE verb is passed to the communications package, which then encapsulates it into an SNA ATTACH request which we will see in a following frame in the trace.

Remember that we are now dealing at an entirely different level in the OSI model-up to this point, we have been dealing with SNA related negotiation and establishment, which occurs at the Transport layer in the model. The APPC conversation exists in the Session layer, which "flows" across the transport layer. The Transaction Programs (TP's), in this case APPCTEST on the server and ATST in CICS, are dealing at an even higher level using the CPIC API-the Presentation and Applications layers.

Trace 34: APPC ATTACH Request

| 25.01 SNA >>SEND>> DAF:00 OAF:02 ODAI:ON

| 25.01 SNA RQE FMD FI BC EC DR1 PI CD

| 25.01 SNA

| 25.01 SNA TH: 2e0000020001

| 25.01 SNA RH: 0b9120

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 200502FF 0003D100 0004C1E3 E2E31107 < .....J...ATST..>

| 25.01 SNA 02C4E6D4 C3F0F308 01C3D3E4 C4E6C9C7 <.DWMC03..CLUDWIG>

| 25.01 SNA 001D12FF D6E200F2 00A39600 C3C9C3E2 <....OS.2.to.CICS>

| 25.01 SNA 00A385A2 A3009485 A2A28187 85 <.test.message >

 

Make note that in the ATTACH you can verify that the correct transaction(ATST) is being invoked and that the User Id being passed is what was typed in from the screen, in this case "DWMC03". The password is also displayed in the trace "CLUDWIG" in this example. These are identified by the x'02' and x'01' subfields respectively. Also note that the application data being passed to the host is "OS 2 to CICS test message".

After the session with mode LU62 was established, a conversation can take place over that session. The ATTACH request established an LU62 conversation. In the following frame (Trace 36) note the other TP stating that the userid was found and hence the APPCTEST worked. The GDS variable (x'12FF') indicates that this is application data.

Trace 35: Pacing Response

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA +RSP FMD BC EC PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000000

| 25.01 SNA RH: 830100

| 25.01 SNA

 

Trace 36: LU 6.2 Application Data (response from ATST transaction)

| 25.01 SNA <<RCVE<< DAF:02 OAF:00 ODAI:ON

| 25.01 SNA RQE FMD BC DR1 PI

| 25.01 SNA

| 25.01 SNA TH: 2e0002000001

| 25.01 SNA RH: 029100

| 25.01 SNA

| 25.01 SNA ---- Data ----

| 25.01 SNA 004112FF C1D7D7C3 40C3D6D5 E5C5D9E2 <.A..APPC@CONVERS>

| 25.01 SNA C1E3C9D6 D540C5E2 E3C1C2D3 C9E2C8C5 <ATION@ESTABLISHE>

| 25.01 SNA C44B40E4 E2C5D9C9 C440C6D6 E4D5C44B <DK@USERID@FOUNDK>

| 25.01 SNA 40404040 40404040 40404040 40404040 <@@@@@@@@@@@@@@@@>

| 25.01 SNA 02 <. >

 

SNA Tracing Conclusion

Even though the preceding trace involved a particular SNA definition over a dial-up connection, the same basic events occur regardless of the configuration details:

  • XID Exchange
  • ACTPU
  • Two initial sessions with SNASVCMG must be established
  • CNOS Negotiation
  • At least one session with the mode defined in VTAM
  • An ATTACH to begin an LU6.2 conversation

We have spent a significant amount of time now discussing an overview of LU6.2, its components, and data flow. An understanding of the events that must happen for a LU6.2 link to be successful is critical before one can troubleshoot an LU6.2 problem. Knowing what events must take place and in what order will help you to define and isolate the problem.

 

Common SNA Problems and Solutions

Below are some scenarios of potential problems that could be encountered when using the Sybase gateway products along with some tips on what to check and/or where or what you might look to resolve the problem.

Problem

  • Any type of ALLOCATE error from the gateway
  • A trace shows no SNA activity at all.

 

Things To Check

  • Verify that the proper levels of NCP/VTAM and CICS are installed for LU6.2 Support.
  • The server machine might not be communicating on the LAN.
  • Verify that you can get to other resources on the LAN from the server machine.
  • The address of the Token Ring Card may be incorrect.
  • If you gateway is token ring attached to a 3174, verify the 3174 configured properly to talk to the server machine.
  • Try to establish a 3270 terminal session from that device to the host. This assures that basic physical connectivity is established.
  • For dial-up or leased line connections check modems, modem eliminators, cables, etc.
  • For dial-up or leased line connections put a data scope between the SDLC card in the server machine and the modem. Are you being polled? Do you see any data? Is the server's SNA subsystem responding to the poll? If it is not it may be installed improperly or configured wrong. Check the configuration. Perhaps the SDLC card is bad. If the gateway's SNA subsystem is not being polled check VTAM's configuration.
  • Do the PU addresses match?
  • If the gateway is token ring (TIC) attached, put a Sniffer on the LAN and check to see if that TIC card is receiving any packets. If it is, is the card responding to the packets?

 

Problem

  • The 1st bind request sent by the gateway's communications subsystem for a session with SNASVCMG, results in an error, or the trace ends abruptly after that bind request with mode SNASVCMG. It may be that an UNBIND is received or the gateway SNA subsystem sends back SNA Sense Data.

 

Things to Check

  • Check to see if the XID flowed before the ACTPU. If the XID3 flow did not occur, VTAM may think this is a TYPE 2 PU and thus would not recognize any incoming bind request, particularly one for SNASVCMG.
  • Verify CICS Sit table entries for TCP and ZCP and ISC are coded. Code the TCP and ZCP with the suffix S$, which is required for LU Type 6.2 nodes. While your in the SIT verify that ISC=Yes. This is also required.
  • Make sure RESSCB is coded in VTAM's LU definition statement. This ensures that adequate VTAM buffer pool space is reserved for your sessions; the general rule is that RESSCB should equal the maximum number of SNA sessions you are planning to use.
  • Verify that the SNASVCMG mode entry is in VTAM's default log mode table.
  • Verify that the LU address in VTAM (LOCADDR) and in the OS\2 communications subsystem is x'00'.
  • Check to see if the UNBIND is carrying any sense data. Check the Sense Data with the SNA Formats manual for the actual meaning.

 

Problem

  • One SNASVCMG session is established successfully. However the bind request with mode SNASVCMG which was sent from the host is responded to negatively by the OS\2 communications subsystem. Trace ends, or Sense Data may be returned to the host. This problem is rare, because if the OS\2 communications subsystem is configured in such a way that it knows it is to send a bind request for mode SNASVCMG to the host, it should be capable of accepting a bind from the host for SNASVCMG.

 

Things to Check

  • Check the configuration to verify that the partner LU session limit is set to something other than 1 (this is generally found in the CICS session definition and the gateway SNA subsystem MODE definition).
  • Verify that the VTAM LOCADDR is 00 and that the LU number on the gateway's SNA software is also set to 0.
  • Look up the Sense Data code in the SNA Formats manual.

 

Problem

  • Both SNASVCMG sessions are established, but no CNOS requests flow. Possible sense data of 0805.

 

Things to Check

  • Try coding AUTOCONNECT=YES in CICS connections and sessions definitions.
  • There is a known problem with CNOS negotiation in VTAM 3.4 and various gateway SNA packages; contact IBM and check into a possible VTAM APAR to fix the problem.
  • Ensure that the gateway's SNA maximum number of sessions and contention winners/losers match up with the CICS session definition maximum sessions and contention winners. If the values match exactly, less CNOS negotiation is required.
  • Try setting contention winners and losers equal to exactly half of the maximum number of sessions both on the gateway's SNA software as well as in the CICS session definition.

 

Problem

  • CNOS Negotiation error. Session negotiation failed, or other similar messages. You might possibly see this when migrating from single to parallel sessions.

 

Things to Check

  • Check the MAXSESS parameter in CICS to verify that there are an adequate number of sessions coded.
  • Verify that FEATURE=PARALLEL.
  • Ensure that the VTAM LU's LOCADDR=00.
  • Verify that the VTAM SNASVCMG mode entry is coded.

 

Problem

  • Sessions are not getting established with CICS. Running a trace you might see the following;

====> Receive Bind Request x'31'

<==== Send Bind Response x'31'

====> Receive LU STAT x'04000600'

 

Things to Check

  • If the problem appears as though CICS does not want to negotiate the bind or accept the bind request with modified parameters, double check the CICS SIT table for the TCP and ZCP parameters. These need to be coded with the S$ suffix to support LU Type 6.2 nodes. This problem has been observed when the TCP and ZCP were coded with E$ which is for LU Type 2 nodes.

 

Problem

  • Security error has occurred

 

Things to Check

  • Verify that the ATTACHSEC parameter in the CICS connection definition is set to VERIFY. This ensures that both user ID and password are sent to the MVS security package for validation.
  • If ACF2 5.2 is in use, verify that UM 87688 has been applied. This is required for APPC conversation security to work.

 

Problem

  • SECG ABEND received when an APPC conversation attempts to allocate

 

Things to Check

  • This abend occurs when ACF2 is the security package. You will get an SECG ABEND if a user provide an incorrect userid or password. This is ACF2's way of informing you that someone entered an incorrect userid or password. Putting the transaction ATST or PCSQ in ACF2's safe list will make the abend go away, however in the case where a bad userid was entered, ACF2 will assign its default CICS userid. This userid will eventually get passed to DB2 and you will most likely receive a DB2 SQL return code.

 

SNA Sense Data Errors

Sense data errors can be seen from either an SNA trace taken from the gateway's SNA communications subsystem or a VTAM trace. In either case you generally see sense data as a result of a negative response with the SDI bit set. If this is the case look for the sense code in the RU for that frame. Sense codes may also be in function management headers. Looking up the specific sense code up in the SNA Formats manual will in many cases "point" you in a specific direction to resolve the problem.

 

 

081C0000

Seen with VTAM V3R2. VTAM shows PU and LU as active but cannot get into CICS. In the VTAM APPL for CICS, APPC should be coded for NO.

 

08120006

Seen when migrating from single to parallel sessions. Verify VTAM's VBUILD to assure that NUMILU is coded for LUDRPOOL NUMILU stands for "Number of Independent Logical Units". Independent logical units are required for parallel sessions.

 

0835001B

Above sense code happens on a bind from an independent logical unit to an application using USERVARS. This is a VTAM issue. Details regarding the required APAR's are described in IBM's Info/System record id E341733 entitled "SENSE 0835001B ON BIND FROM INDEPENDENT LUS TO APPL USING USERVAR R82."

 

08210002

This was encountered when the mode name specified in the gateway's SNA subsystem was in fact the name of the Mode Table, not the Mode Entry. In this case verify that the correct mode name is being configured in the communications subsystem.

 

08090000

If the following error appears in VTAM's syslog "BFINIT request from xxxx failed with sense=08090000" you may want to check that APPC=NO is coded in the VTAM APPL for CICS. A trace may show sense data of 080C0005.

 

080F60F1

If you see this sense data in a trace returned in a FMH Type 7 with a DFH2024I and a message that says "Invalid Security Requested By System xxx Sense Code 080F60F1", you need some assistance from the vendor that supports your security package.

 

080F6051

If this is returned on a FMH Type 7 along with a DFH2033, verify that the CICS PCT table has TRANSEC=1 and not some other number. This was seen with ACF2 as the security package.

 

08640000

Commonly seen with an accompanying CICS DFH2206. The first connection through the gateway works fine but the second one results in the above error. This was seen when Top Secret was the security package. There are a number of fixes available from CA that addresses this issue.

 

0805000B

Seen when migrating from single to parallel sessions. Verify the VTAM parameters are defined properly for parallel sessions. i.e.: Locaddr=00, XID=YES, RESSCB=XX, etc.

 

80070001

This error point to a possible segmenting problem, APPC does not support segmenting. Verify that the Send and Receive sizes configured in CICS match the RU sizes configured in VTAM.

 

8005

This sense data indicates that no half session is active. This problem was seen with V3R2 of VTAM. There are some APAR's available for this, they are for MVSXA APAR OY24431 and for MVS 370, APAR OY31712.

 

080C0005

If you are migrating from single to parallel sessions and you encounter this sense data verify that APPC=NO in the VTAM APPL for CICS. A trace may look similar to the following;

 

=====> Bind Request for SNASVCMG

<===== ACTPU

=====> ACTPU Positive Response

<===== Unbind

=====> Unbind Positive Response

<===== NMVT

=====> Negative Response to NMVT with Sense Data 080C0005

 

VTAM's syslog may show a BFINIT Request from xxxx failed with sense=08090000.

 

References

IBM Publications Publication Number

 

Systems Network Architecture Formats GA27-3136-11

Systems Network Architecture Format and Protocol Reference

Manual: Architecture Logic for LU Type 6.2 SC30-3269-3

An Introduction to Advanced Program-to-Program Communication GG24-1584-01

Operating System/2 APPC Programming Reference S01F-0263-00

IBM OS/2 Extended Edition Version 1.2 Cookbook

Communications Manager SNA Environment GG24-3553-00

VTAM Programming for LU 6.2 Version 3 Release 2 SC30-3400-1

SNA Transaction Programmer's Reference Manual for LU Type 6.2 GC30-3084-4

 

Sybase Publications

 

Database Gateway for DB2 Reference and Installation Guide 501-G01211-20-01

APPC Guidelines 504-G01211-11-02

DB2-CICS Access Server Installation Guide 501-B01201-20-01

 

Other Publications

 

Advanced SNA Networking: A Professional's Guide to VTAM/NCP

By Jay Ranade and George C. Sackett McGraw-Hill Inc.

 



Back to Top
© Copyright 2010, Sybase Inc.