As a security measure, when an application receives the first task selection from a submitter, the application requests submitter authentication from the ACMS Central Controller (ACC) on the submitter node. This authentication checking ensures that malicious code cannot claim to be a valid submitter. If the application is on a node that is different from the node of the submitter (for example, a remote task selection), then auditing occurs on both the submitter and an application node. The audit trail record indicates the success or failure of task submitter attempts to select a task in a remote application. System authentication auditing provides a way to track the task activity of a task submitter selecting tasks in remote applications.

The following sections describe authentication auditing on submitter and application nodes.

12.7.1 Auditing on the Submitter Node

When the ACC on a submitter node authenticates a submitter for a remote application, an "authentication provided or rejected" record is audited. Here is an example of such a record:

********************************************************************* Type : LOGIN Time : 11-JUL-1991 09:23:24.73 User : JONES Term : LTA38: Sub : CARAT::00020033-00000000-1323F040-008E2DEB Text : Authentication provided to node CARAT for application PAYROLL **********************************************************************

This record indicates that on the submitter node (JONES) was authenticated for task selections in the remote application (PAYROLL on node CARAT).

Because the Audit Trail Logger audits remote task selections on the application node and not the submitter node, the Audit Trail Logger on a submitter node does not show task selections in remote applications. The record includes a pointer to the application node. The Audit Trail Logger on that application node can help you track task activity.

This record can indicate that either a submitter was not authenticated or was not signed in. Records that show a submitter was not authenticated may indicate that an unauthorized user tried to select a task. Records that show a submitter was not signed in may indicate that the submitter was canceled after a task selection was initiated to a remote application. An example of a record where the authentication was rejected follows:

********************************************************************* Type : LOGIN Time : 11-JUL-1991 09:23:24.73 User : Term : Sub : CARAT::00020033-00000000-1323F040-008E2DEB Text : Authentication rejected to node CARAT for application PAYROLL -ACMSACC-W-SUBNOTAUTH, Unable to authenticate submitter **********************************************************************

12.7.2 Auditing on the Application Node

When an application receives a task selection from a remote submitter for the first time, the application asks the ACC on the submitter node for submitter authentication. The Audit Trail Logger audits this request as an "authentication request" record. An example of such a record is shown in Example 12-11.

Example 12-11 Authentication Request Record

***************************************************************** Type : LOGIN Time : 11-JUL-1991 09:23:23.66 User : Term : Sub : CARAT::00020033-00000000-1323F040-008E2DEB Text : Submitter authentication request for application PAYROLL *****************************************************************

The authentication request record includes the submitter ID and the application that requests authentication.

After ACC on the submitter node authenticates the submitter, then an authentication success or failure record is audited. Example 12-12 contains an example of an audited success record for the application PAYROLL.

Example 12-12 Authentication Success Record

************************************************************************** (1) Type : LOGIN (2) Time : 11-JUL-1991 09:23:25.86 (3) User : ACMS_USER (4) Term : NL: (5) Sub : CARAT::00020033-00000000-1323F040-008E2DEB (6) Text : Successful submitter authentication for application PAYROLL of submitter CARAT::JONES **************************************************************************

The following is a description of the numbered items in Example 12-12.

1. Type
   Is the type of information in the record.
2. Time
   Specifies the time the record was created.
3. User
   Displays the user name associated with the remote submitter. The user name helps determine the access rights of the submitter (ACMS_USER) for all task selections in the application (tasks run as though they were selected by a local submitter with this user name). The user name is either an OpenVMS proxy or, if an OpenVMS proxy is not found, the default submitter user name (USERNAME_DEFAULT) as specified in ACMSGEN. See Chapter 6 for more information about authorizing remote access to ACMS applications.
4. Term
   Includes the login device associated with the submitter. For remote submitters, this device is used for display purposes only and is always NL.
5. Sub
   Includes the submitter ID assigned to the submitter upon sign-in. See Section 12.6.1 for more information about submitter and task identification codes.
6. Text
   Shows the node and remote user name of the task submitter (CARAT::JONES). It also shows the application that authenticated the submitter (PAYROLL).

An authentication failure record indicates that ACMS was unable to authenticate the submitter and that the submitter was denied access to the application. Example 12-13 contains an example of an authentication failure record.

Example 12-13 Audited Authentication Failure Record

********************************************************************** Type : LOGIN Time : 11-JUL-1991 09:23:25.86 User : Term : Sub : CARAT::00020033-00000000-1323F040-008E2DEB Text : Unsuccessful submitter authentication for application PAYROLL -SYSTEM-F-NOLINKS, maximum network logical links exceeded **********************************************************************

Authentication can fail for these reasons:

• There is no proxy for the remote submitter and no default submitter user name.
• The application cannot send the authentication request message to the submitter node because of a resource failure, as when maximum links for DECnet are exceeded.

When a known ACMS system on a remote node fails or is terminated, the failure or termination event is audited. A known remote ACMS system is one that is either a submitter node (submitters on the remote system are accessing applications on the local node) or an application node (submitters on the local system are accessing applications on the remote node).

The following is an example of a termination event:

************************************************************ Type : COMMAND Time : 16-FEB-1991 16:54:57.15 Text : Remote system stopped on node MARAT ************************************************************

The following is an example of a failure event:

************************************************************************ Type : ERROR Time : 16-FEB-1991 16:57:19.37 Text : Remote system no longer accessible on node CORDAY -SYSTEM-F-THIRDPARTY, network logical link disconnected by a third party ************************************************************************

12.8 System Messages from Other Products

ATR cannot translate message codes from any product other than TDMS or ACMS. Messages from products other than these are reported by message number. For example:

message number 000288664f

You can, however, cause ATR to translate messages from other products by using the DCL SET MESSAGE command and specifying the name of the product's system message file. For example:

$ SET MESSAGE SYS$MESSAGE:DBMMSG.EXE

To find out the name of another product's system message file, see the documentation for that product.

ATR commands help you create reports that include information in the audit trail log file. Table 12-2 lists the ATR commands and qualifiers and provides a brief description of each of the ATR commands. For a detailed description of the ATR commands and qualifiers, see Chapter 23.

Table 12-2 Summary of ATR Commands

Commands and Qualifiers	Description
EXIT	Ends the ATR session and returns you to the DCL prompt.
HELP /[NO]PROMPT	Provides online information about ATR commands.
LIST /APPLICATION=appl-name /BEFORE[=time] /BRIEF /IDENTIFICATION=task-id /OUTPUT=file-spec /SINCE[=time] /SUBMITTER=submitter-id /TASK=task-name /TERMINAL=device-name /TYPE=type /USERNAME=user-name	Displays or lists information from a source file. The output of this command is an ACMS log report consisting of audit trail records. With qualifiers, you can select the records to be included in the report.

This chapter describes the ACMS Software Event Logger (SWL) and tells you how to use Software Event Log Utility Program (SWLUP) commands to generate reports containing SWL error information. See Section 13.3 for a summary of SWLUP commands and qualifiers. For reference information on the commands described in this chapter, refer to Chapter 24.

13.1 How SWLUP Works

The SWL records internal software errors that occur during the execution of ACMS application programs. The SWL is part of the ACMS software installed on your system and is typically started automatically when you start ACMS. If you find that the SWL is not logging events, start the SWL by executing the ACMS startup procedure SYS$MANAGER:ACMSTART.COM. For example:

$ @SYS$MANAGER:ACMSTART.COM

SWL writes all event messages and software errors to the SWL log file. Each time an error occurs, ACMS writes a message to the SWL log file with the following information:

• System absolute time
• Process ID (PID)
• Process image name
• User name
• Process name
• Process UIC
• Program processor status longword at the time of the call
• Program counter of the event log routine call
• Standard VAX condition code
• Extended error information

The default SWL log file is SYS$ERRORLOG:SWL.LOG. To redirect the location of the SWL log file, use the logical name ACMS$SWL_LOG. You must define this logical as an executive mode system logical in order for the SWL process to create the file in an alternative location.

When you use this logical name, any pieces of the file specification contained in the equivalence name are used. Parts of the file specification not used take the SYS$ERRORLOG:SWL.LOG default.

If the use of the logical name results in a file that cannot be opened (for example, because of an incorrect directory or device), then SWL opens the SYS$ERRORLOG:SWL.LOG. If this happens, SWL also writes a message to the SWL log describing the problem with the logical name.

To read information in the SWL log file, you use SWLUP commands. SWLUP command qualifiers allow you to select information that appears in the report. For example, you can specify the following SWLUP command to list all software errors occurring before April 25, 1994.

SWLUP> LIST/SINCE=25-APR-1994

When you list your reports, specify an output file with the /OUTPUT qualifier, or let the output default to SYS$OUTPUT.

Use the /INPUT qualifier to cause SWLUP to read a file specification other than the default SWL log file or one specified by the logical name ACMS$SWL_LOG. If you do not use the /INPUT qualfier, SWLUP uses either the default SWL log file specification, or one specified by the logical name.

13.2 How to Run SWLUP

Use either of the following commands to run SWLUP:

$ RUN SYS$SYSTEM:SWLUP SWLUP>

or

$ MCR SWLUP SWLUP>

When you see the SWLUP> prompt, begin entering SWLUP commands. For example:

SWLUP> LIST/PROCESS_NAME=AT_HOME/SEVERITY=W,E/OUTPUT=AT_HOME.LIS

Use the HELP command to access online help information about SWLUP commands and qualifiers. Press [PF1] then [PF2] for access to a keypad of SWLUP commands. Press [Ctrl/B] to recall each SWLUP command you enter. To exit from SWLUP, use the EXIT command or press [Ctrl/Z].

Enter SWLUP commands from DCL level by using the following command to define SWLUP as a foreign command. When you enter this command interactively, you define SWLUP as a foreign command only for your current process. To define SWLUP as a foreign command permanently, place this command in your login command file:

$ SWLUP:==$SYS$SYSTEM:SWLUP

Once you define SWL as a foreign command, use SWLUP commands from DCL by preceding each command with the characters "SWLUP". For example:

$ SWLUP LIST

Table 13-1 provides a brief description of each of the SWLUP commands and lists the qualifiers for each command. For a complete description of the SWLUP commands and qualifiers, see Chapter 24.

Table 13-1 Summary of SWLUP Commands

Commands and Qualifiers	Description
@ (At sign)	Runs an indirect command file that contains SWLUP commands.
EDIT	Lets you edit the last SWLUP command you typed and lets you create an edit buffer into which you can enter SWLUP commands.
EXIT	Causes SWLUP to exit or ends the execution of a command file.
HELP /[NO]PROMPT	Provides online information about SWLUP commands.
LIST [ EVENTS ] /BEFORE[=time] /EVENT_CODE=event-code /FACILITY=facility-name /IMAGE=image-name /INPUT=file-spec /OUTPUT=file-spec /PRINT /PROCESS_NAME=process-name /SEVERITY=severity-code /SINCE[=time] /USER=user-name	Lists information selected by command qualifiers.
RENEW	Starts a new systemwide SWL log file.
SAVE	Writes the last command you typed to a file.
SET [NO]LOG	Enables or disables logging of any commands you type during a SWLUP session.
SET [NO]VERIFY	Enables or disables the printing of commands stored in an indirect command file. SWLUP sends output to your terminal.
SHOW CURRENT	Displays the name of the current log file opened by the SWL detached process.
SHOW LOG	Displays whether or not you are currently logging SWLUP commands and names the log file.
SHOW VERSION	Displays the current version of SWLUP on your terminal.
STOP	Stops the Software Event Logger detached process so that it can exit properly.