DAE / ADYSET00 / SYSMDUMP
Mark Zelden
DB2 stored procedure to load some data into a QA data base. The
program abended at each invocation and it had 5000 loads to do.
It looked like recursive abends at the time (we found out later it
was a script doing 5000 loads).
For some reason the WLM controlled DB2 stored procedure PROC had
SYSMDUMP DD SYSOUT=* coded and the spool started to fill up. Operations
couldn't get the stored procedure ASID stopped nor cancel it. DB2 support
couldn't either even after shutting down DB2. Eventually the ASID was
forced and the output purged but not until after the spool hit 100% which
caused some other problems during the period the spool was 100% full.
For postmortem action items, I want the SYSMDUMP DDs removed
or not to point to sysout. But I was wondering if there was any reason I am
not thinking of that the DAE SYSMDUMP setting can't be changed to suppress
duplicates like SVCDUMP? If no good reason, I wonder why is that not
the done in the IBM supplied member (ok, I know IBM has a history of bad
defaults, but this is a parmlib setting, not a default)?
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Brian Peterson
>For postmortem action items, I want the SYSMDUMP DDs removed
>or not to point to sysout. But I was wondering if there was any reason I am
>not thinking of that the DAE SYSMDUMP setting can't be changed to suppress
>duplicates like SVCDUMP? If no good reason, I wonder why is that not
>the done in the IBM supplied member (ok, I know IBM has a history of bad
>defaults, but this is a parmlib setting, not a default)?
>
>Regards,
>
>Mark
Interestingly, my z/OS 1.11 Init and Tuning Reference says this:
3.4 IBM-supplied defaults for ADYSETxx
IBM supplies three ADYSETxx parmlib members:
o ADYSET00 automatically starts DAE. It contains:
DAE=START,RECORDS(400),SVCDUMP(MATCH,SUPPRESSALL,UPDATE,
NOTIFY(3,30))
SYSMDUMP(MATCH,UPDATE,SUPPRESSALL)
But, the z/OS 1.11 SYS1.IBM.PARMLIB(ADYSET00) actually says this instead:
BROWSE SYS1.IBM.PARMLIB(ADYSET00) Line 00000009
Command ===> Scrol
DAE=START,RECORDS(400),
SVCDUMP(MATCH,SUPPRESSALL,UPDATE,NOTIFY(3,30)),
SYSMDUMP(MATCH,UPDATE)
Note the difference in the SYSMDUMP value between the manual and the shipped
parmlib member....
Brian
Jim Mulder
10:06:27 AM:
> For postmortem action items, I want the SYSMDUMP DDs removed
> or not to point to sysout. But I was wondering if there was any reason
I am
> not thinking of that the DAE SYSMDUMP setting can't be changed to
suppress
> duplicates like SVCDUMP? If no good reason, I wonder why is that not
> the done in the IBM supplied member (ok, I know IBM has a history of bad
> defaults, but this is a parmlib setting, not a default)?
I imagine the think was that it is OK to suppress SVC dumps,
since they are intended for the systems programmer, who has
access to all of the SVC dumps which have been taken.
But SYSMDUMPs are typically intended for users. So suppose
application developer Joe hits a problem and gets a SYSMDUMP.
Later, application developer John hits the
same problem and his SYSMDUMP is suppressed. John does not have
access to Joe's SYSMDUMP, and doesn't even know that Joe has
the SYSMDUMP which John needs. And neither Joe nor John
have the authority to update the DAE data set to allow another
SYSMDUMP to be taken for this condition (only Mark, the
all powerful systems programmer, has that authority).
In a production-only z/OS image, you may have a view of
things which might make suppressing of SYSMDUMPs reasonable.
The ADYSETxx members supplied by IBM were created in
MVS/XA SP2.1.1, many years before the advent of LPAR,
in a time when production and development were more likely
to be in the same MVS image, since separating them
required separate physical machines (or VM).
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Mark Zelden
>IBM Mainframe Discussion List <IBM-...@bama.ua.edu> wrote on 08/16/2010
>10:06:27 AM:
>
>> For postmortem action items, I want the SYSMDUMP DDs removed
>> or not to point to sysout. But I was wondering if there was any reason
>I am
>> not thinking of that the DAE SYSMDUMP setting can't be changed to
>suppress
>> duplicates like SVCDUMP? If no good reason, I wonder why is that not
>> the done in the IBM supplied member (ok, I know IBM has a history of bad
>> defaults, but this is a parmlib setting, not a default)?
>
> I imagine the think was that it is OK to suppress SVC dumps,
>since they are intended for the systems programmer, who has
>access to all of the SVC dumps which have been taken.
>
> But SYSMDUMPs are typically intended for users. So suppose
>application developer Joe hits a problem and gets a SYSMDUMP.
>Later, application developer John hits the
>same problem and his SYSMDUMP is suppressed. John does not have
>access to Joe's SYSMDUMP, and doesn't even know that Joe has
>the SYSMDUMP which John needs. And neither Joe nor John
>have the authority to update the DAE data set to allow another
>SYSMDUMP to be taken for this condition (only Mark, the
>all powerful systems programmer, has that authority).
>
Thanks Jim. This was almost exactly what I said to one of my Jr. Sysprogs
who asked why it wasn't set. But I also thought it could even be the same
programmer who made a small change, but had the same abend
and wanted the SYSMDUMP.
I figured if I set the suppress option and someone complained and actually
needed a SYSMDUMP, we could always set a SLIP for them too. But I
can't think of any people I know at my shop that want / use SYSMDUMPs.
I know there have been some discussions in the past on IBM-MAIN about
writing them to SYSOUT and using <insert your favorite spool browser
product here> to copy the dump to a data set with the proper attributes
to open it up in IPCS.
> In a production-only z/OS image, you may have a view of
>things which might make suppressing of SYSMDUMPs reasonable.
>The ADYSETxx members supplied by IBM were created in
>MVS/XA SP2.1.1, many years before the advent of LPAR,
>in a time when production and development were more likely
>to be in the same MVS image, since separating them
>required separate physical machines (or VM).
>
In this case there was a shared spool between a QA and prod environment,
even though the LPARs were separate. But I think "prod" wins here and
and I'm going to set the SYSMDUMP supress option to prevent something
like this from happening again.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------