Document revision date: 19 July 1999
|
|
|
|
Guide to Creating OpenVMS Modular Procedures
A.1.5 Resource Allocation
- A procedure should not allocate static storage unless it is a
processwide, resource-allocating procedure, or unless it must retain
results for implicit inputs on subsequent invocations.
- Timing procedures and resource allocation procedures should make
statistics available for performance evaluation and debugging by
providing the entry points fac_SHOW_name and fac_STAT_name. (Optional.
See Section 4.3.)
- If a procedure uses a processwide resource, it calls the
appropriate resource allocating library procedure or system service to
allocate the resource to avoid conflict with allocations made to other
procedures. To conserve resources, a procedure that requests resource
allocation does one of the following:
- Calls the deallocation procedure before returning to the calling
program
- Remembers the allocation in static storage and calls the
deallocation procedure later
- Passes the responsibility for deallocation back to the calling
program
- Allocates a fixed number of the resources, independent of the
number of times it is called (See Section 2.4 and Section 3.1.3.)
A.1.6 Format and Content of Coded Modules
- Each module must be documented with a module description. (See
Section 2.5.1.)
- Each procedure must be documented with a procedure description.
(See Section 2.5.2.)
- When symbol definitions are to be coordinated between more than one
module (such as control blocks, procedure argument values, and
completion status codes), the definitions should be centralized in a
common source file. Note, however, that the modules must be written in
the same language. (See Section 3.1.2.)
- Procedure entry point names, module names, and PSECT names must
conform to the naming conventions. (See Section 3.1.1.2, Section 3.1.1.4,
and Section 3.1.1.5.)
- Digital recommends that you also adhere to the naming conventions
in choosing names for facilities and files. (Optional. See
Section 3.1.1.1 and Section 3.1.1.3.)
A.1.7 Upward Compatibility
When a new version of a procedure replaces an existing library
procedure, all new arguments should be added at the end of the call
sequence and made optional to maintain upward compatibility. (Optional.
See Section 2.2.5 and Chapter 6.)