This section explains how to monitor and interrogate a UDS environment. It also explains what to do when an error occurs to help you return to normal operations. Section 5 and Section 6 deal further with errors and abnormal conditions.
More specifically, this section explains how to
• Verify a recovered and active application group
• Verify an open audit trail for the application group
• Verify access to UDS
• Monitor the status of active threads
• Monitor UDS events such as security violations to the system log file and access to database files
• Verify the creation of a new cycle of the dump file for the application group
• List bank descriptor indexes (BDI) associated with the UDS alternate file common bank (AFCB) and fixed-gate subsystem files installed by SOLAR and the bank attributes associated with each BDI
• Display the status of UDS files with file description tables (FDT)
• Report information on backup dumps and audit trails from the IRU dump history file and move history file
• Determine the security status of files associated with UDS
Monitoring UDS During Normal Operations
3.1.
Verifying Recovered and Active Application
Group
Use the following keyin to verify that application group 3 is recovered and running:
@@cons ap 3 fs Notes:
• If an application group is switchable, the keyin and statuses differ from the
standard keyin and statuses shown below. For an explanation of the changes to the standard keyin and responses, see the Partitioned Applications Planning,
Installation, and Operations Guide.
• If an application group is concurrent, the keyin and statuses differ from the
standard keyin and statuses shown below. For an explanation of the changes to the standard keyin and responses, see the XTC Planning, Migration and
Operations Guide.
• For more information on keyins, see the Exec Operations Reference Manual.
The response follows in the format
APP3 status usage steps recovery mcbstatus datetime
where:
status
is the state of the application group, as follows:
UP The application group is up (enabled). DN The application group is down (disabled).
RCV Recovery is in progress for the application group. NOT CONFIGURED The application group is not configured. In this case,
the remainder of the line is not displayed.
usage
is the percentage of queue items in use (that is, not on the free chain).
steps
is the total number of queue items on the active and commit-in-progress lists displayed if the application group is up, in the form
PRG:n
where n is a 1- to 6-digit decimal number that corresponds to the number of application group program activities executing within a step.
If the application group is disabled or has a recovery in progress or if the Message Control Bank (MCB) or Data Management Routine (DMR) has an abort in progress, the status of IRU appears is in the form
Monitoring UDS During Normal Operations
where status has one of the following values: PND IRU execution is pending. INP IRU execution is in progress.
recovery
is the type of application group recovery executed displayed in the form
REC:type
where type is one of the following types:
INIT The application group was initialized.
SUTIL Exec and IRU used information from the older half of the periodic savefile and audit trail to recover the application group.
REBLD Exec used information from the periodic savefile and the audit trail to recover the application group.
PANIC Exec used information from the panic dump to recover the application group.
Blank The application group is either disabled or recovery is in progress.
mcbstatus
is the status of MCB, which is one of the following values: DN MCB is down (disabled).
UP MCB is up.
AIP MCB has an abort in progress. Absent The application is down.
This field is omitted when the application group does not have a tree structure configured.
datetime
is the date and time when the keyin was processed in the format
yymmdd hhmmss
where:
yymmdd is year, month, and day.
hhmmss is hour, minutes, and seconds.
The AP n FS keyin is rejected if the application group number is greater than the highest configured application group. The following error message appears:
Monitoring UDS During Normal Operations
Either status type keyin is rejected if the syntax is incorrect, such as when the application group number is not completely composed of numerals (where required), or the key word FS is misspelled, misplaced, or missing. The following message appears:
APP KEYIN ERROR: IMPROPER SYNTAX
During normal operations, the application group is in an UP state with SUTIL as the type of application group recovery used. The number of program activities executing within a step (PRG:n) fluctuates as user programs access and depart UDS. Repeated use of the AP 3 FS keyin shows this fluctuation.
The AP keyin can be executed from the system console or from a workstation. You need sufficient CONS keyin privileges to check the status of configured application groups from a demand terminal.
SUTIL appears as the type of application group recovery if a valid periodic savefile existed on the system when the application group was last recovered. SUTIL is always the method of application group recovery used during normal UDS operation.
INIT means that step control is initializing queue item storage and the periodic savefile. The system does not attempt to recover messages and databases. On an initial boot when the periodic savefile does not contain recovery information, INIT is the correct entry for initializing the default application group.
If you must use IRU short recovery to recover the retention file, you must specify SUTIL; if you or the operator specifies INIT to recover the default application group, your database can become corrupted.
UDS Control uses mass storage retention files to hold data accessed during a UDS abort or system failure.
If MCB is installed in this application group, the status of MCB is UP. If MCB is not installed in this application group, the status of MCB is DN.
For more information, see the Universal Data System Configuration Guide and the
Monitoring UDS During Normal Operations
3.2.
Logging UDS Events
As an option, you can monitor UDS Control, RDMS, DMS, and UREP for
• Access to UDS database files
• Attempted security violations to UDS Control
• Specific security violations to DMS and RDMS
• Specific authorizations to DMS databases
• UREP security authorizations and violations
When a database access or a security violation occurs, UDS Control, RDMS, DMS, or UREP create log entries in the system log through ER SYSLOG$. You use the
TeamQuest Log Analyzer (LA) processor to display the contents of log entries and to generate reports based on information in the system log.
In particular, the LA processor SECURITY report displays security-related log entries. For information about this report, see the LA Administration and End Use Reference
Manual.
You can activate UDS security logging on individual application groups by setting the following parameters on the UREP PROCESS CONFIGURATION command:
• LOG-AUTHORIZATION-AND-ACCESSES
ON activates security authorizations and database access logging; OFF turns off security logging.
Default: OFF
• LOG-SECURITY-VIOLATION
ON activates security violation logging. Default: OFF
For more information about UDS product configuration, see the Repository for
Monitoring UDS During Normal Operations
3.3.
Verifying Open Audit Trail for Application
Group
Use the following keyin to verify that the audit trail for application group 3 is open (that is, ready for use):
@@cons at 3 fs
Note: If an application group is switchable (that is, configured as SHARED), the keyin and statuses differ from the standard keyin and statuses shown below. For an explanation of the changes to the standard keyin and responses, see the Partitioned
Applications Planning, Installation, and Operations Guide.
You get responses similar to the following:
AT 3 OP
AT 3 L1 FIX(29,90) 38% PL:A1 1919:57 AT 3 L1 BLK 844 TBSN 843 1919:57 AT 3 L2 FIX(29,92) 38% PL:A2 1920:02 AT 3 L2 BLK 844 TBSN 843 1920:02
AT 3 S1 FIX(6,24) PL:A1 *SPARE* 1920:05 AT 3 S2 FIX(6,275) PL:A2 *SPARE* 1920:05
where:
L1 is the leg-id for leg 1 of a duplex audit trail. L2 is the leg-id for leg 2 of a duplex audit trail. BLK is the file block number.
FIX means fixed mass storage media. TBSN is the trail block sequence number.
During normal operations, the status of the audit trail is open (OP). As audited information is written to the audit trail, the F-cycles and TBSN increase in value.
The AT keyin can be executed from the system console or from a workstation. You need sufficient CONS keyin privileges to check the status of an audit trail from a workstation.
This example displays information for a duplex mass storage audit trail.
In the preceding example, leg 1 has 29 cataloged F-cycles and is using absolute
F-cycle 90. Absolute F-cycle 90 is 38 percent full. If the maximum number of cataloged F-cycles is reached (the system default is 32) for a mass storage audit file, the system console operator is prompted to either allow the next F-cycle to be cataloged or not.
Monitoring UDS During Normal Operations
Allowing F-cycle wraparound destroys the oldest cataloged F-cycle, thus deleting audit data. If you use a mass storage audit trail, you can use the IRU MOVE command to archive the audit trail to tape before this occurs.
For more information about F-cycle wraparound for the audit trail file, see “Audit Control Files” in Section 2.
3.4.
Verifying Access to UDS
Executing UREP begins a thread in UDS.
The following session enters UDS through UREP and verifies access to UDS by performing a task to verify normal UDS operations:
@dd,e ,,udssrc UREP 8R1 (04/01/02 12:34:56) 01/04/02 12:34:56 report schema tcs. 1 report schema tcs. **DESCRIPTION REPORT** SCHEMA TCS urep exit. 2 exit.
Monitoring UDS During Normal Operations
3.5.
Monitoring Status of Active Threads
To observe UDS thread activity, execute the UDS supervisor program (SUDS):
@uds$$src*abs$.suds
When used at a workstation, SUDS requires a 2-character command to interactively retrieve information from an application group.
SUDS resides in the UDS Control absolute file (UDS$$SRC*ABS$ in this example) on the UDS Control release tape.
When SUDS is executed, it solicits a 6-character application group name. The application group name determines which active application group to monitor.
The following sequence uses two SUDS commands, RC and LS, to observe user activity in the default application group, UDSSRC:
@uds$$src*abs$.suds,d
INPUT APPLICATION NAME (6 CHARS)
udssrc
INPUT FUNCTION
rc
ORG-ID/GEN-ID TIME SEQUENCE UPDATES LOCKS UDSMSG STATUS 5JLS /5JLS 102641 223 16 SOS DONE 5KMG /5KMGA 000000 1 INITIALIZE 5BCM /5BCM 102712 73 2 SOS DONE INPUT FUNCTION
ls
** SCHEMA SCHEMATA ACTIVE-INCOR INPUT FUNCTION
ex
EXITING SUDS
This example uses the SUDS RC command to look at the status of all threads (three in this example) registered with UDS Control. Repeated use of the RC command
monitors all threads as they move through UDS. You see the sequence number (SEQ) this is the number of times a thread has entered UDS Control per step increase on each subsequent RC command until the thread has reached an end of step. If the thread was in the process of updating a database, the number reflected in the UPDATE column also increases in value with each update to the database.
The SUDS LS command produces a list of active schemas in use by the DMS DMR in this application group.
Monitoring UDS During Normal Operations