After an AS400 or I-Series has either had a Backup performed, been put into a Restricted state or been IPL'd the telnet sessions on a PTX controller are in a Lock-H state. Generally the terminals will show a blank screen with the Lock-H status.
The process of an IPL or System Backup requires the AS400 to be put into a Restricted state. To get to a Restricted State the ENDSBS *ALL command is used to shut down all the subsystems on the AS400. This process will end all the jobs on the AS400, end the TN5250 telnet connections by locking the sessions, clearing the screen and then closing the TCPIP connection. Sniffer traces have shown it is possible that the AS400 will lock the session and clear the screens but not close the TCPIP connections to the PTX controller. Since the sessions are in a locked state, the user is not able to start a new telnet connection to the AS400 after it has exited the Restricted state.
The Telnet server needs to be stopped before the ENDSBS *ALL occurs. This is done using the ENDTCPSVR *TELNET command. This means prior to issuing the PWRDWNSYS, SAVE, GO SAVE, GO BACKUP or performing an action that will end all subsytems the ENDTCPSVR *TELNET command needs to be issued. Reference for this problem can be found in the following IBM documentation.
Document Number: 472677295
Functional Area: Communications-TCP
SubFunctional Area: Emulation
SubSubFunctional Area: Telnet
Product: TCP/IP CON UTIL (5722TC100)
Release: V5R3M0; V5R3M5; V5R4M0
Not Able to Establish Telnet Session or PC5250 Emulation after Restricted State
After a Restricted State process is taken, end users find that they are
unable to connect to the system via Telnet; however, other TCP applications
work fine (PING, FTP, mapped drives, and so on). It was determined that
ENDSBS *ALL *IMMED was issued prior to ending the Telnet server or as part
of the client's restricted state process.
This problem was addressed by development. The following was determined:
The Telnet server is different than other TCP servers. Most other TCP
servers are only required to support stateless sessions or sessions of very
short duration as compared to a Telnet session. The jobs above the MI are
used for startup and tear down of each individual Telnet session, but all
of the steady state traffic runs in stream sessions below the MI. Neither
job type is designed to abend.
The Telnet server job is the anchor point for potentially tens of thousands
of Telnet stream sessions running below the MI. If that job abends, all of
those stream sessions get closed, so Telnet is designed to keep the server
up (even if it can no longer take new connections because of TCP or Socket
errors) unless it is explicitly requested to shut down with ENDTCPSVR
Likewise, the Device manager jobs are designed to run from IPL to IPL; they
do not even end with ENDTCPSVR. They are required to be active for an
indeterminate length of time after the server is shut down to de-allocate
virtual devices, including all LUD list cleanup processing. As for backup
and restore, there is also a lot of design that went into seamlessly
allowing for all interactive subsystems to be ended and restarted without
disturbing the active, steady-state Telnet sessions that are connected to
The ENDSBS help text warns of undesirable side effects when the *IMMED
option is used. To properly address this issue would require a nontrivial
change to the design of the job start up and shut down flow, and it would
be more properly addressed in a request for design change and not in an
The Telnet server is working as designed.
A recommended change is to ensure the ENDTCPSVR *TELNET command has
completed prior to ending the QSYSWRK subsystem in your restricted state
process. The time needed for the Telnet server to end may vary on
This document and many others can be found by selecting the "Technical
databases" link at the following URL: