ca.portal.admin

Storage creep

Discussion created by ca.portal.admin on Jun 12, 2008
Latest reply on Jun 12, 2008 by ca.portal.admin
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, the
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 CA
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.

Thanks,
Laura Rochon
Ajilon
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Storage creep
"Good point! Let me check with the areas involved to see if there are
compressed records. I'll get back to you.

Thanks Don.
Laura

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
To: IDMS-L@LISTSERV.IUASSN.COM
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, the
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 CA
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.

Thanks,
Laura Rochon
Ajilon

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Storage creep
"Hi Don,

That's the problem. There are no dbproc calls on several of the areas
that are called by the subprogram.

I'll have to check the whole schema!

Thank you!
Laura

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
To: IDMS-L@LISTSERV.IUASSN.COM
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, the
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 CA
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.

Thanks,
Laura Rochon
Ajilon

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Storage creep
"Laura,

Check your syslocks to see if it is overflowing (use LOCKMON). I believe
overflows come out of Pool 128.

Steve

Outcomes