Re: Storage creep

Discussion created by ca.portal.admin on Jun 12, 2008
Good point! Let me check with the areas involved to see if there are
compressed records. I'll get back to you.

Thanks Don.

Don Casey wrote:
COMP and DCOM won't release storage unless they are called at AREA
level (on
FINISH?) as well.

Don Casey
Run Right, LLC

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Laura Rochon
Sent: Thursday, June 12, 2008 8:00 AM
Subject: Storage creep

Hi everyone,

I'm at that age where somethings seem vaguely familiar but can't
remember, so I'm calling on your help.

I have a production batch job that has been running for years, with no
problems. Has NOT been changed (and I can attest to that). The
volume of the input is a lot higher than normal though. When the job
runs, Pool 128 (contains ALL) goes SOS. Monitoring the job while it's
running shows that locks are being released as the rununits commits,
and in
fact, there is not that much database updating going on. However,
program calls 2 subprograms which each do a BIND RUNUNIT and a FINISH
for each call. So, as the volume of input increases the number of
times the subprograms get called and the number of BIND RUNUNIT/FINISH
increases. When we split the input file into small input files and
reran, it ran okay. Now this is where my memory isn't helping me
much. I seem to recall that there was a problem about storage not
being released in this type of scenario, but cannot find anything on
Support. So, I'm hoping this rings a bell to someone out there in
IDMS-L land.

We're running on zOS 1.8, with CA IDMS R16, sp4.

Laura Rochon

IDMS Public Discussion Forum


Re: Storage creep
I got bit by this recently myself, both forgetting things and the
storage creep!

Although the program hasn't changed in years, do you have any database
procedures involved? Have those changed? In our situation it was a
database procedure that had a big in it for a long time and was not
releasing storage between calls. Once this was fixed the problem went

Dan Hall
GE Capital Solutions
Database Administrator

T 513.217.5060

Middletown, OH 45042
General Electric Capital Corporation