HP OpenVMS Systems Documentation

HP COBOL
User Manual

If you allow duplicate keys in alternate indexes, the number and size of SIDRs depend on the number of duplicate key values in the file. (For duplicate key alternate index calculations, refer to the OpenVMS Record Management Services Reference Manual.) Because alternate index records are usually inserted in random order, the bucket packing efficiency ranges from about .5 to about .65. The following example uses an average efficiency of .55.

In each of the following calculations, the results are either rounded up or truncated.

The system requires at least two buffers to process an indexed file: one for a data bucket, the other for an index bucket. In fact, a data buffer and an index buffer are needed for every level of indexing available in the file (a fact that is not visible to the COBOL program, because the minimum amount of space is always allocated). Each buffer is large enough to contain a single bucket. If your program does not contain a RESERVE n AREAS clause, or if you do not use the DCL SET RMS_DEFAULT command, the system sets the default.

A RESERVE n AREAS clause creates additional buffers for processing an indexed file. At run time, the system retains (caches) in memory the roots of one or more indexes of the file. Random access to any record through that index requires one less I/O operation.

You can also use the SET RMS_DEFAULT/BUFFER_COUNT=count to create additional buffers.

The following rules apply for caching index roots:

• Allocate one buffer for each key that your program uses to access file records, in addition to the two required buffers. For example, if the file contains a primary key and two alternate keys, and you use all these keys to access records, allocate a total of five buffers. If you use only one key, you need only one additional buffer area, or a total of three.
• Use the RESERVE n AREAS clause to obtain allocation, where n is two more than the number of distinct keys used for access. For example, the RESERVE 5 AREAS clause allocates two required buffers, plus three buffer areas for caching the roots of three distinct file access keys.
• Use the DCL SET RMS_DEFAULT/BUFFER_COUNT=count command if you want to allocate buffers without specifying the RESERVE AREA clause in your program, or for buffer allocation on a process or systemwide basis.

The DCL SET RMS commands also apply to sequential and relative files. The DCL SET RMS commands and RESERVE AREA clause provide the same functionality.

For information about DCL commands, refer to the OpenVMS DCL Dictionary. <>

15.8 Image Activation Optimization (Tru64 UNIX)

Shared objects are checksummed when images are activated. If the checksum does not match, symbols will be re-resolved, extending image activation time for existing images. You can avoid this potential performance hit by relinking. Relinking can improve image activation time for any HP COBOL applications that were built -call_shared (which is the default). <>

HP COBOL provides compile-time mechanisms you can select to control run-time memory access. Effective memory management can improve:

• Compile-time performance
• Run-time performance
• Compatibility
• System resource usage

You place compiler command-line qualifiers and flags, and/or embedded directives in your source code to alter data alignment and to structure memory references. All such directives begin with the characters *DC, where the asterisk (*) signals the beginning of the structured comment to the compiler. You use these alignment directives exclusively in the Data Division. (If you compile this code on HP COBOL for OpenVMS VAX, a structured comment *DC directive is treated like any other comment and ignored.)

This chapter provides the following information about managing memory and data access:

• Managing memory granularity (Alpha, I64) ( Section 16.1)
• Using the VOLATILE compiler directive (Alpha, I64) ( Section 16.2)
• Aligning data for performance and compatibility (Alpha, I64) ( Section 16.3)
• Using alignment directives, qualifiers, and flags (Alpha, I64) ( Section 16.4)

You can control the HP COBOL compiler granularity to set the minimum size of a memory access. Granularity refers to the amount of storage that can be modified when updating a data item.

The form on Tru64 UNIX systems is:

-granularity option  <>

The form on OpenVMS Alpha and I64 systems is:

/GRANULARITY=option  <>

You can specify the following values for option:

• byte
• long
• quad (default)

To update a data byte, the HP COBOL compiler will issue a sequence of instructions to fetch the longword or quadword containing the byte, update the memory inside the longword or quadword, and then write the longword or quadword back to memory.

If different processes sharing memory try concurrently to update different parts of the same aligned quadword, this multi-instruction sequence can cause one of the updates to be lost. If you have multiple processes concurrently updating different bytes within the same aligned quadword, you should use byte granularity. Use longword granularity for better performance if you are sure the processes never make concurrent updates within the same aligned longword. Use quadword granularity for best performance if you are sure the processes never make concurrent updates within the same aligned quadword.

To successfully use byte/word granularity, you need to consider at least four important restrictions:

• An EV56 or higher CPU is necessary for byte/word granularity.
• LIBOTS.EXE support for byte/word granularity is necessary if PIC X support is needed. However, LIBOTS.EXE Version 1.3 on OpenVMS Alpha Version 7.1 does not support byte/word granularity.
• Use of PIC 9 COMP-3 (PACKED numerics) and PIC 9 (DISPLAY numerics) should be restricted, because they do not have byte/word granularity support.
• You need to evaluate any NONGRNACC diagnostics as potentional sources of incorrect data update. These warnings contain critical information and must not be ignored.

You should avoid the use of /GRANULARITY=BYTE unless all of these requirements are met.

In the following example (which is OpenVMS specific), the warnings at lines 16, 17, and 18 must be heeded. If this application is run on a CPU that supports byte/word granularity, the warning at line 16 (PIC X) indicates that the move will not produce byte granularity unless it is run on a system with a LIBOTS.EXE version that supports byte/word granularity. The warnings at line 17 (PIC 9 display numeric) and line 18 (PIC 9 COMP-3 packed numeric) indicate that these moves will not produce byte granularity.

$ cobol c3484/granularity=byte/list=sys$output
C3484   Source Listing   5-JUN-2004 07:37:22  HP COBOL V2.8-1060  Page 1

       1 identification division.
       2 program-id. c3484.
       3 environment division.
       4 data division.
       5 working-storage section.
       6 01 w1.
       7 03   a1   pic 9(9) comp.
       8 03   a2   pic 9(4) comp.
       9 03   a3   pic x(9).
      10 03   a4   pic 9(9).
      11 03   w2 occurs 3 times.
      12 05     a5 pic 9(18) comp-3.
      13 procedure division.
      14 0. move 1   to a1.
      15  move 2   to a2.
      16  move "c" to a3.
  ........1
%COBOL-W-NONGRNACC, (1) Unable to generate code for requested granularity

      17  move 4   to a4.
  ........1
%COBOL-W-NONGRNACC, (1) Unable to generate code for requested granularity

      18  move 5   to a5(2).
  ........1
%COBOL-W-NONGRNACC, (1) Unable to generate code for requested granularity

      19  if a1      not = 1   display "?1".
      20  if a2      not = 2   display "?2".
      21  if a3(1:1) not = "c" display "?3 ".
      22  if a4      not = 4   display "?4".
      23  if a5(2)   not = 5   display "?5".
      24  stop run.

VOLATILE directives offer flexibility and selectivity: they alter the current storage of certain data items by specifying new storage information from within the program source.

The SET VOLATILE directive enables you to direct that certain data items be stored in memory, rather than in machine registers. This technique is useful for declaring data that is to be accessed asynchronously. (Device driver applications often use volatile data storage.)

The forms of the VOLATILE directives are as follows:

    *DC SET VOLATILE
    *DC SET NOVOLATILE
    *DC END-SET VOLATILE

In your application you specify *DC SET VOLATILE to begin a range of data declarations with this attribute set. You terminate the volatile attribute range with the *DC END-SET VOLATILE (or *DC SET NOVOLATILE) directive. Subsequent declarations will not be affected.