HP OpenVMS Systems Documentation

You can modify the access control list editor (ACL editor) by modifying and recompiling the ACL section file SYS$LIBRARY:ACLEDIT.TPU (the source file used to create the compiled ACL section file SYS$LIBRARY:ACLEDT$SECTION.TPU$SECTION). You can also create your own ACL section file.

Refer to the DEC Text Processing Utility Reference Manual for more information about writing and processing section files.

B.1 Modifying Variables in the ACL Section File

Table B-1 lists the ACL section file variables and their defaults.

If you modify any of the variables in Table B-1 or change any other part of the ACL section file, recompile the section file with the following command:

$ EDIT/TPU/NOSECTION/COMMAND=SYS$LIBRARY:ACLEDIT

Use the preceding command if you make changes directly to the source code file (SYS$LIBRARY:ACLEDIT) that creates the compiled ACL section file SYS$LIBRARY:ACLEDT$SECTION. If you add a private command file to the existing ACL section file, recompile the section file using the following command:

$ EDIT/TPU/SECTION=SYS$LIBRARY:ACLEDT$SECTION/COMMAND=CUSTOM_ACL.TPU

The compiled DECtpu ACL section file is placed in your current directory. To use the new section file, perform one of the following actions:

• Move the compiled section file, ACLEDT$SECTION.TPU$SECTION, to the SYS$LIBRARY directory. This changes the default ACL editor section file for all users.
• Keep the compiled section file in your directory and define the logical name ACLEDT$SECTION in your LOGIN.COM file to point to the file, as follows:

  $ DEFINE ACLEDT$SECTION yourdisk:[yourdir]ACLEDT$SECTION

Note that the default file type for the section file before compiling (the source file) is TPU, and the default file type for the compiled section file is TPU$SECTION.

For more information about writing and processing a DECtpu section file, refer to the DEC Text Processing Utility Reference Manual.

B.2 Using the ACL Editor CALL_USER Routine

The ACL editor CALL_USER routine is part of the shareable image SYS$LIBRARY:ACLEDTSHR.EXE. You can incorporate the ACL editor CALL_USER routine with its existing function codes into your own ACL section file, or you can write your own CALL_USER routine that recognizes a different set of function codes.

The ACL editor CALL_USER routine recognizes only those functions used by the ACL editor DECtpu section file. All other function codes are passed to a user-supplied CALL_USER routine; if the high-order word of the CALL_USER function code contains the ACL editor facility code (277 in decimal or 115 in hexadecimal), it is handled by the ACL editor CALL_USER routine. Otherwise, an attempt is made to locate a user-supplied CALL_USER routine. For more information about creating your own CALL_USER routine, see the description of the CALL_USER routine in the DEC Text Processing Utility Reference Manual.

Table B-2 describes the CALL_USER routine function codes supported by the ACL editor.

Table C-1 gives a summary of the system services that relate to accounting. No system service reads accounting files; to do this you must use knowledge of the structure of accounting files.

This appendix describes the structure of an accounting file. It is for programmers who want to access accounting data directly.

The symbols and offsets described in this appendix are defined by the $ACRDEF macro in the STARLET library.

C.1 Format of an Accounting File Record

An accounting record consists of an accounting record header and a number of information packets. The number and type of information packets depend on the type of the record.

Figure C-1 illustrates the general format of an accounting record. Table C-2 describes the fields in the record header. The type field in the record header is subdivided into five fields, described in Table C-3.

Figure C-1 Format of an Accounting Record

The type of an accounting record identifies the type of event that caused the record to be logged. The eight types of accounting records are shown in Table C-4. This table shows the information packets contained in each type of record.

The header, in each of the six types of information packets, defines the type of packet as follows:

• File name packet (ACR$K_FILENAME)
• Identification packet (ACR$K_ID)
• Image name packet (ACR$K_IMAGENAME)
• Print resource packet (ACR$K_PRINT)
• Resource packet (ACR$K_RESOURCE)
• User data packet (ACR$K_USER_DATA)

Section C.1.2.1 describes the general format of an information packet. Section C.1.2.2 to Section C.1.2.7 describe the format of each type of information packet.

C.1.2.1 General Format

Each information packet contains a packet header, followed by data fields. The data fields can contain fixed-length data, variable-length data, or offsets to variable-length data. Offsets contain the distance in bytes from the beginning of the packet to the variable-length data.

All variable-length data are represented as counted strings. Variable-length data follow the last fixed-length data field in the packet. Figure C-2 shows the general format of an information packet. An information packet may not have values in all of its data fields.

See Section C.1.2.2 to Section C.1.2.7 for complete descriptions of the data fields contained in each information packet.

All information packets start with a packet header that has ACR$W_LENGTH and ACR$W_TYPE fields (see Table C-5 and Table C-6).

Figure C-2 Format of an Information Packet

The file name packet contains the name of the accounting file. Figure C-3 shows the format of the file name packet. Table C-7 describes the field contained in the packet. See Section C.1.2.1 for information on the packet header.

Figure C-3 Format of a File Name Packet

The identification packet identifies the process that caused the record to be logged.

Figure C-4 shows the format of the identification packet. Table C-8 describes the fields contained in the packet. See Section C.1.2.1 for information on the packet header.

Figure C-4 Format of an Identification Packet