Resizing SYSCHK1

[Anon Anon]

I was looking to reduce the size of our GLOBALMAX parameter. Currently on our production system we have less that 250,000 blocks used according to the GLOBALBLOCKSUSED parameter. Our current GLOBALMAX parameter is set to an astronomical 4,500,000. When looking at the Storage Simulator (4.1.6) we noticed that reducing GLOBALMAX significantly reduced our storage usage. In my research, I determined that GLOBALMAX was related to the SYSCHK1 data set and came up with a few questions for clarifications:

 

When decreasing GLOBALMAX does SYCHK1 need to be physically resized or can it stay the same size just need to be reallocated for the new GLOBALMAX value?

 

If SYSCHK1 can stay the same size and I need to rename the data set to conform to naming standards can I do an IDCAMS REPRO while OPS is down and then start OPS with the new SYSCHK1?

 

Is there any method to reduce the size of the SYSCHK1 data set that isn't destructive?

[Cesar_Molina]

Hello Travi,

 

Some answers to your questions first.

 

You can decrease the current value of the GLOBALMAX parameter without having to physically resize the SYSCHK1 DIV dataset. To do it you need to specify the new lower vale in your OPSSPAxx parameter file and then restart OPSMAIN.

To rename the DIV file you need first bring down OPSMAIN then use IDCAMS ALTER to give it a new name. Make sure the OPSSPAxx parameter file contains the new name then simply restart OPSMAIN and confirm the task starts successfully.

To reduce the size of the SYSCHK1 DIV dataset you need to physically recreate it.

 

Now, look at your current GLOBALBLOCKSUSED and GLOBALFREE values. The sum of them should be already calculated in the GLOBALALLOC parameter. With this info you should be in a better position to choose a GLOBALMAX value. Consider that GLOBALFREE is not the number of free blocks in the entire SYSCHK1 DIV dataset. Is just the number of blocks that have been freed, but not reused yet by the task.

         

Travi, hopes this helps and let us know if anything else concerns.

Regards, Cesar

[Anon Anon]

Thanks Cesar. That is the confirmation I was looking for. Instead of using the IDCAMS ALTER, I already had DEFDIV handy so I just allocated a new SYSCHK1 data set with the new name and did the REPRO when I brought CA-OPS down. I brought OPS back up and everything looks fine. I am now using a much smaller GLOBALMAX (500,000).

[Cesar_Molina]

Sounds good Travi and you're welcome

Thanks to you for participating in this forum.

Regards, Cesar

[Marcel van Ek]

Cesar, while this may work with reallocating and repro, just lowering the GLOBALMAX won't work.

We have a test lpar that is the base for installing new lpars, and each time we copy over the SYSCHCK1 to the new lpar.

On the test GLOBALMAX is set to 200000, but on prod we tried to limit it to 70000. We always get this message at startup on those prod lpars:

OPS0185W GLOBALMAX value of 70000 is too low.  Reset to 200000. 

Even after deleting all unnecessary vars/rdf's ....

We've never succeeded in lowering GLOBALMAX without reallocating SYSCHCK1.

 

Marcel van Ek

Atos

[Cesar_Molina]

Hello Marcel,

Thanks for joining to the discussion

If the system where message OPS0185W can be produced is still available (after lowering GLOBALMAX down to 70000 and recycling the OPSMAIN Address Space) then give us a current reading of the following parameters via OPSVIEW option 4.1.1:

 

GLOBALBLOCKSUSED

GLOBALFREE

GLOBALALLOC

GLOBALMAX (should be at 200000)

GLOBALSIZE

 

When I provide the answers to Travi yesterday I used a low traffic system to test. Your system might have more activity so I would like to have your current values to see if the drop from 200K to 70K  in the GLOBALMAX plus your workload might have caused it. Also share with us when, during initialization or after a while, the message OPS0185W is posted.

 

Regards, Cesar

[Marcel van Ek]

Well , we have several lpars showing this phenomenon, here's one:

GLOBALUSED	7777
GLOBALBLOCKSUSED	14311
GLOBALFREEAREAS	140
GLOBALFREE	147943
GLOBALALLOC	162254
GLOBALMAX	200000
GLOBALUPDATE	38149

GLOBALCHECKUPDATES  38149   

GLOBALSIZE

50000K

and the msg comes out just after starting subtask GLVA:

OPS5002I TSOX subtask is active
OPS5002I TSOL subtask is active
OPS5002I TSOP subtask is active
OPS5002I USSX subtask is active
OPS0210H MRT INSTALLED
OPS0070H MSF installed
OPS0075I EPI subtask attached
OPS5002I MREX subtask is active
OPS5002I MFEX subtask is active
OPS5002I EPCM subtask is active
OPS0075I EPI installed
OPS5002I MRSV subtask is active
OPS5002I MRSV subtask is active
OPS0075I EPI INIT under main task POSTed - subtask active
OPS5002I GLVA subtask is active
OPS0185W GLOBALMAX value of 70000 is too low.  Reset to 200000.
OPS5002I SHFI subtask is active
OPS5002I AOFX subtask is active
OPS5002I ATMX subtask is active
OPS5002I OPSLOG subtask is active

 

Marcel van Ek

[Cesar_Molina]

Marcel.

 

Look only at your current values for GLOBALBLOCKSUSED (14,311) and GLOBALFREE (147,943).. The sum of them are already calculated in the GLOBALALLOC parameter as 162,254. Without reallocating the SYSCHK1 DIV file for this specific system you can not go any lower than 162,254 for GLOBALMAX. Schedule a test where the GLOBALMAX is reduced from 200K to 170K. You should no longer see the OPS0185W message but it will be a very tight system to work with. A value of 70K is simply too low since the number of blocks in use and what have been freed in the past but not reused yet by the task is a value larger than that. Those blocks are already allocated and GLOBALMAX needs to cover them event if a large section of them are not currently in use.

 

Let me know if this helps explain the situation better Marcel.

 

Regards, Cesar

[Marcel van Ek]

Yes, I  realize thy have been allocated in the past. The thing is: that was on another lpar. We've copied the data over into a new dataset, and then deleted all the irrelevant data for the new lpar. We know that we'll never hit that amount again on that new lpar, unfortunately, there's no way to ever release the previously allocated space...

 

regards,

 

Marcel.

[Anon Anon]

Marcel,

 

Why are you copying the SYSCHK1 over to the new LPAR in the first place? When I installed 12.1 and 12.2, I made sure each system was running it's own SYSCHK1 and OPSLOG data sets. These data sets never follow the installation from LPAR to LPAR. They may all be allocated the same but because they are different LPAR's, they will always have different information in them. I see this situation as being analogous to the situation of trying to run run two versions of OPS on one LPAR where each instance needs its own SYSCHK1 data set. Now, you should be able to reuse each SYSCHK1 on each LPAR provided that you don't decrease GLOBALMAX. It appears that the SYSCHK1 data set somehow holds onto that information and obviously OPS checks it on start up. I have noticed similar behavior in the OPSLOG data sets and the BROWSEMAX parameter. I defined an OPSLOG backed by an older data set which originally had a BROWSEMAX of 800,000. I defined it in option 4.13 with a BROWSEMAX of 2,950,000. However, when I activated it, the BROWSEMAX value went right back to 800,000.

[Cesar_Molina]

Marcel,

Your current procedure will not allow you to reclaim the unused allocated space. So you are correct GLOBALMAX can not go bellow the value of GLOBALALLOC without reallocating the SYSCHCK1 DIV.

Cesar

[Marcel van Ek]

Thanks Cesar. That's what i thought all along. I guess we should review our new lpar install procedure more closely....