Advanced communication function trace analysis program (ACFTAP)

The Advanced Communication Function Trace Analysis Program (ACFTAP) is part of the ACF/SSP (System Support Programs) licensed product. This formatter interprets the GTF records and puts out the buffer trace records in various formats, depending on the options requested.

ACFTAP does not format the data that is given to VTAM® over the application interface. This information is available only when formatting with IPCS. The following options are relevant to the VTAM buffer trace:

SOURCE=GTF: This option tells ACFTAP that the input data set has records in GTF format. Normally, this is the only input that is defined in an z/OS® system.
INPUT=BUFFER: This option tells ACFTAP to use only the buffer records in the input data set. The input data set could have various different record types, including VTAM internal trace records, Db2 performance trace records, and many different z/OS records.
NODE=<name>: This option requests ACFTAP to format any records for the node specified. If this option is omitted, ACFTAP formats only network PIUs (those PIUs flowing to set up or take down a session, activate or deactivate resources, etc.). Depending on the time the trace was taken, there might be no output from the job.
PRINT=YES: This option gives an entry for each PIU, including the interpretation of the TH and RH. Only 45 bytes of the RU is printed.

In Figure 2 is an example of ACFTAP formatting when using PRINT=YES. The PIU is the same as the one in Figure 1.

This trace entry shows an OUTbound (from this VTAM) PIU flowing from LUDBD2 to LUDBD1.

The interpretation of the TH shows the addresses of the LUs and the count field. The count field has converted the length field in the TH from X'350' to decimal 848. The Origin SubArea Field (OSAF) and Origin Element Field (OEF) show an address for LUDBD2 of '0000000F 006E'. Similarly, the destination address is '0000000E 006B' This address represents LUDBD1.

Figure 1. Buffer trace formatted by using ACFTAP option SSPRT=YES

                                                    ADVANCED COMMUNICATIONS FUNCTION
                                                         TRACE ANALYSIS PROGRAM
            DATE: 09:19:89                        SYSTEMS NETWORK ARCHITECTURE SUMMARY                        PAGE: 00001
              *******SDLC******  **********TRANSMISSION HEADER*********  ************************REQUEST HEADER*********************
              ..-SDLC ADDRESS    .-FORMAT IDENTIFIER (FID)               .-REQUEST(Q) OR RESPONSES  .-PACING INDICATOR
              || .-CMND/RESP     | .-F/M/L/( =ENTIRE)SEGMENT  **FID3**   | .-SC/DFC/NC/( =FMDATA)RU   | .-BEGIN BRACKET INDICATOR
  DIRECTION-. || | .-POLL/FINAL  | | .-EXPEDITED                         | | .-FORMATTED              | | .-END BRACKET INDICATOR
            | || | | .-RECEIVE   | | |                        LSID---.   | | |  .-F/M/L( =ONLY)CHAIN  | | | .-CHANGE DIRECTION IND
    TYPE--. | || | | | .-SEND    | | |    SAF-EF     FROM/TO SSCP--. |   | | |  |                     | | | | .-ALT CODE
  ------- | | || | | | | .-TYPE  | | |      OR       FROM/TO PU--. | |   | | |  |                     | | | | |    *********RU******
  MESSAGE | | || | | | | | CMND  | | |   OAF  DAF    SEQNO COUNT | | |   | | |  |  REQUEST/RESPONSES  | | | | |     COMMAND   SENSE
  NUMBER  V V VV V V V V V ____  V V V _____________ _____ _____ V V V   V V V  V  _________________  V V V V V    _________  ______
  0000001 B O                    4     0000000F 006E 0007  00848        Q   F     DR1     EXCEPTION    B   S      UNKNOWN
                                       0000000E 006B
  0000002 B I                    4     0000000E 006B 0006  00781        Q         DR1     EXCEPTION        S
                                       0000000F 006E

The bits in the RH have also been interpreted. The following functions are listed:

FMT to show there in an FMH in the RU. In our case, this is the FMH5.
BB to show that this is the beginning of a bracket.
CD for change direction, to allow LUDBD1 to send some data back.
REQ to show that this is a request PIU.
DR1 and EXC tell LUDBD1 to send a response to this PIU only if there is an error.
FM is the RU data type.

This format indicates that the RU holds the FMH5, but little else.

The following figure is an inbound PIU. It is the same as the PIU formatted in the VTAM entry in VTAM buffer traces.

This trace entry shows an Inbound buffer from LUDBD1 to LUDBD2. Similar interpretation of the TH and RH has occurred for this PIU. This PIU is in fact the first row of output from a select being sent back to LUDBD2. Not all the data is available in the VTAM buffer trace. It can be seen in the Db2 performance trace.

SDPRT=YES: This option requests an SNA detail report of the VTAM buffer trace. The two entries that are formatted for the PRINT=YES were formatted by using the SDPRT=YES option for comparison purposes.
SNA detail gives interpretation for each section of the TH and each bit of the RH, whether it is on or not. PRINT=YES gave only interpretation of the bits that were on. SNA detail also includes all of the traced PIU - TH, RH and up to 256 bytes of the RU. In the 'USER DATA' the RU was converted from EBCDIC to alphanumeric characters, for easier interpretation of the data.
SSPRT=YES: This option requests an SNA summary report that is shown in the previous figure. On its own, this report is of little use in diagnosing a problem. However, it is helpful if the buffer trace is long and you are looking for a particular event that occurred. You might be able to find the particular event by using the command or sense column of the output. After the event is located, use the message number on that row to cross-reference into the SNA detail or print reports. Any particular PIU has the same message number in each of the reports.

Figure 2. VTAM IO trace printed by using ACFTAP

   0000001 RNIO TRACE OUT ORIGIN(0000000F) DESTINATION(0000000E) TIME(10.08.48.174531) DATE(09.26.89)
           TH   40000000000000000000000E0000000F1C00006B006E00070350             OSAF OEF(0000000F 006E) DSAF DEF(0000000E 006B)
                              ERN(0) VRN(0) TP PRI(0) VR SEQ(000) TG SEQ(000) SEQ(0007) COUNT(00848)
           RH   0B90A0                      FM     DR1     EXC                BB    CD              FMT          REQ       UNKNOWN
           RU                               270502FF0003D0
   0000002 RNIO TRACE IN         ORIGIN(0000000E)    DESTINATION(0000000F)  TIME(10.08.48.371635)  DATE(09.26.89)
           TH   40000000200000100000000F0000000E1C00006E006B0006030D             OSAF OEF(0000000E 006B) DSAF DEF(0000000F 006E)
                              ERN(0) VRN(0) TP PRI(0) VR SEQ(010) TG SEQ(000) SEQ(0006) COUNT(00781)
           RH   039020                      FM     DR1     EXC                      CD                           REQ
           RU                               030AEFFE415500

The SNA summary report contains five main column sections:

Section 1 has the message number, the type (in this case shows 'B' for buffer), and the direction ('O' for outbound and 'I' for inbound).
Section 2 is 'SDLC'. This is used for NCP line traces and is not used for buffer traces.
Section 3 is a summary of the transmission header. The parts of interest are the addresses. The origin address '0000000F 006E' is on the first line and the destination address '0000000E 006B' is on the second line for the first message. These are the same addresses as the other formats, but the names of the LUs are not included. The count is the length value that is again converted to decimal. The sequence number of the PIUs (SEQNO) is included here also. Sequence numbers are kept on the PIUs that flow in each direction on the session to avoid getting data out of order at the receiving end and for pacing purposes.
Section 4 is a summary of the bits in the request header (RH). This has the same information that is explained under the other formatting options.
Section 5 is for the RU. Only the command and sense are included here. On message number '0000001' the command is unknown. This is because the formatter does not recognize the FMH5. For PIUs that have a command code as the first bytes in the RU this indicates the interpreted code. For example, if the RU is a BIND, it has X'31' as the first byte of the RU. ACFTAP interprets this, and put 'BIND' in the command column for that PIU. If there is any sense in the RU, (remember there is a sense-data-included bit in the RH), ACFTAP puts the sense data in the SENSE column.