ca.portal.admin

Re:Going SOS in Pool 255

Discussion created by ca.portal.admin on Jun 14, 2006
Hi,



Yesterday and today we have exhausted Pool 255 allocation with large
Batch CV jobs. This pool is defined as type SY. We have a cushion
defined and can see no other storage pool went SOS though pool 0 high
water mark was higher than normal. The IDMS system handled everything
well and once it abended the problem program, the CV settled down.



An effect that I was surprised was that we had a SYSTEM MODULE PROGRAM
CHECKED NEAR RHDCSTGP AT OFFSET 328 when the pool went SOS with an SOS
CONDITION 1 the first time.



We are on 16.0 SP1 plus many apars. Is this the way that the system is
expected to work?



We are putting a stop on running the large Batch CV job during the day
and increasing both the primary allocation and cushion in that pool.



I just thought that this was a strange method to handle the situation
and had not seen it before.



Thanks



Chris Wood

Alberta Department of Energy

CANADA

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








Normal

Normal
Re: Going SOS in Pool 255
"If pool 255 fills up then it will overflow into pool 0. 255 has no cushion
as I remember since it is strictly system stuff.

Dick

Richard C Borman/GIS/CSC
CSC/GIS Idms System Support
9305 Lightwave Ave
San Diego, Ca 92193-9011
home 760-787-1075
office 858-573-3265
rborman@csc.com



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------





Chris Wood
<Chris.Wood@GOV.A
B.CA> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> Going SOS in Pool 255


06/14/2006 10:31
AM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>






Hi,



Yesterday and today we have exhausted Pool 255 allocation with large
Batch CV jobs. This pool is defined as type SY. We have a cushion
defined and can see no other storage pool went SOS though pool 0 high
water mark was higher than normal. The IDMS system handled everything
well and once it abended the problem program, the CV settled down.



An effect that I was surprised was that we had a SYSTEM MODULE PROGRAM
CHECKED NEAR RHDCSTGP AT OFFSET 328 when the pool went SOS with an SOS
CONDITION 1 the first time.



We are on 16.0 SP1 plus many apars. Is this the way that the system is
expected to work?



We are putting a stop on running the large Batch CV job during the day
and increasing both the primary allocation and cushion in that pool.



I just thought that this was a strange method to handle the situation
and had not seen it before.



Thanks



Chris Wood

Alberta Department of Energy

CANADA

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








Normal

Normal
Why Parallel Unload/Reload would have helped.........
"Thought I would share some interesting statistics from a
situation where the new Express Unload/Reload would have helped.

We added a new area/records that we added to satisfy some Sarbanes Oxley

compliance requirements. This new area grew at a rate no one
anticipated.
One fine Wednesday before we can look at the weekly print space
reports, I get a call that this new production area has filled up
and task are taking 1211's all over the place.

Since this was our busiest production region we had to act quickly and
ran an expand page and changed the block size from 6516 to 13032.
We were only down 18 minutes and the earthquake only measured 2.3
on the management scale...

However, before I could get a good weekend to unload/reload the area,
the area
fills once again in the middle of a week. (Murphy's law hard at work)
This time I decided an extend space was in order and I added 3 datasets
to the
area. So now I have an area that has been xpaged and extended.

I expected the I/O to the area to go up because of the space
management implications, but the interesting part is the I/O went
through the roof! See the real daily I/O to the area below;

I/O per day
Before XPAGE 450,000
After XPAGE 902,177
After Extend Space 10,773,437 - yes, over 10 million, this is not a typo

After Unload/Reload 497,783

As you can see when we were able to unload/reload it
cut the I/O considerably (understatement!).
The good news is the new Express Unload/Reload would
have allowed me to unload reload the area in a much smaller time frame.
I could have reorganized the area before it filled the second time.
We are all looking forward to this new SP4 feature.

Regards,
Terry Schwartz

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








Normal

Normal
Re: Why Parallel Unload/Reload would have helped.........
"Terry,
You have to remember with EXTEND that the calc pages do not change. So
all the new calc records would select a target page within the original
files and then overflow. Causing the dramatic increase in I/O. Another
situation that I have seen with EXTEND was with direct records. The
programs that stored the direct record had the area page range
hard-coded. If the routine calculated a page outside of this range, it
assumed a logic error occurred and forced the store to page 1 of the
area. This also caused a HUGE increase in I/O.

Dan Hall

Outcomes