HP OpenVMS Systems Documentation

Content starts here

User Manual

Previous Contents Index

15.5.3 Selecting Hypersort or SORT-32 for Sorting Tasks

Hypersort is a high-performance sorting tool. COBOL has Hypersort on both Alpha platforms: OpenVMS and Tru64 UNIX.

On Tru64 UNIX, Hypersort is the only method. <>

On OpenVMS Alpha, a different sorting method, SORT-32, is the default, but you can choose Hypersort instead for both sorting within COBOL and sorting at the DCL level. Refer to the DCL online help (type $HELP SORT) for details on the differences between the two sorting methods and instructions for switching between methods. <>

On OpenVMS VAX, only SORT-32 is available. <>

15.5.4 Minimizing USE Procedures with LINKAGE SECTION References

HP COBOL can perform certain optimizations if a program unit does not contain USE procedures that reference LINKAGE SECTION items. Note that USE procedures implicitly reference the following variables for any files associated with the USE procedures:

Record buffer

If you need to reference LINKAGE SECTION items in a USE procedure, try to limit the size of the program unit containing that USE procedure. HP COBOL will be able to perform more aggressive optimizations on all the other program units that do not contain the LINKAGE SECTION references in any USE procedures.

15.6 I/O Operations

HP COBOL provides methods of controlling actions taken by the I/O system during I/O operations. You have the choice of accepting the defaults the I/O system provides or using these optional methods to make your program more efficient.

The HP COBOL language elements that can specify alternatives to the I/O system defaults are as follows:

  • The APPLY clause in the I-O-CONTROL paragraph
  • The RESERVE n AREAS clause in the FILE-CONTROL paragraph
  • The SAME RECORD AREA clause in the I-O-CONTROL paragraph
  • The BLOCK CONTAINS clause in the FD entry

On OpenVMS, for additional information on the RMS terms and concepts included in this section, refer to the OpenVMS Record Management Utilities Reference Manual and the OpenVMS Record Management Services Reference Manual.

15.6.1 Using the APPLY Clause

On OpenVMS, the APPLY clause in the I-O-CONTROL paragraph of the Environment Division provides phrases that you can use to improve I/O processing. <>

On Tru64 UNIX systems, many elements of the I-O-CONTROL paragraph are for documentation only (accepted and ignored by the compiler), including the phrases described in this section. <>

For complete information on the APPLY clause and its phrases, refer to the I-O-CONTROL section of the Environment Division chapter in the HP COBOL Reference Manual. Using the PREALLOCATION Phrase of the APPLY Clause (OpenVMS)

By default, the system does not preallocate disk blocks. As a result, files can require multiple extensions of disk blocks. Although file extension is transparent to your program, it can reduce performance. To avoid a degradation in performance, use the APPLY PREALLOCATION clause to preallocate disk blocks.

Specifying APPLY PREALLOCATION preallocates noncontiguous disk blocks. When you specify the CONTIGUOUS-BEST-TRY phrase, the I/O system makes up to three attempts to allocate as many contiguous disk blocks as it can; it then preallocates remaining blocks noncontiguously. The CONTIGUOUS-BEST-TRY phrase minimizes disk space fragmentation and gives better system throughput than CONTIGUOUS.

The APPLY CONTIGUOUS (physically adjacent) clause makes one attempt at contiguous preallocation; if it fails, the OPEN operation fails. Use APPLY CONTIGUOUS if you require contiguous physical space on disk.

Contiguous files can reduce or eliminate window turning. When you access a file, the file system maps virtual block numbers to logical block numbers. This map is a window to the file. It contains one pointer for each file extent. The file system cannot map a large noncontiguous file: the file system may have to turn the window to access records in another extent. However, a contiguous file is one extent. It needs one map pointer only, and window turning does not take place after you open the file.

The following statements create a file (after OPEN/WRITE) and preallocate 150 contiguous blocks:

                  . Using the EXTENSION Phrase of the APPLY Clause (OpenVMS)

The format of APPLY EXTENSION is as follows:

APPLY EXTENSION extend-amt ON { file-name } ...

The APPLY EXTENSION clause is another way to reduce I/O allocation and extension time. Adding records to a file whose current extent is full causes the file system to extend the file by one disk cluster. (A disk cluster is a set of contiguous blocks; its size is determined when you initialize the volume with the DCL INITIALIZE command or when the volume is mounted with the DCL MOUNT qualifier: /EXTENSION=n.)

You can override the default extension by specifying the number of blocks in the APPLY EXTENSION clause. The APPLY EXTENSION integer becomes a file attribute stored with the file. Using the DEFERRED-WRITE Phrase of the APPLY Clause (OpenVMS)

The format of APPLY DEFERRED-WRITE is as follows:

APPLY DEFERRED-WRITE ON { file-name } ...

Each WRITE or REWRITE statement can cause an I/O operation. The APPLY DEFERRED-WRITE clause permits writes to a file only when the buffer is full. Reducing the number of WRITE operations reduces file access time. However, the APPLY DEFERRED-WRITE clause can affect file integrity: records in the I/O buffer are not written to the file if the system crashes or the program aborts. DEFERRED-WRITE is very useful on write-shared files. Using the FILL-SIZE ON Phrase of the APPLY Clause (OpenVMS)

The format of APPLY FILL-SIZE is as follows:

APPLY FILL-SIZE ON { file-name } ...

Use the APPLY FILL-SIZE clause to populate (load) the file and force the HP COBOL compiler to write records into the bucket area not reserved by the fill number. Routine record insertion uses the fill space, thereby reducing bucket splitting and the resulting overhead.

Do not use the APPLY FILL-SIZE clause for routine record insertion; it prohibits the use of bucket fill space and creates unnecessary buckets. Using the WINDOW Phrase of the APPLY Clause (OpenVMS)

The format of APPLY WINDOW is as follows:

APPLY WINDOW ON { file-name } ...

Window size is the number of file mapping pointers stored in memory. A large window improves I/O because the system spends less time remapping the file.

When a disk is initialized, the default window size is set by specifying the /WINDOW qualifier. You can override this qualifier with the APPLY WINDOW clause. However, avoid specifying too large a window size. Window size is part of the system's pool space, and a large window size could affect system performance. <>

15.6.2 Using Multiple Buffers

Multibuffering can increase the speed of I/O operations by reducing the number of file accesses. When a program accesses a record already in the I/O buffer, the system moves the record to the current record area without executing an I/O operation.

You can specify multiple buffering by using the RESERVE clause in the SELECT statement of the Environment Division. The RESERVE clause specification overrides the system default. (The system default is usually set by means of the DCL SET RMS_DEFAULT command.) The following example reserves six areas for FILE-A:


You can specify up to 127 areas in the RESERVE clause. In general, specifying from 2 to 10 areas is best.

15.6.3 Sharing Record Areas

The compiler allocates unique storage space in the Data Division for each file's current record area. Transferring records between files requires an intermediate buffer area and adds to a program's processing requirements.

To reduce address space and processing overhead, files can share current record areas. Specify the SAME RECORD AREA clause in the I-O-CONTROL paragraph of the Environment Division. Records need not be the same size, nor must the maximum size of each current record area be the same.

Figure 15-1 shows the effect of current record area sharing in a program that reads records from one file and writes them to another. However, it also shows a drawback: current record area sharing is equivalent to implicit redefinition. The records do not exist separately. Therefore, if the program changes a record defined for the output file, the input file record is no longer available.

Figure 15-1 Sharing Record Areas

Previous Next Contents Index