OA38554: ABEND0C4 IN MODULES ISTSQCDS, ISTMGCSC DUE TO BAD ACDEB POINTER IN RDTE WHEN RUNNING TELNET SHAREACB FUNCTION.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ABEND0C4 in modules ISTSQCDS, ISTMGCSC due to bad ACDEB pointer
  in RDTE when running TELNET SHAREACB function.
  

Local fix

• Specify NOSHAREACB in Telnet profile.
  Ensure that Telnet LU names are unique.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users who specify SHAREACB in            *
  *                 their Telnet profiles.                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABEND0C4 in various modules due to      *
  *                      corrupted RAPACDEB pointer after        *
  *                      APPL/CDRSC collision.                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem may be summarized as follows:
  1. The Telnet profile has SHAREACB coded.
  2. A SNA session from a remote SLU is established,
     causing VTAM to create a dynamic CDRSC with the
     name of the session partner that does not reside
     in this host.
  3. Later, Telnet assigns that same name to one of its
     connections and when it notifies VTAM of the name, VTAM
     creates a APPL RDTE, but because a CDRSC of the same name
     is present and has a session, the APPL RDTE is put into
     a shadow state.  This is the root of the problem.
     (The RDTE collision also prevents Telnet from initiating
     a session for the connection.)
     Having unique names for different resources would have
     avoided this situation.
  4. When the session ends, VTAM frees the CDRSC and moves the
     APPL RDTE out of the shadow state.  In the process of
     moving the APPL RDTE out of the shadow state, ISTACCDG
     checks a bit in the RDTE without first verifying that
     the RDTE is the appropriate type. The bit is on, but it
     is part of an address that points to the ACDEB.  Because the
     bit is on, ISTACCDG calls ISTACCLA, which, as part of its
     processing, turns off the bit, thus corrupting the pointer
     to the ACDEB.
  5. The next time the RAPACDEB pointer is used, an ABEND0C4
     may occur.  What module encounters the ABEND is dependent
     upon the function that is invoked.  For instance, a
     display of the resource name may lead to an ABEND0C4 in
     ISTSQCDS. Or, if a CNM RU is being processed, it may lead
     to an ABEND0C4 in ISTMGCSC.
  

Problem conclusion

• ISTACCDG is updated to ensure that the RDTE is an RLU
  before checking the RLUSHAD_ACT bit.
  
  ISTLUCST is updated to cleanup the RAP just created if
  it is in a shadow state upon return from the DYNAMRDT
  macro.
  

Temporary fix

Comments

APAR Information

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

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

  UA63969 UA63970

Modules/Macros

• ISTACCDG ISTLUCST
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1C0 PSY UA63969

     UP12/04/24 P F204

• R1D0 PSY UA63970

     UP12/04/24 P F204

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.