We have some JOBS/STEPS that can open around 100 VSAM datasets in one same STEP or JOB, for read and write processing. Some of those datasets can have 20,000,000 plus records. How will the REGION= be managed for out of memory conditions?
Article ID: 46189
Updated On:
Products
Issue/Introduction
We have some JOBS/STEPS that can open around 100 or more VSAM datasets in one same STEP or JOB, for read and write processing. Some of those datasets can have 20,000,000 plus records. How will the REGION= be managed for out of memory conditions?
What HB does to prevent out of memory conditions at OPEN time?
Environment
Component:
Resolution
Hyper-Buf utilizes internal buffering algorithms to determine buffer sizes based on the data sample it discovers at IDCAMS OPEN. Using the Constraint table settings and the data sample the best buffering model is utilized and changes are completed. Then control is released to IDCAMS. Hyper-Buf will not actually process data for read/write processing.
The DYNAMIC=YES option means that CA Hyper-Buf will also update the REGION= values in the JCL so the new buffer changes will allow the job to complete properly.
What HB does to prevent out of memory conditions at OPEN time?
CA Hyper-Buf does nothing to manage the system memory condition from either above or below the line. CA Hyper-Buf only manages the buffers and performance based on LSR/NSR settings in the Constraint table.
Consider the following parameters in effect:
DYNAMIC=YES
RMODE31=NONE
If DYNAMIC=YES is being used then the REGION= value in the jobcard will be changed to handle the new LSR/NSR buffer settings. Hyper-Buf would not know if there was sufficient memory available to execute the application
With RMODE31=NONE you are telling Hyper-Buf to not utilize 31 bit processing.
Additional Information:
For more details see page 56 of the User Guide titled RMODE31: Specifying VSAM Buffer and Control Block Residency
Feedback
