HP OpenVMS Systems Documentation
The recommendations that follow were determined by compiling one set of very large HP COBOL modules on OpenVMS Alpha and I64. While your results may vary, the principles are generally applicable. For more detailed information on OpenVMS Alpha tuning, refer to the OpenVMS System Manager's Manual, particularly the sections on Managing System Parameters and Managing System Page, Swap, and Dump Files.
Note that many tuning exercises are more beneficial if you work with a
relatively quiet system, submit batch jobs, and retain the log files
for later analysis.
188.8.131.52 Optimizing Virtual Memory Usage
If your system does not have enough virtual memory allocated, the compile may fail, with the "%LIB-E-INSVIRMEM, insufficient virtual memory" error reported.
OpenVMS has two parameters that control the amount of virtual memory available to a process. One is the system generation parameter VIRTUALPAGECNT, which sets an upper bound on the number of pagelets of virtual memory for any process in the system. The other control is the AUTHORIZE parameter PGFLQUOTA, which determines the number of pagelets a process can reserve in the system's page file(s).
After an "insufficient virtual memory" error, you can issue the DCL command $SHOW PROCESS/ACCOUNTING to see the "Peak virtual size" used by the process (or look at the "Peak page file size" at the end of a batch job log file). If the peak size is at the system generation parameter VIRTUALPAGECNT, you will need to raise this value. If the peak size is below VIRTUALPAGECNT, and at or above PGFLQUOTA, run AUTHORIZE to increase PGFLQUOTA for the COBOL users. (Peak size can exceed PGFLQUOTA because some virtual memory, such as read-only image code, is not allocated page file space.)
It is difficult to predict precisely how much virtual memory will be required for a compilation, but a starting point for system tuning may be computed by multiplying 250 times the size of the largest program in disk blocks (including all COPY files referenced). Alternatively, multiply 25 times the number of lines in the program (including all COPY files).
The resulting figure can then be used as a starting point for the system generation parameter VIRTUALPAGECNT. Put that figure in the parameter file SYS$SYSTEM:MODPARAMS.DAT. For example, if you estimate 370,000 pages, add the following line in MODPARAMS, run AUTOGEN and reboot:
MIN_VIRTUALPAGECNT = 400000
If the compilation now completes successfully, use the command $SHOW PROCESS/ACCOUNTING to determine the Peak Virtual Size; if the actual peak is significantly less than the value computed above, you can reduce VIRTUALPAGECNT.
When modifying VIRTUALPAGECNT and PGFLQUOTA, you may also need to
increase the size of the page file.
184.108.40.206 Optimizing Physical Memory Usage
In any evaluation of your system's physical memory, two of the questions to consider are:
Is there enough memory on the system?
Is enough available to the process running the compilation?
The amount of physical memory required will vary, but it should be a large percentage of the process peak virtual size---as close to 100% as practical. The reason is that the compiler makes multiple passes over the internal representation of the program. A page that falls out of the working set in one pass is probably going to be needed again on the very next pass.
The physical memory present on the system can be determined by the DCL command $SHOW MEMORY/PHYSICAL. The physical memory used by the compilation is reported as "Peak working set size" by the command SHOW PROCESS/ACCOUNTING or at the end of a batch log file.
More physical memory can be made available to a process by minimizing the number of competing processes on the system (for example, by compiling one module at a time or by scheduling large compiles for off-peak time periods; late at night is a good time in some situations).
More physical memory can also be made available to a process (if it is present on the machine) by adjusting the system generation parameter WSMAX and the corresponding WSEXTENT (in AUTHORIZE). Approach such adjustments with great caution, as the system may hang if memory is oversubscribed and you create a situation where OpenVMS Alpha and OpenVMS I64 effectively have no options to reclaim memory. The following guidelines can help:
The effects of physical memory on compilation time were studied for a set of seven large modules. These modules ranged in size from approximately 1600 to 3300 disk blocks. Your results may differ, but to give a rough appreciation for the effect of physical memory on compilation time, note that:
Your results may differ from those shown in this section and will be strongly affected by the speed of the devices that are used for paging.
Note that the requirements for virtual memory and physical memory can
also be reduced by breaking large modules into smaller modules.
220.127.116.11 Improving Compile Performance with Separate Compilation (Alpha, I64)
The /SEPARATE_COMPILATION qualifier can improve compile-time
performance for large source files that are made up of multiple
separately compiled programs (SCPs). For programs compiled without this
qualifier, the compiler engine parses the entire compilation unit and
uses system resources (sized for the total job) for the duration of
this compilation. When you use the /SEPARATE_COMPILATION qualifier, the
compilation is replaced by a smaller series of operations, and memory
structures that are needed for individual procedures are reclaimed and
recycled. See Section 18.104.22.168 for additional information. <>
1.3.3 Choosing a Reference Format
You need to choose a reference format before you set out to write an HP COBOL program, and you must be aware of the format at compile time. The HP COBOL compiler accepts source code written in either terminal or ANSI reference format. You cannot mix reference formats in the same source file.
On OpenVMS, when copying text from Oracle CDD/Repository, the HP COBOL compiler translates the record descriptions into the reference format of the source program. <>
1 MB= megabytes