gtps4m20System Generation

Diagnostic Output Formatter

The diagnostic output formatter is really two packages. One of these

operates offline under MVS and is known as the post processor. The other operates online under TPF and is known as the in-core dump formatter (ICDF). SIP automatically includes both of these packages in the generated system. For more information see the TPF Program Development Support Reference.

The function of these packages is to format TPF diagnostic data on a printer in a form that is easily readable by the programmer for the purpose of debugging. Normally, all TPF log type output is directed to the RTL tape (Tape Support). This tape is then read and formatted by the offline post processor.

The types of output logged and formatted are:

Information about all of these diagnostic test tools may be found in the TPF Program Development Support Reference. Other data logged to the RTL tape is processed by other offline packages (for example, SNA's PIU trace).

ICDF, the online portion of the diagnostic output formatter, is designed to only format system error dumps of TPF's main memory directly to a printer. The address of the printer to be used is specified at SIP time on the APRNT keyword of the CONFIG macro. This facility can only be used in a test system. The ZASER command is used to direct output to the online printer via ICDF or to the RTL tape which will be processed by the offline post processor. All other diagnostic output, normally directed to RTL tape, will still be directed to it when ICDF is used to format system error dumps.

Note:
The generated system is set up to use the RTL tape.

One of the functions of the offline version of the diagnostic output formatter is to perform terminal simulation on the input/output message stream that has been logged by PTV to the RTL tape. These messages are printed by the post processor in the same form that they would be seen on the actual communications terminals. In addition, errors in the message text, as a result of terminal characteristics or requirements, are detected and reported.

Terminal simulation is provided for the following communication devices:

For PTV phases I and III, the terminal simulator programs of the offline diagnostic output formatter know which messages are for which terminal types based upon user input to STC that identifies the terminals by address (LNIATA). This information is passed by PTV to the post processor via the RTL tape.

For PTV/STV mode, a preset table in segment BMP0 of the offline formatter is used to identify specific 3705 EP, 3270 local, and NEF supported terminals by terminal address.

The user must physically update each of the tables within segment BMP0 to reflect the terminals and terminal types that will be used for input during PTV/STV mode testing. The tables must also contain the addresses of any printers that are to receive output and are on simulated lines during the STV test. The use of a simulated communications network during PTV testing is discussed in Program Test Vehicle. The entries in the BMP0 tables should also be consistent with the terminal type entries made in the UAT.

There are six tables within segment BMP0, one for each of the supported communication device types, except for SNA devices. The 3270 terminal table is further subdivided into eight subsections based upon 3270 model type.

  1. Each table entry, except for 3270 devices, consists of four bytes:
    1. The first byte is a X'00'.
    2. The next three bytes are the terminal address (LNIATA). Note, for NEF supported terminals, the pseudo terminal address should be used.
    3. The entry for the teletype (83B) terminals, which are addressed by only a one-byte low-speed line number, should be placed into the table as X'0000LN'.
  2. For 3270 terminals, each entry consists of six bytes:
    1. The first byte, instead of being a X'00' as it is for non-3270 terminals, is a bit combination that is used to identify the 3270 model type. An explanation of the bit settings appears in the BMP0 listing commentary.
    2. The next three bytes are the LNIATA of the 3270 terminal. Note, 3270 local terminals should appear as X'LN0000'.
    3. 3270/SDLC pseudo terminal addresses should not appear in the table.
    4. The next two bytes for each entry is the EBCDIC control unit and device address that is used by the 3270 copy command.
      Note:
      The CU/DV address should be coded as two blanks, X'4040', for 3270 local terminals since they do not support the copy command.

The list below identifies the labels used within BMP0 and the terminal type that they represent:

Note 1:
3270 support within the terminal simulators is obtained via the use of conditional assembly code; the 'AIF' statement. As a result, the 3270 tables are not present unless the user has requested one of the various 3270 supported protocols (e.g., 3270 local or BSC), except for 3270/SDLC.

Note 2:
These tables are for all of the supported 3270 printers except for the 3284 model 3. Special mention should be made of the relationship of this package to the ISAM data set created by the SNA table generation process. When formatting either PTV or RTT output, it must convert the logged SNA resource identifier (RID) to a nodename. The ISAM data set, which is used to perform this conversion, must represent the same online TPF/SNA data base that has been loaded to the TPF system. In addition, the terminal simulator uses this data set to obtain terminal/device characteristic information. If, for example, a resource has been added to the online database, but an old ISAM data set was used, the converted RID would not identify the correct SNA resource.