Why has Easytrieve run out of storage, below the line?
Article ID: 16520
Updated On:
Products
Issue/Introduction
Adding BUFNO to sequential files.
We have a compiled Easytrieve program, running in New Function mode, with a large number of sequential files. The program is linked as amode 31, rmode ANY. Why has the program run out of storage below the 16MB line?
We had just added BUFNO 5 to all the files. That's what pushed us over the limit.
Environment
Resolution
When you have the BUFNO on the file statement of
an Easytrieve program, where it is allocated is controlled by the
Options Table parameter of AMODE31 either being yes or no.
This is used at Runtime, for dynamic storage allocation. It would
be most efficient, if it was allocated above the line.
So this means AMODE31 is where the dynamic storage allocations is
placed either above or below the line.
If AMODE31=YES, then the dynamic storage allocation will be above the
16MB line.
AMODE31 is used at execution time for Dynamic Storage Allocation,
which is not a factor at compilation time.
BUFNO specified on FILE statement will be the highest in terms of precedence.
Next order of precedence is the Options table setting. Third and final order
of precedence is any setting you may have for buffering on the JCL of the
file itself.
Additional Information
We worked around it by explicitly closing files.
Also we had a user add CALL(AMODE31) to program PARM. That worked.
BUFNO as defined in the Easytrieve r11.6 Installation Guide.
We recommend that you specify the number of I/O buffers for each sequential file by using the BUFNO option. You can override the Options Table value through the BUFNO parameter of the FILE statement. The default BUFNO is 2. You can specify BUFNO from 0 to 255.
Business Value:
Specifying more buffers for a large sequential file permits your job to run faster.
Additional Considerations:
VFM and VSAM files do not use the BUFNO information.
Feedback
