The main goal of diagnosing this type of problem is to
determine whether the data was sent incorrectly by the host application
or corrupted by VTAM®, TCP/IP,
Telnet, or Telnet client code.
About this task
Table 1 lists the types
of incorrect output that might be seen and the steps needed to identify
the code in error.
Table 1. Incorrect output types for Telnet| Incorrect Output |
Analysis Steps |
|---|
| Blank screen |
1, 6, 7 |
| Garbled or unreadable characters on the screen |
2, 3, 4, 5, 6, 7 |
| Incorrectly formatted screen |
6, 7 |
Procedure
See Table 1 to identify
which of the following steps to use in determining the cause of the
error.
- Was the last output data seen in a SEND DATA to CLIENT
CTRACE entry displayed at the terminal emulator? If not, the problem
is in the client or emulator. Contact your emulator provider for this
product. If the last output was seen at the terminal, go to step 9 of the analysis procedure
in Session hangs (server), and continue your diagnosis.
- Was the TELNET command entered with TRANSLATE specified?
If so, make sure the translate table is compatible with the capabilities
of the client device. If compatible or no TRANSLATE was used, continue
with Step 4.
- The CTRACE with TELNET option entries show the data as
it arrived from VTAM and again
as it goes to the stack. FULLDATATRACE parameter should be specified
in the profile when looking for a problem in the data stream. Examine
the CTRACE and compare the DATA from VTAM entries to the DATA to CLIENT entries. If they are different,
then Telnet altered the data stream. If not, the problem is with the
TCP/IP platform code. Otherwise, continue with Step 4.
- In the data trace output, is the data stream
sent by the server the same as received from VTAM? If not, the problem is with the Telnet
code. Otherwise, continue with Step 5.
Tip: If the client is an ASCII device, these might be different
due to EBCDIC-to-ASCII translation. Check the appropriate translate
table for compatibility with the client device.
- In the VTAM Buffer trace with the FULL option specified, is the data in the VTAM USER entry (data received
by VTAM) the same as the data
in the VTAM BUFF entry (data
sent by VTAM)? If not, VTAM has corrupted the data. Otherwise,
incorrect data was sent by the application. Contact the IBM® Software Support Center for the host application.
- Is the LOGMODE specified for the negotiated terminal type
valid for the actual client device?
Tip: A VTAM session display specifying
the SID for the session shows the actual logmode selected by the
SNA application.
- Does the device characteristics information in the BIND
sent by the host application match the device characteristics information
in the specified LOGMODE entry, and are these characteristics appropriate
for the emulator in use? This can be checked by comparing
the specified LOGMODE entry (see z/OS Communications Server: SNA Customization) with the BIND in the buffer trace at logon
to the selected application. For information about the BIND RU, see z/OS Communications Server: SNA Programming and SNA Formats.
Results
If the problem is not found after using the analysis steps,
contact your IBM Software Support
Center for additional diagnostic suggestions.