Document revision date: 15 July 2002

An Identifier ACE controls the types of access allowed to a particular user or group of users. It has the following format:

(IDENTIFIER=identifier[,options][,access])

For example, the following ACE grants user Pat, who is identified by the UIC identifier [SALES,PAT], read, write, and execute access to a file. The ACL denies Pat delete and control access because it omits them from the access statement.

(IDENTIFIER=[SALES,PAT],ACCESS=READ+WRITE+EXECUTE)

The Default attribute of an Identifier ACE allows users to define one or more default ACEs for inclusion in the ACLs for newly created files in a particular directory. Thus, if you wanted all files in the directory [MALCOLM] to have an ACE that permitted read and write access to users with the PERSONNEL identifier, you could include the following ACE in the ACL for the file MALCOLM.DIR:

(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE)

As a result of this ACE, any file created in the [MALCOLM] directory has the following ACE:

(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)

Refer to the OpenVMS Guide to System Security for further discussion of the Default attribute and its effect on the processing of an ACL.

12.8.2 Setting a Default Protection Code

A Default Protection ACE defines a protection code for all files that are subsequently created in the directory and in any subdirectories under that directory, unless protection is specified for one of those files individually. The ACE does not apply if a previous version of the file exists (in this case, the previous file protection is used). This ACE type has the following format:

(DEFAULT_PROTECTION[,options],protection-code)

For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory, and that group and world users have no access:

(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W)

Security ACEs allow you to specify that an event message be sent when a protected object is accessed in a particular manner. The security Alarm ACE directs the event message to the security operator's terminal and the security Audit ACE directs the event message to the system security audit log file.

Refer to the OpenVMS Guide to System Security for more information about how to use these types of ACEs.

12.9 Auditing Security-Relevant Events

System managers can select the destination for security-relevant event messages. Alarm messages are sent to the operator's terminal and audit messages are sent to the system security audit log file. You can choose to have an event reported as an alarm, as an audit, or as both.

12.9.1 Enabling Classes of Security Alarms

The OpenVMS operating system automatically monitors a certain number of events, as listed in Table 20-7.

You can enable additional classes of events by listing one or more of the keywords of the /ENABLE qualifier to the DCL command SET AUDIT listed in Table 12-1.

Table 12-1 Kinds of Security Events OpenVMS Can Report

Event Class	Description
Access	Specifies access events for all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.
ACL	Events requested by a security Audit or Alarm ACE in the access control list (ACL) of an object.
Authorization	Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.
Breakin	Break-in attempts.
Connection	Logical link connections or terminations through SYSMAN, DECnet for OpenVMS Phase IV, DECwindows products, or an interprocess communication (IPC) call.
Create	Creation of a protected object.
Deaccess	Deaccess from a protected object.
Delete	Deletion of a protected object.
Identifier	Use of identifiers as privileges.
Install	Modifications made to the known file list through the Install utility.
Logfailure	Failed login attempts.
Login	Successful login attempts.
Logout	Logouts.
Mount	Volume mounts and dismounts.
NCP	Modification to the network configuration database, using the network control program (NCP).
Privilege	Successful or unsuccessful use of privilege.
Process	Use of one or more of the process control system services.
SYSGEN	Modification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.
Time	Modification of system time.

Refer to the OpenVMS DCL Dictionary for more information about the SET AUDIT command.

12.10 Analyzing Audit Log Files

The Audit Analysis utility (ANALYZE/AUDIT) enables system managers and site security administrators to selectively extract and display information from security audit log files. Using ANALYZE/AUDIT qualifiers, you can choose from among a variety of report formats and select the event criteria to be included in the report. Refer to the OpenVMS Guide to System Security for a description of how to use the utility.

Before you can create and start queues, you must set up the queue manager and the queue database. This chapter tells how to set up and manage the queue manager and queue database for the OpenVMS batch and print queuing system.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Specifying the location of the queue database	Section 13.3
Displaying information about queue managers	Section 13.4
Starting the queue manager and creating the queue database	Section 13.5
Customizing queue manager failover	Section 13.6
Stopping and restarting the queue manager	Section 13.7
Using multiple queue managers	Section 13.8
Saving and restoring the queue database	Section 13.9
Maximizing queuing system performance	Section 13.10
Solving queue manager problems	Section 13.11
Reporting a queuing system problem to Compaq	Section 13.12

This chapter explains the following concepts:

Concept	Section
The queue manager	Section 13.1
The queue database	Section 13.2
Multiple queue managers	Section 13.8.1

Note that this chapter contains many references to DCL commands. You can find additional information about all DCL commands in the OpenVMS DCL Dictionary.

13.1 Understanding the Queue Manager

To use a printer or batch processing on your system, you must use queues. The queue manager controls queue activity. The queue database consists of a master file as well as queue and journal files, which store information about queues and jobs.

Before you can perform any queue operation, you must start the queue manager and create the queue database. Section 13.5 contains instructions for doing this.

Figure 13-1 illustrates how the queue manager works to manage queue activity in an OpenVMS Cluster environment.

Figure 13-1 OpenVMS Batch and Print Queuing System

When a user submits a batch or print job to a queue, the queue manager performs the following tasks:

1. Receives the user's queue request, including information about the type of job, the file name or names, the name of the queue, and any special options.
2. Stores and retrieves appropriate information from the queue database to print or execute the job.
3. Places the job in the appropriate queue to await its turn for processing:
   1. Print jobs are sent to an independent process, called a symbiont, for formatting and are then sent to the printer for printing.
   2. For batch jobs, the job controller creates a batch job process.

One or more queue manager processes control queuing for all processes on a node or in an OpenVMS Cluster environment. Jobs can be submitted from one node and executed on a queue running on another cluster node. User processes, symbionts, and job controllers on each node communicate directly with queue managers.

In addition, the job controller works with the queue manager to perform the following queue management tasks:

• Create and monitor batch, symbiont, and queue manager processes
• Restart the queue manager process on reboot
• Handle failover of the queue manager in an OpenVMS Cluster environment

Queue Manager Failover

By default, in an OpenVMS Cluster environment, the queue manager tries to fail over to another node if the node on which the queue manager is running leaves the cluster.

You can specify the order in which OpenVMS Cluster nodes claim the queue manager process; you can also limit the nodes that can run the queue manager. For more information, see Section 13.6.

Multiple Queue Managers

To work around CPU, disk space, or memory limitations, you can use multiple queue managers to distribute the batch and print work load among nodes as well as to distribute the database files among disks.

For example, you might create separate queue managers for batch queues and print queues. Run the batch queue manager on one node and the print queue manager on a different node. You can also maintain queue and journal files on separate disks.

For information about creating additional queue managers, including reasons and restrictions for using multiple queue managers, see Section 13.8.

13.2 Understanding the Queue Database

The queue database contains files that store information used to keep the queuing system operating, including information about jobs, queues, and the queue manager. The queue database for the default queue manager, SYS$QUEUE_MANAGER, is made up of the following files:

File	Description
Master file, QMAN$MASTER.DAT	Contains: The location of the queue and journal files Definitions of forms and characteristics A list of queue names A list of nodes allowed to run the queue manager A list of queue managers and a list of nodes allowed to run the queue managers
Queue file, SYS$QUEUE_MANAGER.QMAN$QUEUES	Contains the queue definitions formed when you create, start, or modify queues.
Journal file, SYS$QUEUE_MANAGER.QMAN$JOURNAL	Contains information allowing the queue manager to return to the last known state if: A standalone machine stops unexpectedly An OpenVMS Cluster node that is running the queue manager leaves the OpenVMS Cluster environment The journal file also contains job definitions.

On systems with multiple queue managers, the queue database contains an additional queue file and journal file for each additional queue manager. Additional queue files are named in the format name_of_manager.QMAN$QUEUES. Additional journal files are named in the format name_of_manager.QMAN$JOURNAL.

Figure 13-2 shows a queue database containing a master file that lists two queue managers, PRINT_MANAGER and BATCH_MANAGER. Each queue manager has its own queue and journal files.

Figure 13-2 Queue Database

SYS$COMMON:[SYSEXE] is the default location for all queue database files. However, you can store the files in another location. The next section explains why and how to do this.

13.3 Specifying the Location of the Queue Database

You might need to specify a location for queue database files other than the default location of SYS$COMMON:[SYSEXE] for one of the following reasons:

• In an OpenVMS Cluster environment with multiple system disks, the default location does not work because it has a different physical location on each system disk. You need to store the files on a disk that is shared by all cluster member nodes.
  You must also make sure the disk holding the master file, QMAN$MASTER.DAT, is available to all nodes using the queue database at the beginning of system startup.
• To save space on the system disk or to help improve performance. Moving just the queue and journal files is usually sufficient.

Ways to Move Queue Database Files

You can move queue database files in either of the following ways:

• When you create the queue database files the first time, create them in an alternate location:
  1. Define the logical name QMAN$MASTER in the SYLOGICALS.COM command procedure (to specify where the master file is to be created).
  2. Start the queue manager with the START/QUEUE/MANAGER command, specifying the dirspec parameter (to specify where the queue and journal files are to be created).
  
  For detailed information, see Section 13.5.
• If you previously created the files in the default location:
  1. Stop the queue manager.
  2. Copy the files to the new location.
  3. Verify that the files have been successfully copied to the new location, and then delete the files in the old location.
  4. If you move the master file, define the logical name QMAN$MASTER on all nodes (to specify where the master file is located), and add this logical name definition to SYLOGICALS.COM on all nodes.
  5. Restart the queue manager with the START/QUEUE/MANAGER command, specifying the dirspec parameter (to specify where the queue and journal files are located).

Section 13.3.1 explains how to specify the location of the master file; Section 13.3.2 explains how to specify the locations of queue and journal files.

13.3.1 Specifying the Location of the Queue Master File

To specify the location of the queue master file, perform the following steps before starting the queue manager:

1. Enter a command in the following format:

   DEFINE/SYSTEM/EXECUTIVE_MODE QMAN$MASTER equivalence-name

   
   where equivalence-name specifies the device and directory where the master file is to be created or located.
   In an OpenVMS Cluster environment, enter this command on every node in the cluster.

   Note In an OpenVMS Cluster environment, the directory you specify for the master file must be available to all nodes in the cluster. If the directory specification is a concealed logical name, you must define it identically on all nodes in the cluster; you must also mount the disk on all cluster member nodes early in system startup.

2. On every node in the OpenVMS Cluster environment, add the command that you entered in step 1 to SYS$MANAGER:SYLOGICALS.COM.
3. If the location you specify is on a disk other than the node's system disk, add a command in SYLOGICALS.COM to mount the disk. SYLOGICALS.COM is normally used to define logical names; however, it is important that SYLOGICALS.COM contain the command to mount the disk holding the master file so that the master file is available before the job controller starts the queue manager.
   For more information about defining systemwide logical names in SYLOGICALS.COM, see Section 5.2.5.

Specify the location of queue and journal files with the dirspec parameter to the START/QUEUE/MANAGER command. For example:

$ START/QUEUE/MANAGER DUA2:[SYSQUE]

This command specifies that the queue and journal files are to be located in the directory DUA2:[SYSQUE].

The directory location you enter with START/QUEUE/MANAGER is stored in the queue database master file and becomes the default. Therefore, if you must restart the queue manager, you do not need to respecify this directory location.

13.4 Displaying Information About Queue Managers

To obtain information about one or more queue managers, enter the SHOW QUEUE/MANAGERS command.

Examples

1. The following example displays default (/BRIEF) information about two queue managers, PRINT_MANAGER and SYS$QUEUE_MANAGER.

   $ SHOW QUEUE/MANAGERS Queue manager PRINT_MANAGER, running, on NODEA:: Queue manager SYS$QUEUE_MANAGER, running, on NODED::

2. Use the /FULL qualifier to display complete information about queue managers on the system or cluster.
   In the following example, the master file is in one location, while the queue and journal files belonging to two queue managers are in a different location.

   $ SHOW QUEUE/MANAGERS/FULL Master file: SYS$SPECIFIC:[SYSEXE]QMAN$MASTER.DAT; Queue manager PRINT_MANAGER, running, on NODEA:: /ON=(NODEA,NODEB,*) Database location: DUA2:[SYSQUE] Queue manager BATCH_MANAGER, running, on NODED:: /ON=(NODEC,NODED,NODEE,*) Database location: SYS$SYSROOT:[SYSEXE]

Figure 13-3 shows the locations of the queue database files shown in the second example.

Figure 13-3 Locations of Queue Database Files

	privacy and legal statement
6017PRO_055.HTML