Size Of SQA At Next IPL

[Andrew Metcalfe]

Hello Listers

We only perform scheduled IPLs of our systems twice a year. During these 6
month periods, there is a large amount of IODF change implemented by
dynamic Activate (by another team).

We have had a number of occasions when IPLing our systems where the
Private area (below) has increased (not so much of a problem till folks start
using it and I take it away again) or decreased (big problem as some
applications won’t start) as a result of the change in SQA size without a
compensating change in the CSA= parameter in IEASYSxx to maintain the top
boundary of Private.

The problem is caused by SQA size being “determined” rather than “specified”
at IPL time. Then CSA, which is specified, is bolted on the bottom and rounded
to the next Mb boundary.

Does anyone know of a programmatic way to determine the approximate size
that SQA would be at the next IPL assuming no more Activates are performed?
Is it simply a matter of counting the UCBs below 16Mb (via UCBSCAN?) and
multiplying by x’112’ as per HCD Planning manual?

Any pointers gratefully received.

Thanks

Andrew Metcalfe
Barclays Bank

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gaur]

Post by Andrew Metcalfe
Hello Listers
We only perform scheduled IPLs of our systems twice a year. During these 6
month periods, there is a large amount of IODF change implemented by
dynamic Activate (by another team).
We have had a number of occasions when IPLing our systems where the
Private area (below) has increased (not so much of a problem till folks start
using it and I take it away again) or decreased (big problem as some
applications won’t start) as a result of the change in SQA size without a
compensating change in the CSA= parameter in IEASYSxx to maintain the top
boundary of Private.
The problem is caused by SQA size being “determined” rather than “specified”
at IPL time. Then CSA, which is specified, is bolted on the bottom and rounded
to the next Mb boundary.
Does anyone know of a programmatic way to determine the approximate size
that SQA would be at the next IPL assuming no more Activates are performed?
Is it simply a matter of counting the UCBs below 16Mb (via UCBSCAN?) and
multiplying by x’112’ as per HCD Planning manual?
Any pointers gratefully received.
Thanks
Andrew Metcalfe
Barclays Bank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Search the archives athttp://bama.ua.edu/archives/ibm-main.html

Hi Andrew,

I have met very recently with this kind of scenario though it was not
much IODF changes we just went to the zOS1.9 and started seeing IPL
fail with the wait state..opened PMR with IBM and found we would have
to go with the INITSQA in the LOADxx member since that is what being
used at the time of IPL and IEASYSxx member would not be used till the
time it reach there ...so no CSA overflow would happen....

I would suggest go with INITSQA of 1 MB or possible with 2...you
would not have problem..

If you would like to look at the wait state...just search on this
listserv with my id...you will find ..difficult to recall when you
have worked for 14 hours :-)

[Dave Barry]

Funny you should mention it. I was about to raise a similar question.

In PARMLIB, we have SQA=(600K,45M) and CSA=(3200K,400M). After a recent IPL, our ESQA went from 69,120K to 69,152 K. Our ECSA jumped from 409,616K to 410,608K while EPVT was reduced from 1,526,784K to 1,525,760K.

So I lost one Meg of extended private area. The problem is getting the numbers to add up. Init & Tuning is not helping me figure it out, although I suspect an increase in MAXUSERS from 1,000 to 1,200 (with CSCBLOC=ABOVE) may have had something to do with it.

If it were due to UCBs, wouldn't I expect to see the increase in HSA?

db
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Andrew Metcalfe
Sent: Wednesday, September 17, 2008 9:35 AM
To: IBM-***@BAMA.UA.EDU
Subject: Size Of SQA At Next IPL

Hello Listers

We only perform scheduled IPLs of our systems twice a year. During these 6 month periods, there is a large amount of IODF change implemented by dynamic Activate (by another team).

We have had a number of occasions when IPLing our systems where the Private area (below) has increased (not so much of a problem till folks start using it and I take it away again) or decreased (big problem as some applications won't start) as a result of the change in SQA size without a compensating change in the CSA= parameter in IEASYSxx to maintain the top boundary of Private.

The problem is caused by SQA size being "determined" rather than "specified"
at IPL time. Then CSA, which is specified, is bolted on the bottom and rounded to the next Mb boundary.

Does anyone know of a programmatic way to determine the approximate size that SQA would be at the next IPL assuming no more Activates are performed?
Is it simply a matter of counting the UCBs below 16Mb (via UCBSCAN?) and multiplying by x'112' as per HCD Planning manual?

Any pointers gratefully received.

Thanks

Andrew Metcalfe
Barclays Bank

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <***@njrarsvr3bf7.us.ups.com>,
on 09/18/2008

Post by Dave Barry
If it were due to UCBs, wouldn't I expect to see the increase in HSA?

No; UCB's are not in HSA. They're in the page-fixed virtual storage of
your operating system. Different z/OS images in the same CEC share the HSA
but may have different numbers of UCB's.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[John McKown]

Post by shmuel+ (Shmuel Metz , Seymour J.)
on 09/18/2008

Post by Dave Barry
If it were due to UCBs, wouldn't I expect to see the increase in HSA?

No; UCB's are not in HSA. They're in the page-fixed virtual storage of
your operating system. Different z/OS images in the same CEC share the HSA
but may have different numbers of UCB's.

Technically true, but there is some sort of structure in HSA for every
device. I don't know what it is called.
--
Q: What do theoretical physicists drink beer from?
A: Ein Stein.

Maranatha!
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Post by John McKown

Post by shmuel+ (Shmuel Metz , Seymour J.)
on 09/18/2008

Post by Dave Barry
If it were due to UCBs, wouldn't I expect to see the increase in HSA?

No; UCB's are not in HSA. They're in the page-fixed virtual storage of
your operating system. Different z/OS images in the same CEC share the HSA
but may have different numbers of UCB's.

Technically true, but there is some sort of structure in HSA for every
device. I don't know what it is called.

UCWs reside in HSA
UCBs reside in MVS memory (SQA)

It's possible to have UCW without corresponding UCB (and UCB without UCW
as well). First case may be desired configuration and not an error.
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

Post by R.S.
It's possible to have UCW without corresponding UCB (and UCB without UCW
as well). First case may be desired configuration and not an error.

The second case may be legitimate as well, e.g., for VIO.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Scott Rowe]

There is no need for a dummy UCB for VIO.

Post by R.S.
It's possible to have UCW without corresponding UCB (and UCB without UCW
as well). First case may be desired configuration and not an error.

The second case may be legitimate as well, e.g., for VIO.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change.

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

Post by Dave Barry
If it were due to UCBs, wouldn't I expect to see the increase in HSA?

There are still UCBs in each z/OS image.
You need something to schedule an I/O to.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Marchant]

Post by Dave Barry
In PARMLIB, we have SQA=(600K,45M) and CSA=(3200K,400M). After a recent

IPL, our ESQA went from 69,120K to 69,152 K. Our ECSA jumped from 409,616K
to 410,608K while EPVT was reduced from 1,526,784K to 1,525,760K.

Post by Dave Barry
So I lost one Meg of extended private area. The problem is getting the

numbers to add up.

It seems to me that the numbers add up just fine. ESQA increased by 32K.
Your specification for ECSA is 409,600K and when your ESQA increased by 32K,
your ECSA could not be reduced by 32K, so it was increased by 992K, for a
total ECSA+ESQA increase of 1024K, or 1M That equals your 1M decrease in EPVT.

[Dave Barry]

You're right, the numbers do add up, they just don't add up to 45M or 400M.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Tom Marchant
Sent: Friday, September 19, 2008 8:08 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Size Of SQA At Next IPL

Post by Dave Barry
In PARMLIB, we have SQA=(600K,45M) and CSA=(3200K,400M). After a recent

IPL, our ESQA went from 69,120K to 69,152 K. Our ECSA jumped from 409,616K to 410,608K while EPVT was reduced from 1,526,784K to 1,525,760K.

Post by Dave Barry
So I lost one Meg of extended private area. The problem is getting the

numbers to add up.

It seems to me that the numbers add up just fine. ESQA increased by 32K.
Your specification for ECSA is 409,600K and when your ESQA increased by 32K, your ECSA could not be reduced by 32K, so it was increased by 992K, for a total ECSA+ESQA increase of 1024K, or 1M That equals your 1M decrease in EPVT.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Marchant]

Post by John McKown

Post by shmuel+ (Shmuel Metz , Seymour J.)

Post by Dave Barry
If it were due to UCBs, wouldn't I expect to see the increase in HSA?

No; UCB's are not in HSA. They're in the page-fixed virtual storage of
your operating system. Different z/OS images in the same CEC share the HSA
but may have different numbers of UCB's.

Technically true, but there is some sort of structure in HSA for every
device. I don't know what it is called.

Yes, and HSA is outside of your virtual storage.

[Tom Marchant]

Post by Dave Barry
You're right, the numbers do add up, they just don't add up to 45M or 400M.

The I&T reference clearly says that the amount of ESQA will likely be more
than you specify, and that ECSA will be rounded up so that it will end on a
segment boundary. You didn't say how your common storage is being used.
You had your ECSA specified at a value just a little less than what was
allocated. Then all it took was a small increase in the size of your ESQA
to cause the extended common to increase by 1M.
--
Tom Marchant

Post by Dave Barry
-----Original Message-----

Of Tom Marchant

Post by Dave Barry
Sent: Friday, September 19, 2008 8:08 AM
Subject: Re: Size Of SQA At Next IPL

Post by Dave Barry
In PARMLIB, we have SQA=(600K,45M) and CSA=(3200K,400M). After a
recent

IPL, our ESQA went from 69,120K to 69,152 K. Our ECSA jumped from 409,616K

to 410,608K while EPVT was reduced from 1,526,784K to 1,525,760K.

Post by Dave Barry

Post by Dave Barry
So I lost one Meg of extended private area. The problem is getting the

numbers to add up.
It seems to me that the numbers add up just fine. ESQA increased by 32K.
Your specification for ECSA is 409,600K and when your ESQA increased by

32K, your ECSA could not be reduced by 32K, so it was increased by 992K, for
a total ECSA+ESQA increase of 1024K, or 1M That equals your 1M decrease in
EPVT.

Post by Dave Barry
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Barry]

Makes sense, Tom.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Tom Marchant
Sent: Monday, September 22, 2008 8:14 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Size Of SQA At Next IPL

Post by Dave Barry
You're right, the numbers do add up, they just don't add up to 45M or 400M.

The I&T reference clearly says that the amount of ESQA will likely be more than you specify, and that ECSA will be rounded up so that it will end on a segment boundary. You didn't say how your common storage is being used.
You had your ECSA specified at a value just a little less than what was allocated. Then all it took was a small increase in the size of your ESQA to cause the extended common to increase by 1M.

--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html