Document revision date: 30 March 2001

• To be AST reentrant, a procedure must execute correctly while allowing any procedure (including itself) to be called between any two instructions. The other procedure can be an AST-level procedure, a condition handler, or another AST-reentrant procedure. (See Section 3.3.)
• A procedure that uses no static storage and calls only AST-reentrant procedures is automatically AST reentrant. (See Section 3.3.3.)
• If a procedure uses static storage, it must use one of the following methods to be called from AST and non-AST levels:
  • Perform access and modification of the database in a single uninterruptible instruction. This can be done only from VAX MACRO, and emulated instructions are not allowed. (See Section 3.3.4.1.)
  • Detect concurrency of database access with test and set instructions at each access of the database. (See Section 3.3.4.2.)
  • Keep a call-in-progress count incremented upon entry to the procedure and decremented upon return. (See Section 3.3.4.3.)
  • Disable AST interrupts on entry to the procedure and restore the state of the AST enables on return. (See Section 3.3.4.4.)
• If a procedure performs I/O from the AST level by calling RMS $GET and $PUT system services, it must check for the record stream active error status (RMS$_RSA). If this error is encountered, the procedure issues the $WAIT system service and then retries the $GET or $PUT system service. (See Section 3.3.5.)
• A procedure should not depend on AST interrupts being disabled to execute correctly if there are other coding methods available. For example, RMS completion routines are implemented via ASTs and will not work if ASTs are disabled. (See Section 3.3.)

• 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.)

• 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.)
• Compaq 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.)

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.)

	privacy and legal statement
4518PRO_007.HTML