On Wed, 8 Jun 2011 13:00:13 -0500 Rick Fochtman wrote:
:>Peter, I had the same problem in my shop. Seems that the "pencil
:>pushers" were afraid that IPCS
:>access to a dump would reveal passwords that we "stored" somewhere in
:>system storage.
:>I finally won the fight when I got the RACF tea
I don't know why someone would want to restrict IPCS use. What someone
would normally want to restrict is the data (such as system SVC dump data
sets) that "Joe User" might be allowed to use IPCS on. Your own SYSMDUMPs
should
I suggest using GTF trace to track getmain/freemain for your address
space. Reduce your region size to be at a minimum. When it fails look
at the dump to determine what storage is duplicated and use the GTF
trace to determine where the getmain came from.
In the old days IPCS was seen as one of the biggest users of memory - for
TSO. That may still be guiding installations.
Martin
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Face
>1) IPCS seems to be a great debugging tool. Unfortunately here the
ordinary
>mortals [like us, the applications programmers] are not allowed to use
it. Any
>idea what's the possible danger?
I don't know why someone would want to restrict IPCS use. What someone
would normally want to restric
Many thanks to everyone responded, your input was *VERY* educational.
A couple of notes:
1) IPCS seems to be a great debugging tool. Unfortunately here the ordinary
mortals [like us, the applications programmers] are not allowed to use it. Any
idea what's the possible danger?
2) Regarding anco
- Original Message -
From: "Bill Fairchild"
To: IBM-MAIN@bama.ua.edu
Sent: Monday, June 6, 2011 3:56:42 PM
Subject: Re: How to diagnose memory leak?
Error handling routines need to be tested thoroughly and debugged as well as
main routines.
Bill Fairchild
Rock
@bama.ua.edu
Subject: Re: How to diagnose memory leak?
The problem was triggered by our increased contention for storage - an effect
of adding more load to our system, so that was why it was hitting an error
handler that had just not been used before.
Linda
===
From:
Ted MacNEIL
To:
IBM-MAIN@bama.ua.edu
Date:
06/06/2011 03:24 PM
Subject:
Re: How to diagnose memory leak?
Sent by:
IBM Mainframe Discussion List
I've been working with z/OS & its predecessors since 1971 and I must have
missed the memo7m
-
Ted MacNEIL
eamacn...@yahoo.c
frame Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tony Lubrano
> Sent: Monday, June 06, 2011 12:47 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: How to diagnose memory leak?
>
> Victor,
>
> You may be experiencing memory fragmentation that causes storage ob
To:
Reply-To: IBM Mainframe Discussion List
Subject: Re: How to diagnose memory leak?
No... I meant GFS trace
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ted MacNEIL
Sent: Monday, June 06, 2011 12:07 PM
To: IBM-MAIN@bama.ua.edu
Linda
- Original Message -
From: "Victor Gil"
To: IBM-MAIN@bama.ua.edu
Sent: Monday, June 6, 2011 9:40:04 AM
Subject: How to diagnose memory leak?
Hi,
We have an Assembler user exit invoked by a software product that runs as a
long-running batch job. The exit properly OBTAINs and RELEA
No... I meant GFS trace
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ted MacNEIL
Sent: Monday, June 06, 2011 12:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How to diagnose memory leak?
>GFS trace data can be used to detect this s
Victor Gil wrote:
>
> Hi,
>
> We have an Assembler user exit invoked by a software product that runs as a
> long-running batch job. The exit properly OBTAINs and RELEASEs its working
> storage, however, as written it does not handle a non-zero return code from
> the STORAGE OBTAIN.
>
> This hasn
On Mon, 6 Jun 2011 11:40:04 -0500 Victor Gil
wrote:
:>We have an Assembler user exit invoked by a software product that runs as a
:>long-running batch job. The exit properly OBTAINs and RELEASEs its working
:>storage, however, as written it does not handle a non-zero return code from
:>the STO
>GFS trace data can be used to detect this sort of thing. If you search the
>web for "GFS trace" you should be able to find what you need to know. You can
>map the trace records with IPCS. But you should consider using a program to
>process the trace records to expose the leak.
ITYM GTF trac
--Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Victor Gil
Sent: Monday, June 06, 2011 11:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: How to diagnose memory leak?
Hi,
We have an Assembler user exit invoked by a software product that runs as a
lo
...@neon.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Victor Gil
Sent: Monday, June 06, 2011 11:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: How to diagnose memory leak?
Hi,
We have an Assembler user exit invoked by a software product that runs
Hi,
We have an Assembler user exit invoked by a software product that runs as a
long-running batch job. The exit properly OBTAINs and RELEASEs its working
storage, however, as written it does not handle a non-zero return code from
the STORAGE OBTAIN.
This hasn't been a problem up until last we
19 matches
Mail list logo
