Lots of questions ...
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Woodger
Sent: Sunday, October 23, 2016 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' failure
> D
Do you need to reacquire the storage, or does the LE dump routine hang around
for the second-time-through?
Would it be possible to load the LE dump routine instead of doing the initial
GETMAIN? And your own routine?
Do you have issues with something else looking for storage while you are
proce
@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' failure
From some internal discussion after this issue was raised today, our
intention is that LE will move the CEEDUMP modules to SCEELPA in the next
release of z/OS.
Jim Mulder z/OS Diagnosis, Design, Development, Test
: Tue, Oct 11, 2016 1:44 pm
Subject: Re: CEEDUMP possible following 'new' failure
The "callrtm command" will do no better than anything else that requires
private storage of the address space to run. It is nothing more than a
targeted cancel.
Out of private storage is ou
The "callrtm command" will do no better than anything else that requires
private storage of the address space to run. It is nothing more than a
targeted cancel.
Out of private storage is out of private storage.
Peter Relson
z/OS Core Technology Design
-
Hi Barbara,
no, we did not have Compuware in this environment.
But the callrtm command seams something we need to look at. Thanks for that.
Denis.
-Original Message-
From: Barbara Nitz
To: IBM-MAIN
Sent: Mon, Oct 10, 2016 9:22 am
Subject: Re: CEEDUMP possible following
>I cannot remember exactly, but what happened was that in IMS the STOP REGION
>command was issued and the address space was not listed anymore in IMS
>(Display active showed it was gone).
>It was visible in JES but nothing could be done about it, it did neither
>accept cancel nor force.
Do you
It was visible in JES but nothing could be done about it, it did neither
accept cancel nor force.
Fault Analyzer showed that the last thing that happened in the address
space was trying to load some z/OS routines for termination (if it was not
memory termination then it must have been task te
ginal Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Sunday, October 9, 2016 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: CEEDUMP possible following 'new' failure
>Fault Analyzer showed that the last thing th
>Fault Analyzer showed that the last thing that happened in the address space
>was trying to load some z/OS routines for termination (if it was not memory
>termination then it must have been task termination) and failed to load those
>routines because of an out of storage condition.
I have i
enough room for task termination.
Thanks.
-Original Message-
From: Jim Mulder
To: IBM-MAIN
Sent: Fri, Oct 7, 2016 8:39 pm
Subject: Re: CEEDUMP possible following 'new' failure
> this reminds me of some hanging IMS jobs that could neither be
> cancelled nor fo
On 10/7/2016 1:38 PM, Jim Mulder wrote:
Since memterm does not access the storage of the address
being terminated, there is no connection between IEFUSI and memterm.
There is no requirement for any available storage in the address
space being memtermed. Task termination, yes.
Memory terminatio
> this reminds me of some hanging IMS jobs that could neither be
> cancelled nor forced because the routines for memterm could not be
> loaded because of memory exhausted. Only BMC Tooling allowed to get
> rid of them.
> The suggestion in the PMR was to code an IEFUSI to reserve 512k
> below to
ssage-
From: Jim Mulder
To: IBM-MAIN
Sent: Thu, Oct 6, 2016 10:33 pm
Subject: Re: CEEDUMP possible following 'new' failure
>From some internal discussion after this issue was raised today,
our intention is that LE will move the CEEDUMP modules to SCEELPA
in the next release of
>From some internal discussion after this issue was raised today,
our intention is that LE will move the CEEDUMP modules to SCEELPA
in the next release of z/OS.
Didn't look up and didn't care so far, but now that you mention it, I'm
astonished those modules are not currrently part of LE's LPA
Awesome! Thanks,
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Thursday, October 06, 2016 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' failure
From som
andard? :)
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jim Mulder
> > Sent: Thursday, October 06, 2016 10:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CEEDUMP possible fol
So, when will CEE.SCEELPA be z/OS standard? :)
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jim Mulder
> Sent: Thursday, October 06, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CEEDUMP possi
Ah! Most excellent. Thank you.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Thursday, October 06, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' fail
The reserve seems to be used as the new stack segment, and anything else can
still gobble it up. Gets a U4008 with 1004 not a 1024 apparently. A larger
reserve may help if you still have things acquiring storage.
But then you didn't get a U4008.
Does the production of an LE Dump acquire stora
> The remaining problem is that I am not getting any diagnostic
information,
> in other words, exactly *which* new failed -- which will of course make
any
> bug of this sort in the field hard to find. I call CEEDUMP to get a call
> trace and it produces an *empty* four-line dataset. On the consol
AIN@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' failure
Some suggestions:
- try REPORT (LE option) to see where the storage is used (below, above,
User heap, LE below- or anyheap) and how much storage is used before you get
in trouble; does it depend from the amount of input data
Subject: Re: CEEDUMP possible following 'new' failure
In article <01a301d21fe6$1dbcd760$59368620$@mcn.org> you wrote:
> I have been wrestling with the issue of recovery from a failure of 'new'
> (kind of like a GETMAIN for those of you who are not C people; just
&g
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Woodger
Sent: Thursday, October 06, 2016 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CEEDUMP possible following 'new' failure
Non-batch, I assume. Whilst your "news" are sucking up memory, almost anything
el
Some suggestions:
- try REPORT (LE option) to see where the storage is used (below, above,
User heap,
LE below- or anyheap) and how much storage is used before you get in
trouble; does it
depend from the amount of input data? REPORT will also show if you can
do any better
by playing with the
UA.EDU] On Behalf
Of Charles Mills
Sent: Thursday, October 06, 2016 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CEEDUMP possible following 'new' failure
I have been wrestling with the issue of recovery from a failure of 'new'
(kind of like a GETMAIN for those of you who are
Non-batch, I assume. Whilst your "news" are sucking up memory, almost anything
else asking for more memory could fail, couldn't it? Not just one of yours?
Do you mean CEE3DMP? CEEDUMP is just for setting the options for am LE dump.
In article <01a301d21fe6$1dbcd760$59368620$@mcn.org> you wrote:
> I have been wrestling with the issue of recovery from a failure of 'new'
> (kind of like a GETMAIN for those of you who are not C people; just like
> malloc() for those of you who are C but not C++ people) in XLC/LE C++ code.
> (Yes
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Thursday, October 06, 2016 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CEEDUMP possible following 'new' failure
I have been wrestling with the issue of recovery from a failure of 'new'
(kind of like a GET
I have been wrestling with the issue of recovery from a failure of 'new'
(kind of like a GETMAIN for those of you who are not C people; just like
malloc() for those of you who are C but not C++ people) in XLC/LE C++ code.
(Yes, I know, the right answer is "don't do too many 'new's" but this is
err
30 matches
Mail list logo
