IBM Support

OW11968: APPLICATION ASID HUNG DURING SHUTDOWN MEMTERM CANNOT COMPLETE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A cics application was shut down, but the address space did not
    terminate.  ISTAPCSX disabled memory termination and exited
    without enabling it.  This prevented the asid(s) from
    terminating and being available for reuse.
    -
    Additional Keywords: RTMMEMT used to increment ASSBMT#
      but no decrement was done.
    Additional diagnostic information:
    To verify that OW11968 is the fix for a customer's problem, you
    must inspect the field ASSBMT# for each ASCB on the memory
    termination queue.  The memterm queue looks like this:
    .
    .                       +------------+  +------------+
    CVT+x'23C'->RTCT+x'18'->| ASCB+x'68' |->| ASCB+x'68' |->...
    CVTRTNCT    RTCTFASB    | ASCBTMCH   |  | ASCBTMCH   |
                            |            |  |            |
    .                       | ASCB+x'150'|  | ASCB+x'150'|
    .                       | ASCBASSB   |  | ASCBASSB   |
    .                       +------------+  +------------+
    .                            |               |
    .                            V               V
    .                        ASSB+x'D0'      ASSB+x'D0'
    .                        ASSBMT#         ASSBMT#
    .
    If you have a dump, type 'cbf rtct' to format the RTCT, get the
    contents of RTCTFASB (at offset x'18'), and run the queue.  The
    following runchain command worked at SP510:
    .
    runc addr(xxxxxxxx) link(x'68') exec((l X+150?+D0 len(48)))
    .
    where xxxxxxxx is the address in RTCTFASB
    .
    Look at offset x'D0' in each ASSB presented by the runchain
    command. (You should see 'ASSB' eyecatchers in each ASSB').  If
    there are ASSBs that have x'80000001' at offset x'D0', then this
    APAR is likely to be the proper fix for the problem.  FYI, the
    low order 31 bits of this word are used as a count.  As long as
    the count is non-zero, MEMTERM will not run for the associated
    address space.
    
    Additional Symtom:
    ***********
    *  HIPER  *
    ***********
    The MVS command, 'Display Active' does not show a jobname
    associated with an address space (it shows *UNKNOWN).
    MSGIEF352I ADDRESS SPACE UNAVAILABLE
    
    DB2INFO:
    CICS 566540301
    RTM 5752SC1CM 5752scrtm
    DB2 5740XYR00
    Partial dump, NO region (RGN) storage dumped.
    

Local fix

  • ++APAR(AW11968).
    ++VER(Z038) FMID(HVT4201) PRE(UW15050).
    ++VER(Z038) FMID(HVT4201) PRE(UW10768).
    ++ZAP(ISTAPCSX).
      NAME ISTAPCSX
      VER 00B0 47E0,C222
      VER 0750 47E0,C812
      VER 089E 47E0,C9A2
      VER 0A10 47E0,CAD8
      REP 00B0 47F0,C222
      REP 0750 47F0,C812
      REP 089E 47F0,C9A2
      REP 0A10 47F0,CAD8
      IDRDATA AW11968
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: MVS MEMTERM disabled by ISTAPCSX but    *
    *                      not re-enabled. ASIDs cannot terminate. *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    If Module ISTAPCSX segment POSTCRPL, finds a CLOSE UECB on the
    PSTCRPLQ then MEMTERM is not re-enabled upon exiting the module.
    

Problem conclusion

  • It was determined that the MEMTERM DISABLE/ENABLE function in
    ISTAPCSX did not provide any significant protection for
    Persistent enabled applications. This is due to APAR OY50698
    changing the way a synchronous internal request now TPWAITs.
    Consequently, it was removed in four locations in the module.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OW11968

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    201

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    1995-03-14

  • Closed date

    1995-05-16

  • Last modified date

    1996-04-01

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

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

    OW13090 UW17869 UW17870 OW14381

Modules/Macros

  • ISTAPCSX
    

Fix information

  • Fixed component name

    VTAM V4 MVS/ESA

  • Fixed component ID

    569511701

Applicable component levels

  • R101 PSY UW17869

       UP95/06/13 P F506

  • R201 PSY UW17870

       UP95/06/13 P F506

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"201","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"201","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 April 1996