I am just looking for a quick survey to see what other shops have coded for the STCs for OPS/MVS. the MAIN, OSF, USS, etc.
After I upgraded from r12.1 to r12.3 my region size was way to small. I am just trying to see what might be a more reasonable size. For example, is using REGION=0M in your Shop? Or do you use something more like REGION=96M
Just trying to get a feel for REGION size specification on OPS/MVS STCs.
I do have a case open with CA OPS/MVS Support, but I wanted to see if customers might have some comment on this.
To summarize what we have already discussed in the open case we are working together it is normal to be impacted by an increase of storage after an upgrade to release 12.3 and it is caused mainly for the expansion of the OPMO Control Block. I have recently added in the Introduction section of the KD TEC1037203 most of our clients have already looked at, what is the delta in bytes for the Control Block in question.
This is a direct URL to the KD:
A tool to help estimate an appropriate REGION= size based on current storage impacting related parameters for the OPSMAIN region will be the use of the OPSVIEW option 4.1.6 'CA OPS/MVS Storage Simulator'.
Recommendation will be that for starters you should use REGION=256M as the smallest size for a OPSMAIN region.
This is a list of what we currently shipped our sample PROCs at this time:
CCLXCNTL(OPSMAIN) => REGION=4M
CCLXCNTL(OPSOSF) => REGION=4M
CCLXCNTL(OPSECF) => REGION=4M
CCLXCNTL(OPSUSS) => REGION=0M
CCLXCNTL(OPSLOGSV) => REGION=0M
CCLXCNTL(OPSWS) => REGION=0M
CCLXCNTL(OPSOFSRV) => No REGION= coded
CCLXCNTL(ARCHPROC) => No REGION= coded
Hope this helps start a discussion with the rest of the Community and how you would like to have this documented in our online product manuals in addition of what we have already out there.
Thanks Lizette for starting this discussion today.
You said this: Recommendation will be that for starters use REGION=256MB as the smallest for OPSMAIN region.
Did you really mean 256MB or was that a typo and should be 256KB? Wouldn't the samples, like CCLXCNTL(OPSMAIN) contain at least the minimum CA recommends (Sample has 4M in this case)? (or am I missing something and MB and M mean different things.)
Also 4.1.6 still isn't on the panels in 12.3 - thought that was supposed to be added (it is still hidden.)
Not sure how to really read 4.1.6 panel to say that our OPSMAIN, running with REGION=6M, is sufficient. We are not having any issues with REGION=6M, but only running this release for a couple of days now. Not sure how to verify that we are not close to any limits?
REGION=256MB was a typo and I have already corrected with REGION=256M in my prior update.
Due to the reasons I explained in my prior post the use of REGION=4M is not going to be sufficient for a OPSMAIN region to start under release 12.3. Your setup of REGION=6M might be sufficient to bring your system up but as workload kicks in you might experience storage related issues that will force you to either use REGION=256M or REGION=0M as Lizette is using right now. Keep in mind that the OPSMAIN Address Space can not alter its region size once it has started. My recommendations is to contact your System Programmers to determine if an exit like iefusi is in place to control region sizes in your site.
Sal, OPSVIEW option 4.1.6 is still hidden and we do our best to keep the code used to calculate storage utilization as much as accurate as possible. Perhaps taking snapshots of your current non release 12.3 systems and compare it with your current 12.3 systems could give you an idea how the enlarged OPMO Control Block (almost double) has impacted storage use in overall at different times of the day.
As Lizette explained this is a survey kind of discussion but I am happy to address your comments and different values your OPSMAIN Address Spaces are using for the REGION= parameter nowadays.
I understand that 4M is not sufficient, just don't understand why CA had not updated the procs, like CCLXCNTL(OPSMAIN) with a valid size? Did I miss it in the install guide/release notes that region size may need to be increased? I compared the CA supplied OPSMAIN procs between 12.2 and 12.3 - and since there were no changes, I had no idea we needed to consider it. I will be opening a ticket about this.
Cesar, in our shop testlpar 4.1.6 shows these totals (r12.2)
Total ................ ( 978 MB) 1025045749 Limit ................ ( 1712 MB) 1795162112
Still we have been running with Region=6M forever, never any storage problems.
Now in r12.3 on that same lpar I see:
Total ................ ( 1059 MB) 1110692575 Limit ................ ( 1712 MB) 1795162112
So indeed a considerable increase of storage, (and that is without any MSF links active in 12.3 whereas we have 34 in r12.2)
Still the REGION=6M was not (yet?) changed....
Is there maybe any other line I need to examine from 4.1.6?
Otherwise I don't see how it will help me here.
EDIT: Ok, on further investigation, the REGION=6M appears to just get 6M storage below the line.
So the User PVT = 6M, whereas I see the E-PVT here is 1.6Gb.
I guess we're fine.
Marcel van Ek
Many thanks for participating in this discussion.
Thanks for sharing your OPSVIEW 4.1.6 numbers across releases.
Glad to see how they show the difference caused by the enlarged OPMO Control Block.
I am assuming that all your storage related parameters across systems have the same value.
So this is exactly what I wanted to share in this thread for the rest of the Community to see.
In the case I am working with Sal he has confirmed that IBM iefusi is in place.
You might want to check this with your Sys Progs as well.
That will explain why the use of REGION=6M is valid for your system and why you are not seeing the storage related problems Lizette reported in the case I am working with her.
Again, thanks Marcel and Sal for participating.
Marcel alluded to a key point about the REGION= JCL parameter, if a value of anything other than 0M is specified, this value is only controlling the upper limit for GETMAIN requests BELOW the 16 megabyte line. And the storage that is available below the 16 megabyte line is very 'shop' dependent.
There are several factors involving the REGION= JCL parameter and I highly recommend that you search and read up on this parameter as there are too many details to go into in this type of forum.
If you would like to discuss your specific questions on the affect of the REGION parameter then please open a case and we can get into more detail involving your shop/LPAR's factors upon storage and OPS/MVS.