Well, in that case, if you can read a "paper dump", you can
specify, as a DD, SYSUDUMP for the "short version and allocate it
to SYSOUT(*) or you can allocate SYSABEND DD SYSOUT=* which will
be the long more inclusive dump (depending on how it is defined
at your installation).
I used to do support and development, I have tricks up my sleeve
as it were.
Steve Thompson
On 5/24/2023 12:05 PM, Farley, Peter wrote:
I had not thought of that as a possible way to find a solution. Unfortunately
I also do not have the IPCS skills needed to assess the dump and figure out
where the problem is.
Thanks for the idea though.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Steve Thompson
Sent: Wednesday, May 24, 2023 11:35 AM
To: [email protected]
Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential
file?
Peter:
You can allocate a SYSMDUMP data set using the DDNAME SYSMDUMP
within your TSO session, and if DAE doesn't kill it, you should
be able to capture the dump there. It will be readable by IPCS if
you define it as follows:
RECFM=F,LRECL=4160,BLKSIZE=0 (I think blocking works with dumps now)
And SPACE=(CYL,100,30) I think that should be able to hold the
whole dump.
Normally I grab something out of my samples library where I keep
a SYSMDUMP allocation DD. But I don't have that on this system.
Steve Thompson
On 5/24/2023 11:00 AM, Farley, Peter wrote:
Jim,
If I was a systems programmer maybe I could do that, but I am just an
application programmer, and the likelihood that I could get management approval
and production paperwork done to get the systems programming team to set a SLIP
for an infrequently occurring 878 abend in my TSO task only is slim and none,
and slim retired.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Jim
Mulder
Sent: Tuesday, May 23, 2023 11:36 PM
To: [email protected]
Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential
file?
I would set a SLIP and take a dump of the 878 abend, and then look to see
what
is consuming the storage. If this is an extended format compressed sequential
data set,
and if Browse uses BSAM to read the data set, it might be due to NOTE/POINT
compression tables,
We had a problem with the GTF/CTRACE external writer running out of storage
while writing to very
large extended format compressed data sets. I see that I added the following
code in z/OS 2.5
to alleviate that:
/***********************************************/
/* */
/* Our model DCB had MACRF=WP. Since we do not*/
/* do wrapping for extended format data sets, */
/* we do not use NOTE or POINT. We do not */
/* want BSAM to waste space creating */
/* NOTE/POINT compression tables if the data */
/* set is compressed, so we turn off DCBMRPT1, */
/* which is as if we had specified MACRF=W. */
/* @L7A*/
/***********************************************/
IF (OBTAINsucceeded & DS1STRP) /* If OBTAIN
succeeded and it is an extended
format data set @L7A*/
| TWCB_NonWrap_Mode THEN /* Or NOWRAP was
specified @L7A*/
DCBMRPT2 = False; /* Indicate no NOTE/POINT
@L7A*/
Jim Mulder
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Farley, Peter
Sent: Tuesday, May 23, 2023 5:19 PM
To: [email protected]
Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential
file?
Possibly. But if so we are in a lot more trouble than annoying abends out of
TSO, as this is customer data with legal archiving requirements. If it is
somehow corrupted by compression (not sure at this point if that file is using
IBM software compression or zEDC hardware compression) we have MUCH larger
issues.
IMHO it is probably just BAD (broken as designed) BROWSE code, but with OCO
there is no way for an ordinary customer to know.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Schmitt, Michael
Sent: Tuesday, May 23, 2023 4:56 PM
To: [email protected]
Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential
file?
I agree that Browse isn't supposed to require enough memory to hold the file,
so it should work.
But.
Is "compressed data" the key? How is it compressed? Does the fact that it is
compressed mean that more data has to be in memory? Or is it going wild on decompression,
such as if the data is corrupted so the length is wrong? (Like how it is possible to
create a tiny .ZIP file that decompresses to terabytes.)
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Farley, Peter
Sent: Tuesday, May 23, 2023 3:13 PM
To: [email protected]
Subject: Why does ISPF BROWSE abend with S878 searching a large sequential file?
This has happened to me twice this afternoon, and several other times in the last
few months - I am trying to browse (from ISPF 3.4) a quite large sequential file
(> 14500 cylinders of compressed data) for a record with a specific 31-byte key
at the beginning of the record, and browse abends with S878 and throws me off TSO
entirely, requiring me to login again each time.
My TSO logon region size is set to 48000, so what in the world is making browse
consume so much memory that it runs out and crashes my TSO session entirely?
I know, OCO prevents anyone knowing for sure, but if you have any clue I'd
appreciate knowing the answer.
I've been forced to search that file using SORT in a batch job to keep the
frustration level lower.
Peter
--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
