ca.portal.admin

Going SOS in Pool 255

Discussion created by ca.portal.admin on Jun 14, 2006
Latest reply on Jun 22, 2006 by ca.portal.admin
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
"Linda,

We have QO74375 and you need QO74381. Then you can DCMT V STORAGE POOL
255 CUSHION ???

We had lock overflow too and it is set at 100,000. Sounds like we should
extend that a little too then. We have always had lock overflow under
16.0 whenever we have users signed on and then we have to DCMT V SEG
XXXXXXX OFF. It always comes from type Resource. We now DCMT V SEG
XXXXXXX RET and then DCMT V SEG XXXXXXX OFF.

Thanks

Chris

PS Did you ever try switching PAV on with IDMS?

Outcomes