OPS/MVS

Expand all | Collapse all

Resizing SYSCHK1

  • 1.  Resizing SYSCHK1

    Posted 08-01-2016 11:16 AM

    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?



  • 2.  Re: Resizing SYSCHK1

    Posted 08-01-2016 12:18 PM

    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



  • 3.  Re: Resizing SYSCHK1

    Posted 08-01-2016 03:40 PM

    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).



  • 4.  Re: Resizing SYSCHK1

    Posted 08-01-2016 04:00 PM

    Sounds good Travi and you're welcome

    Thanks to you for participating in this forum.

    Regards, Cesar



  • 5.  Re: Resizing SYSCHK1

    Posted 08-02-2016 02:32 AM

    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



  • 6.  Re: Resizing SYSCHK1

    Posted 08-02-2016 09:27 AM

    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



  • 7.  Re: Resizing SYSCHK1

    Posted 08-03-2016 02:29 AM

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

    GLOBALUSED      7777
    GLOBALBLOCKSUSED14311   
    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



  • 8.  Re: Resizing SYSCHK1

    Posted 08-03-2016 09:32 AM

    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



  • 9.  Re: Resizing SYSCHK1

    Posted 08-04-2016 02:41 AM

    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.



  • 10.  Re: Resizing SYSCHK1

    Posted 08-04-2016 09:31 AM

    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.



  • 11.  Re: Resizing SYSCHK1

    Posted 08-04-2016 10:05 AM

    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



  • 12.  Re: Resizing SYSCHK1

    Posted 08-05-2016 02:04 AM

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