OA23790: VTAM HANG IN ISTPUCTI AFTER AN IPL OF AN ADJACENT HOST.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After an IPL of one host an adjacent VTAM experienced a hang in
  module ISTPUCTI on the PUNS PAB processing a VR INOP RU
  for a CTC connection to the host that was just IPL'd. FF01 RU.
  ISTTSCSC issued sense 80040000 when processing the VR INOP RU
  which left the process hung in ISTPUCTI.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All subarea environments using virtual       *
  *                 routes (VRs).                                *
  ****************************************************************
  * PROBLEM DESCRIPTION: VTAM hang during virtual route          *
  *                      INOP processing.  Existing sessions     *
  *                      continue to work, but LOGON and LOGOFF  *
  *                      processing is hung on PUNS PAB.         *
  *                      PUNS waiting in ISTPUCTI.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  1) A subarea CTC or MPC connection INOPs.
  2) As part of INOP processing, the sessions and virtual
     routes traversing the connection are inactivated.
  3) PUNS built a VR_INOP AMRU and sent it to the
     Session Serialization (Sesser) PAB for processing
     via the ?PUIO macro.
  4) The PUIO macro expands into a call to module
     ISTPUCTI which performs the work.  The AMRU was
     queued to the Sesser inbound work queue and
     the Sesser (TSSC) PAB was scheduled.  Module
     ISTPUCTI then went into TPWAIT (WAIT) waiting
     for VR_INOP processing to complete.  At this
     point, the PUNS PAB is suspended and can
     no long process work until it is posted out
     of the wait.
  4) Module ISTTSCSC (Sesser) was dispatched and
     issued a CIDCTL FIND TYPE(NEXTNODE) to find the
     routing point control block.
  5) The CIDCTL FIND failed to locate the control
     block and a non-zero return code was passed back.
  6) ISTTSCSC mainline processing called the
     DISPOSAL subroutine.  The trace shows a
     TSNS trace entry with sense x'80040000' being cut
     by the FINDRPCB subroutine.
  7) Later, the DISPOSAL subroutine called GENRESP,
     which called module ISTTSCGR.  Because the ISTRH
     did not have any response indicators turned on,
     module ISTTSCGR discarded the VR_INOP TSCB.
  8) At this point, Sesser exited processing without
     posting PUNS out of the wait state.
  9) All activation, inactivation, LOGON and LOGOFF
     processing was hung at this point.  Active
     sessions continue to function without problems.
  

Problem conclusion

• ISTTSCSC - Mainline processing has been corrected to allow
             AMRUs to be processed by the PROCAMRU subroutine
             even in the event of a CIDCTL FIND failure.
             The PROCAMRU is the proper routine to correctly
             process the VR_INOP AMRU.  This change also
             corrects a similar problem dealing with
             the processing a Route_Setup (RSETUP) flow for
             a VR-TG connection.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UA39516 UA39517 UA39518

Modules/Macros

• ISTTSCSC
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R170 PSY UA39516

     UP08/03/05 P F803 Ž

• R180 PSY UA39517

     UP08/03/05 P F803 Ž

• R190 PSY UA39518

     UP08/03/05 P F803 Ž

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.