PK80343: ABEND0C4 IN DSXTMM12 WHILE TESTING UNDER ZOS V1.10

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • S0C4 in NvDM at z/OS 1.10 or higher with
    USEZOSV1R9RULES(NO) specified (or used by
    default) in the system parmlib DIAGxx member:
    .
    PSW AT TIME OF ERROR  470C1000   8A120F82  ILC 4  INTC 10
        NO ACTIVE MODULE FOUND
       DATA AT PSW  0A120F7C - 30684780  C9ACBF6C  A0008A60
        GR 0: 8A12060E   1: 00AD03C8
           2: 00000080   3: 00AD1F38
           4: 80AD0388   5: 0A12260C
           6: 00AD1F38   7: 0000006C
           8: 0000006C   9: 00000004
           A: A010004C   B: 0A12160D
           C: 8A12060E   D: 00AD03C8
           E: 8A120ED4   F: 00000000
     EC PSW AT TIME OF ERROR  470C1000 8A120F82 00040010 20100000
    Reg-A is incorrect.
    A snapdump of the abend shows:
    It showed some evidence that a GETMAIN issued by DSXTMM12 for
    the VTAM ACB was wrong. The system trace showed the following
    events.
     1) GETMAIN for the VTAM ACB was issued by DSXTMM12 at 0A963D90
    + 7AE with length= x'6C' (LACB).
     2) The storage address is stored into GETMAR@.
     3) GENCB for VTAM ACB was issued with WAREA=(GETMAR@ + 8)
        and length=x'6c' (LACB).
    Our z/OS specialist pointed out the location of the storage area
    which was GETMAINed by NvDM looked odd.
    When two storage areas are GETMAINed consecutively, the first
    one usually has higher address, and the next one will have a
    lower address.
    In this customer's case, the first one was the VTAM ACB which
    was GETMAINED by DSXTMM12, and the next one was the VSAM ACB for
    DSXTCF.  And the 1st one has lower addess and the 2nd one was
    higher address.
       at  64C0-6527 <-- getmained 1st
       at  6528-6573 <-- getmained 2nd
    He examined the GETMAIN behavior of z/OS v1r10 and found this
    change was documented in OA27291 .
    .
    NvDM should correct the GETMAIN code in DSXTMM12 as it
    uses x'74' bytes while it GETMAINs only x'6C' bytes.
    The local fix described in OA27291 may hide this bug but there
    is no guarantee that the problem would never happen again.
    

Local fix

  • see local fix for apar  OA27291
    (temporarily use parameter USEZOSV1R9RULES(YES)
    in DIAGxx member until the PTF can be applied)
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: all users                                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: TCP -running with ZOS1.10- gets ABEND   *
    *                      0C4 when starts                         *
    *                                                              *
    ****************************************************************
    * RECOMMENDATION: APPLY THE PTF FIXING THIS APAR               *
    ****************************************************************
    see problem description
    

Problem conclusion

  • GETMAIN for the VTAM ACB was issued by DSXTMM12 with length=LACB
    Now it is issued with length=GETMAR
    

Temporary fix

Comments

APAR Information

  • APAR number

    PK80343

  • Reported component name

    NETVIEW DM V1 M

  • Reported component ID

    568501601

  • Reported release

    170

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2009-02-10

  • Closed date

    2009-04-27

  • Last modified date

    2013-09-24

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

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

    UK46033

Modules/Macros

  •    DSXTMM12
    

Fix information

  • Fixed component name

    NETVIEW DM V1 M

  • Fixed component ID

    568501601

Applicable component levels

  • R170 PSY UK46033

       UP09/05/14 P F905

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.



Rate this page:

(0 users)Average rating

Document information


More support for:

Tivoli NetView Distribution Manager

Software version:

170

Reference #:

PK80343

Modified date:

2013-09-24

Translate my page

Machine Translation

Content navigation