SNA Server APPC Error Communicating to Software AG Entire APPC

ID: Q156083

The information in this article applies to:

Microsoft SNA Server, versions 2.0, 2.1, 2.11

SYMPTOMS

You may see the following message sequence when you run an APPC TP on SNA Server communicating to a partner APPC TP on an MVS host (running on Software AG Entire APPC server v1.2.4), over a mapped conversation:


SNA Server            Host

                  <- RH=039020  RU=00 A2 12 FF <lu6.2 data>
                  <- RH=039020  RU=00 A2 12 FF <lu6.2 data>
                  <- RH=019020  RU=00 04 12 F3 00 A2 12 FF <lu6.2 data>

RH=879000, RU=08460000 ->
RH=0A8900, RU=07070889010000 ->

The APPC application running on SNA Server is notified of a conversation failure, when the host TP receives an FMH-7 error with a sense code of 08890100, or the Transaction Program Error: No data truncation.

CAUSE

This is a problem in the Software AG Entire APPC Server running on MVS. The RU in the third LU6.2 data message sent by the host includes a "Map name" GDS command prior to the LU6.2 application data:

000412F300A212FF....

where 000412F3 = Map Name GDS variable (NULL map name) 00A212FF = LU6.2 data (data length of A2)

The SNA Server APPC interface does not support the "Map name" function and rejects the data with a sense code of 08460000 (error forthcoming) followed by an FMH-7 error and sense data = 08890100.

RESOLUTION

Currently no fix is available from Software AG.

The APPC application could work around the problem by using basic conversation verbs on the mapped conversation, allowing the application to ignore the Map Name GDS variable. Here is how the application would need to be modified to accomplish this:

For all APPC calls, change the opcode field to indicate that the Basic verb function is to be called, and change the opext field in the verb control block to AP_BASIC_CONVERSATION.

To simplify handling of received data, set fill = AP_LL on all receive verbs, to restrict received data records to single LLs only.

Change the send and receive verbs to handle the 4 leading bytes at the start of the LU6.2 data as follows:


byte 1,2 = LL field (length of LU6.2 data + 4 bytes, or 32767 max)
   byte 3,4 = GDS variable, where
               x12FF = LU6.2 application data, or
               x12F3 = Map Name GDS variable
   byte 5+  = LU6.2 application data (32763 bytes max)

When you get a message containing the Map Name GDS variable, ignore it and look for LU6.2 application data which may follow.

NOTE: If the leading bit of the LL field is set to "1", this indicates that another LL follows the LU6.2 data. For example, if an APPC application writes 8KB of data, and if it uses a GDS LU6.2 data size of 4KB, the receiving TP would receive the data as follows (if fill=AP_LL is used):


   Data from first receive:   9000 12FF <4KB of data - 4 bytes>
   Data from second receive:  9000 <4KB of data - 2 bytes>
   Data from third receive:   0008 <last 6 bytes of data>

where:


   9000 = LL field: continuation bit + 4KB of data to follow
   12FF = LU6.2 application data GDS variable

NOTE: It is up to the APPC sender to format the GDS variables and length values. The SNA Server APPC interface sends GDS data in 4KB chunks, though other implementations may use the max size of 32767.

For more information about LL and GDS variables, see Chapter 12 of the "IBM SNA Formats Guide" (GDS ID Description and Assignments), IBM document number GA27-3136.

Additional query words: prodsna

Keywords : kb3rdparty kbnetwork kbprg snaappc snatp
Version : WINDOWS:2.0,2.1,2.11
Platform : WINDOWS
Issue type :