A fix is available
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 / Xsystem
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.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMWM","label":"Tivoli NetView Distribution Manager"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"170","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
24 September 2013