Hi
Would try with a SLIP trap with proper SDATA and JOBLIST options
On 8/31/2011 1:16 PM, Robin Atwood wrote:
Barbara -
First, thanks for the speedy response!
I assume by option 4 you mean the Dump Inventory (which is option 6
here). The LD command showed that only ASIDs 1 and 154 were dumped. The
cbf command showed that trace data was to be dumped but systrace
produced:
BLS17541I No address spaces with the ERROR attribute were found
******** ERROR OBTAINING TRVT/01 AT 00FF7C98 RC = 04.
******** ERROR OBTAINING TTCH/05 AT 7FF5F000 RC = 04.
******** SYSTEM TRACE PROCESSING IS TERMINATED.
since neither of the locations are in the dump. Further suggestions are
very welcome!
-Robin
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Barbara Nitz
Sent: 31 August 2011 11:37
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumps with no useful memory
This application uses dependent ASIDs created with the ASCRE macro and
entered with the PC instruction and my suspicion is that the abend is
actually in one of these. Does anybody have an idea how I get z/OS to
the dump the ASID which actually abended (if that is indeed the case)?
There is an estae which I could modify. I am not the original author so
this a bit of a poser!
First of all, go and check option 4. Do an ld in front of the dump and
check which asids are actually contained in the dump. The storage
dumped can be found there.
Next thing is the following command
cbf rtct+9c? str(sdump) view(flags)
which will show you the dump options used for the dump you have. Make
sure that just about everything is specified, when in doubt, modify the
sdump options on that system.
Provided trt was one of the options, check systrace to see if the abend
occured in cross-memory mode. You would recognize this if the column
sasn and/or pasn (on the right hand side) are different from home (to
the extreme left). Only then you would need to do something.
> From the addresses you've shown:
00002000.:B93FFF.--Storage not available
1ABBA000.:FFFFFFFF_FFFFFFFF.--Storage not available
the first one may be not available because it is in common storage (in
which case you're going to browse active storage on the system the dump
was taken. That will give you the address around B92FFF.)
The second address might be above the line of another address space.
> From the systrace you've done above, note the pasn and do your browse
(or where) by adding 'asid(xxx)'.
If option 4 and ld have shown you that most of the dump was taken for
another address space, you might also set the default (setdef) for all
IPCS commands to that address space (which will enable you to not
specify them explicitly on every command).
Come back with the results from the above - I might have further
suggestions :-)
Best regards, Barbara
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This message has been scanned by MailController -
portal1.mailcontroller.co.uk
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
