unisys ClearPath Enterprise Servers Universal Data System Administration and Support Reference Manual Level 18R1 February

Transcription

1 unisys ClearPath Enterprise Servers Universal Data System Administration and Support Reference Manual Level 18R1 February

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

3 Contents Section 1. Introduction to the Universal Data System 1.1. About This Manual Documentation Updates Exec Control Software Exec Step Control Exec Audit Control Integrated Recovery Utility (IRU) Universal Data System Products The UDS Online Data Manager: UDS Control UDS Components Intercept and Connect Routines Logical Data Managers and Storage Record Managers Relational Data Model RDMS Network Data Model DMS Shared File Model SFS Thread Control MCB with Optional Multiple INITAL Commands DPS/MCB with Optional Multiple INITAL Commands Implicit DMS/MCB and DMS/DPS/MCB Programs Distributed Transaction Processing Locking Queuing Table Control System Cache Management Memory Management Addressing Dedicated Files File Management Assigning UDS Files Freeing UDS Files Enabling and Disabling UDS Files and Pages Exec and TIP Files Using TIP Files Role of the Repository (UREP) Application Groups Application Definition Table ADT Alias List Active ADT List Transparent ADT Entries iii

4 Contents Section 2. Files Used in the UDS Environment 2.1. Categories of Files Files Used by the Exec Step Control File Audit Control Files Files Used by IRU IRU Files Used for All Application Groups IRU Files Dependent on Application Groups Files Shared by All Application Groups Files Used Exclusively by Each Application Group UDS Control Files RDMS Files DMS Files UREP Files SFS File File Assignment Limits Summary of Files and Characteristics Executive Control Files Default Product Files IRU Files UDS Control Files RDMS Files DMS Files UREP Files SFS Files Storage Areas and User Files Summary of Product System Files Processor Files Preparing a Dump Plan Recovery Types and Procedures Creating and Maintaining Dump Tapes Section 3. Monitoring UDS During Normal Operations 3.1. Verifying Recovered and Active Application Group Logging UDS Events Verifying Open Audit Trail for Application Group Verifying Access to UDS Monitoring Status of Active Threads Verifying Creation of New Cycle of Application Group Dump File Listing BDIs and Bank Attributes Displaying Status of UDS Files with FDTs Reporting IRU History File Information Determining File Security Status Using a Runstream to Check UDS Files Periodically Section 4. Processing UDS Dumps 4.1. Application Group Dump Initiation iv

5 Contents 4.2. Processing Dumps Using the DUMPER Runstream Selective Dump Processing DAP Functions Dump File Format Dumping the ADT Bank Section 5. Terminating Programs and Handling Errors 5.1. Idling UDS Application Groups Terminating Programs Abnormal Program Termination Handling UDS Errors Contingency Errors Internal Errors UDS Control Messages Message Format Scope and Impact of Errors Error Message Generation Message Text Syntax Changing and Translating Locating Messages Section 6. Recognizing and Correcting Abnormal Conditions 6.1. Abnormal Condition Categories UDS Is Accessible: Programs Fail While Executing Problem: Files File Unavailable (Rolled Out) File Unavailable (Assignment Conflicts) File Unavailable (Security Violation) Retention File Unavailable (Disabled) File Unavailable (Disabled) File Unavailable (I/O Errors) File Unavailable (Lost or No Longer Cataloged) Files Cannot Be Expanded (Special Case I/O Error) File Unavailable (I/O Errors in IOMAX Subsystem) Problem: Deadlocks Problem: UDSC Basic Mode to Extended Mode Transition Failure Problem: UDSC$PFGSDEF File Causes DMS Control Failure Problem: Memory Limit Quota Exceeded Problem: System Cannot Acquire a D-Bank Problem: Inability to Acquire Space in a UDS D-Bank UDS Is Accessible: Programs Seem Stalled v

6 Contents Problem: Programs Queued Programs Queued Trying to Start UDS Session Programs Queued Within UDS Session Problem: Unable to Initialize Because of Encryption D-Bank Error Problem: Unanswered System Console Messages (Unopened Audit Trail) Problem: Unable to Reconfigure XTC Environment Problem: Programs Waiting for File Assignment Problem: Programs Externally Terminated UDS Is Accessible: Database Seems Inconsistent Problem: Programs Reporting Questionable Data Program Error: Invalid Program Input Recovery Procedural Errors Resolving RDMS Database File Inconsistencies Programs Cannot Establish UDS Session Problem: Incomplete Abort of Application Group Problem: Application Group Recovery Failing Savefile Lost or Destroyed Audit Trail File Lost or Destroyed Short Recovery Fails: Retention File Problem Short Recovery Successful but Database File Problem Exists Section 7. Monitoring Performance and Diagnosing Problems 7.1. Trace Control Functions Calling the Trace Control Program (TRCCTL) TRCCTL Options Trace Components Search Constraints Trace Output TRCCTL Examples Example Example Meaning of RDMS Statistics DMR Trace Section 8. Monitoring and Analyzing UDS Control 8.1. Executing SUDS SUDS Options Demand and Batch Examples Demand Mode Examples Batch Mode Examples vi

7 Contents 8.4. SUDS Commands Add Error Code (AE) Add Message (AM) Display or Clear All Entries in RDMS Automatic Recompile Table (AR) Temporarily Change SERVICE Run Configuration Parameter (CF) Set Check Schema Flag (CS) Delete Application Group Entry (DA) Display UDS Control D-Bank (DB) Change or Display the Data Capture State for a Schema (DC) Display Errors (DE) Display Locks (DL) Display Message (DM) Dump UDS D-Banks (DP) Exit SUDS (EX) Free File from UDS Domain (FF) Help (HE) Change or Display the Hardware/Performance Monitoring Mode (HM) Disable Application Group (II) Refresh Application Group (IL) List Dedicated Entries (LD) List Active Schemas (LS) List Active Subschemas (LU) Display UDS Control Level (LV) Modify Batch/Demand Lock Threshold (MB) Modify Transaction Lock Threshold (MT) Override Clear (OC) Override Display (OD) Override Set (OS) List Status of Registered Threads (RC/RU) Remove Error Code (RE) List Active Steps (RL) Remove Message (RM) Change RLP Scan Times for ADT/IRU (RS) Set Schema Abort Flag (SA) Clear Schema Abort Flag (SC) Display Count of Discarded UDS Broadcast Messages (UM) TeamQuest Transaction Performance Auditing System (TeamQuest TPAS) TeamQuest Online System Activity Monitor (TeamQuest OSAM) Database Event Reporting Section 9. Using UDS in a Security Option 3 Environment 9.1. Finding Information About Security Option Security Option 3 Concepts vii

8 Contents 9.3. Subsystems UDS Untrusted Subsystems Library Subsystem Trusted Subsystems Accessing Subsystems UDS Control Command Privileges Creating UDS Subsystems Summary: UDS Subsystem Requirements File Names and Subsystem Divisions UDS Control Security Events Log Section 10. Handling Deadlocks (SERVICE Run) How the SERVICE Run Works Changing Timeout and Sampling Periods Restarting the SERVICE Run Section 11. Using the UDS FILER Utility Accessing FILER Using FILER Functions Avoiding Rollback Errors Customizing FILER Handling Errors Acceptable Errors Unacceptable Errors Index... 1 viii

9 Figures 1 1. UDS Control Configuration Role of Intercept and Connect Routine Multiple Application Groups in UDS Using MCB with UDS DMS and DPS/MCB with Multiple MCB INITAL Commands DMS Implicit Thread Control Flow with MCB DMS Implicit Thread Control with DPS/MCB Distributed Transaction Processing Cache Manager UDS Domains UREP-UDS Relationship ADT Lists Relationships ix

10 Figures x

11 Tables 2 1. Executive Control Files Default IRU Application Group Files Default UDS Control Application Group Files Default RDMS Application Group Files Default DMS Application Group Files Default UREP Application Group Files Default SFS Application Group Files Default Application Group Files Summary of Product System Files Default Application Group Files for Processors DAP Functions Supplied by UDS Contingency Error Result Types of UDS Control Messages Description of UDS Control Messages by Type TRCCTL Trace Components UDS Trace Levels TRCCTL Option 4 Search Dimensions RDMS Statement Count Statistics RDMS Occurrence Count Statistics Trace File Items for DMR Trace SUDS Commands UDS Product Event Logging Entry Types xi

12 Tables xii

13 Section 1 Introduction to the Universal Data System This section introduces this reference manual and provides a conceptual introduction to the Universal Data System About This Manual This manual describes Universal Data System (UDS) administration, maintenance, and support tasks. It covers three broad categories: managing files, monitoring UDS activities, and handling errors. Readers must be familiar with the UDS documentation library and knowledgeable about onsite systems and software, UDS Control software concepts, and integrated recovery. This manual is for database administrators and system support personnel who manage, use, and support UDS databases. Standard Release Configuration The conceptual information in this section and the examples throughout this manual generally describe a single-host version of UDS. If you are using UDS in an XTC environment, there are some differences in UDS operation. See the Integrated Recovery Reference and Administration Guide for Multihost Environment for more information about XTC operations. The examples in this manual are based on the standard release configuration: The default application group qualifier is UDS$$SRC. The default application group name is UDSSRC. The default application group number is 3. If you have more than one application group or change any of the default values, change the examples accordingly

14 Introduction to the Universal Data System Notation Conventions The following conventions apply in examples that illustrate user interaction at a display terminal or system console: Information you must enter is presented in bold type as in the following The system response can be in uppercase or lowercase letters. For example INPUT APPLICATION NAME (6 CHARS) A shaded box means that no information is required; press the XMIT or Enter key. User-designed file qualifiers and file names appear as follows: project-id*iru$pfrun-id Names of items you must supply are in lowercase italic letters. Technical changes entered for the current ClearPath OS 2200 release are highlighted for your convenience. What This Section Contains This section briefly introduces the component products that create and support UDS. These software components work together to control and maintain your database environment. The following major software components provide this integrated environment: Executive control software Integrated Recovery Utility (IRU) Database control software: UDS Control, the central UDS online manager Enterprise Relational Database Server (RDMS), a logical data manager that supports relational databases Enterprise Network Database Server (DMS), a logical data manager that supports hierarchical/network databases Shared File System (SFS), a logical data manager that supports flat files Repository for ClearPath OS 2200 (UREP), the repository for defining and reporting on the database environment and corporate information resources

15 Introduction to the Universal Data System For additional introductory level information, planning considerations, and a general summary of product installation and configuration tasks, see the Universal Data System Planning and Installation Overview. Before you read this section, it might also be helpful to become familiar with the material in the Integrated Recovery Conceptual Overview Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, contact your Unisys service representative or access the current PLE from the Unisys Product Support Web site: Note: If you are not logged into the Product Support site, you will be asked to do so Exec Control Software Exec step control and audit control provide mechanisms to synchronize processing operations within user programs. If an error occurs while an application group program is running, step control and audit control help to recover the actions performed by the affected application group. Error conditions can arise because of invalid input received by the programs, logic errors within the programs, the sequencing of program executions, hardware errors, or system software errors. The processing actions include transaction message handling, as well as database update operations performed by user programs Exec Step Control Exec step control tracks active programs and breaks them down into a series of steps. A step is a recoverable unit of work, in terms of database and message recovery. Exec audit control can record each successfully completed step onto the audit trail. An audit trail is a continuous magnetic tape or mass storage file that contains queue items, database changes, and transaction messages, along with the required system and step control information. A queue item is an Exec step control processing state change, written as a record to the audit trail. You use the audit trail to reconstruct databases when errors occur during processing. UDS supports three data management systems: Enterprise Relational Database Server (RDMS) Enterprise Network Database Server (DMS) Shared File System (SFS) Each UDS data management system has its own method of marking the beginning and end of a recoverable step

16 Introduction to the Universal Data System Step control and audit control also provide low-level file management functions for direct file access. Files registered with the Exec for low-level access management are called file control superstructure (FCSS) files. These files must also be registered with the Exec as Transaction Processing (TIP) files; they cannot be registered with UDS Control at the same time. You might prefer that programs use this alternative if they require the fastest access method and have uncomplicated requirements for organizing files. Section 2 explains how UDS Control uses FCSS files Exec Audit Control Exec audit control maintains the audit trail file for each application group. The audit trail file can be either mass storage or tape. UDS Control and Exec step control use the information on the audit trail file to record, in chronological order, information about recoverable steps within an application group program. Information related to database update events is recorded in the audit trail file. The information includes: A record of each database update. This is a snapshot of a database mass storage page (segment) after the database control software updates it. It is called an after-look. Summary snapshots of the step control queues pertaining to an application group, taken at periodic intervals and also backed up to the periodic savefile. You use the Exec STEPCONTROL stream generation statement (SGS) to determine the periodic savefile interval. A record of each time a queue item of a step is moved from one step control queue to another. This indicates a change in the state of a step. Transaction messages Data Capture records written to an audit trail when DMS Data Capture is configured. Audit control also maintains control of the audit control interface (ACI) file for each application group. The ACI file contains: History data about the use of the audit trail file legs, including audit trail file changes. For more information about the ACI file and other files used in the UDS environment, see Section 2. Audit-only information used by step control and IRU when you initiate the IRU short recovery procedure. For more information about IRU recovery procedures, see the Integrated Recovery Utility Operations Guide. Audit control also uses an Exec file called the audit recovery file (ARF) to recover the state of the audit trail for the application group

17 Introduction to the Universal Data System 1.4. Integrated Recovery Utility (IRU) You use IRU to perform offline and background error prevention and recovery operations for all application groups defined on your UDS system. These recovery functions relate to both message and database recovery. To perform database file recovery for RDMS, DMS, and SFS databases, the system uses the audit trail. For example, IRU uses the audit trail to reconstruct databases when errors occur, by reapplying all database entries recorded on the audit trail within a specified timeframe. With IRU, you can perform short, medium, and long recovery. For more information about IRU, see the Integrated Recovery Utility Administration Guide Universal Data System Products The UDS software products form a comprehensive and unified system for database management, data record processing, and database application development. UDS works with several system control software components and database software products to form this integrated environment for control, maintenance, and recovery of user databases. This integrated environment includes the following system control software components: Exec system software UDS database control software Integrated Recovery Utility (IRU) recovery software UDS includes the following database software products: Universal Data System Control (UDS Control) Enterprise Relational Database Server (RDMS) Enterprise Network Database Server (DMS) Shared File System (SFS) Repository for ClearPath OS 2200 (UREP) These software components and products provide you with a system for designing, manipulating, maintaining, and securing information in several database formats. UDS is the interface through which users can access several types of files The UDS Online Data Manager: UDS Control UDS provides a family of products for organizing and retrieving data in several formats. UDS Control, the UDS online data manager, provides a common architecture and environment for the UDS product family

18 Introduction to the Universal Data System UDS Control supports three data models and manages all their files. UDS Control allows users to share files, controls access to those files, and automatically and uniformly resolves conflicts over access to the files. It also allows users to designate recoverable files, regardless of the data management method used, and it provides consistent file recovery. UDS Control supports data access commands for the logical data managers RDMS, DMS, and SFS. All logical data managers (LDM) can be used within the same program or within different programs executing concurrently. UDS Control supports multiple application groups, which provides for independent database environments. UDS Control can be installed into any configured application group. Users can manipulate data in one application group without affecting data in other application groups. UDS Control can also run without interfering with other database management software on the system. UDS Control handles main storage through its own cache manager banks. The UDS memory can be used for general file paging or as page buffers for specific files. Buffers can contain data from one file, part of a file, or several files. UDS Control assigns all shared Exec files to its own common name section, which improves overall system performance and increases data security. A UDS Control thread is a sequence of commands from one user. The user determines when the thread begins and ends. The user can partition the thread into subsequences (steps) and commit the thread for a successful end of step or omit it and undo the step, including its updates to the database. Records added or changed by a successful step become permanent entries in a recoverable file. Records added or changed by a failed step revert to their prior state. UDS Control maintains a central lock directory for files, pages, and records. A queuing and deadlock detection system recognizes and resolves locking conflicts. UDS Control detects and uniformly resolves resource deadlocks. UDS Control queues threads in conflict because of a lock by a thread or another resource; it reactivates the threads as soon as the lock is lifted and the resource becomes available. The UDS Control trace facility includes its own diagnostics and aids to monitor performance. The UDS Control dump facility issues a machine-readable dump following contingency errors or other abnormal conditions. Some other features of UDS Control are as follows: UDS Control uses a protected fixed-gate subsystem to secure UDS data. UDS supports Fundamental Security and Security Options 1, 2, and 3. See the UDS Planning and Installation Overview for more information about installing UDS products in a secure environment. UDS run-time files can be TIP files. Through UREP dynamic system reconfiguration, system features can be dynamically selected and tuning parameters can be adjusted. Error messages can be translated to languages other than English

19 Introduction to the Universal Data System 1.7. UDS Components UDS consists of a number of components. Each logical data manager has its own intercept and connect routine (ICR), which is installed with the LDM. RDMS and SFS each have a storage record manager (SRM). Figure 1 1 illustrates how UDS Control components fit together. It includes the following components, which are described in the following subsections: ICR LDM SRM CAM LSS/QAD TCL TCS Intercept and connect routine Logical data manager (RDMS, DMS, or SFS) Storage record manager, the component of an LDM that understands file formats Cache manager Locking subsystem/queuing and deadlock detection Thread control Table control system Figure 1 1. UDS Control Configuration

20 Introduction to the Universal Data System 1.8. Intercept and Connect Routines Intercept and connect routines (ICR) link user programs with UDS Control code. ICRs examine user requests entering UDS Control and obtain information about the existing thread environment. If the thread is not yet initialized in UDS Control, thread control sets up a new one. As its name suggests, an ICR serves two functions. The intercept function redirects existing program requests from application group programs to UDS Control. The connect function makes the switch in environments and transfers data between the user program and UDS Control. ICRs perform the following tasks: They direct the user program call to the UDS code. They post all user call parameters into the UDS environment. They isolate the UDS environment from the user environment. Each LDM has its own ICR. Each ICR is installed with its LDM. Whenever a user program requires data from UDS, it transfers control to the ICR. The ICR reads application group information from the application definition table (ADT), sets up the environment, and transfers the data to UDS Control for processing. Figure 1 2 illustrates the role of an ICR. Figure 1 2. Role of Intercept and Connect Routine After a thread begins to access data from an application group, it must remain in that application group. Any attempt to reference data in another application group causes an error; however, one application group program can employ commands of more than one LDM and can use more than one ICR. You can have multiple LDMs servicing one application group

21 Introduction to the Universal Data System Figure 1 3 illustrates the use of multiple application groups. A single LDM serves as an example. Programs from application groups 7, 8, and 9 transfer control to the ICR. The ICR then reads ADT to establish the UDS common banks and subsystems that make up application groups 7, 8, and 9. All three application groups in the figure share the same UDS Control chameleon subsystem. Each application group has its own protected subsystem, which contains the UDS D-banks. The configuration attributes for each application group can vary considerably. Each application group also has its own audit files for other system components, such as the Message Control Bank (MCB). Figure 1 3. Multiple Application Groups in UDS

22 Introduction to the Universal Data System 1.9. Logical Data Managers and Storage Record Managers Commands, syntax, and location of commands within user programs can vary greatly from one data model to another. UDS Control creates an environment for data control that is independent of language or data model. Logical data managers translate data model commands into a form that UDS Control can understand and use in its executing environment. Each data model has its specific code in its LDM, and each LDM has its own interface language and set of commands. For DMS, this interface language is the data manipulation language (DML). For RDMS, it is Structured Query Language (SQL). To extend UDS Control to accommodate another database product, install another LDM. The LDM translates requests for logical data into requests for physical data. It also performs the following tasks: It recognizes and routes your commands. One user command can cause an LDM to execute several requests for physical records. This is especially true for the relational data model. It controls iterative calls to the storage record manager (SRM), if one exists, for the LDM. The SRM processes requests for physical data and calls on the cache manager subsystem to perform I/O operations. It assembles the information you request. It returns control to you through the ICR with the appropriate status and data when the request is complete. The SRM processes requests for physical data received from an LDM and passes them to the cache manager. The SRM interprets the data model expected by the LDM, as well as the format of the data in physical storage. It acts as a translator between the LDM and the physical data. The SRM performs all functions related to managing the page, and storing and retrieving data within the page. RDMS and SFS each have one SRM. The LDM chooses the appropriate SRM, depending on data format. To summarize, the SRM performs the following tasks: It translates requests for data from the LDM and passes them to the cache manager. It controls the storage of records into pages. It manages space within the pages. It calls the locking subsystem to control access to shared data. It controls other functions that manage physical data

23 Introduction to the Universal Data System Relational Data Model RDMS RDMS supports fourth-generation Structured Query Language (SQL) statements for creating relational databases and for retrieving and manipulating relational data. Native RDMS interfaces include The interpreter interface through third-generation programming languages The IPF SQL interface The MAPPER Relational Interface (MRI) The Open Distributed Transaction Processing (formerly called Open/OLTP) interface Embedded SQL statements in UCS COBOL and UCS C programs The Query Language Processor (QLP) The Logic and Network Information Compiler (LINC) Module programs, allowing access through UCS FORTRAN In addition, the UniAccess ODBC Server for OS 2200 Systems allows ODBC-compliant tools for the workstation to access RDMS databases. The Relational JDBC Driver for ClearPath OS 2200 provides Java access to RDMS. For more information about RDMS, see the Relational Database Server for ClearPath OS 2200 Administration Guide Network Data Model DMS With DMS, you describe the physical database structure by writing Data Definition Language (DDL) clauses to define a schema and Subschema Data Definition Language (SDDL) clauses to define subschemas. The optional Data Capture feature allows specified updates to a DMS database to be captured and subsequently applied to a different database. For more information about DMS, see the Network Database Server for ClearPath OS 2200 Administration and Support Guide

24 Introduction to the Universal Data System Shared File Model SFS SFS lets programs share files. To access data stored in files using SFS, you must first use the UREP processor to define storage areas for these files. You can then use either of the following methods to declare a file as shared and thus use SFS to access that file: You can use SELECT clause syntax to specify shared files; for more information, see the ASCII COBOL Programming Reference Manual or the COBOL Compiler Programming Reference Manual Volume 2. You can also use the syntax of ASCII FORTRAN to specify shared files; for more information, see the ASCII FORTRAN Programming Reference Manual. Use the Define File Processor (DFP) to specify the value YES for the SHARE parameter for the file (that is, specify SHARE = YES). For more information, see the DFP Administration and Programming Reference Manual. If the program you are about to execute does not contain the COBOL or FORTRAN syntax to specify shared files, you must use DFP to define the file as shared. You define record descriptions and file descriptions to the COBOL and FORTRAN compilers in the same way as nonshared files. For more information about SFS, see the SFS Administration and Support Reference Manual Thread Control A thread is a sequence of commands coming from one user or from one session. The thread control module controls these sets of user commands. Each thread has the following characteristics: It is related to one specific user. It consists of one or more steps. Steps are either recoverable or nonrecoverable. Recoverable steps also have the following characteristics: Recoverable steps that perform successfully end with a UDS COMMIT command. The COMMIT command makes permanent any record additions or changes that were made since the beginning of the step. Steps that fail to perform successfully are rolled back by a UDS OMIT command. Any records added or changed since the beginning of the step revert to their condition at the beginning of the step. Nonrecoverable steps that fail to perform successfully cannot roll back file updates and might place a database in an inconsistent state. Also see the description of thread control in the Integrated Recovery Conceptual Overview

25 Introduction to the Universal Data System To maximize program flexibility, the application group name of the BEGIN THREAD command for the program must be an alias for the integrated recovery application group name. For example, instead of BEGIN THREAD FOR APPLICATION APPONE, where APPONE is an Exec integrated recovery application group, define PAYROLL as an alias for APPONE, and then use BEGIN THREAD FOR APPLICATION PAYROLL. You can then route the program from one application group to another by changing the alias. Changing the alias is a function of dynamic system reconfiguration (DSR), a UREP facility. The ADT maintains the list of aliases (see ). Note: This use of the alias only switches UDS from one application group to another. The alias does not switch other products, such as MCB, to different application groups. For this reason, this technique might be of limited value for programs, such as transaction programs, that use these other products. UDS Control performs the following standard operations for all programs that execute in UDS: It connects batch or demand programs not already connected to TIP through an Executive request (PB$CON) when the program first attempts to access a UDS/TIP file. If a nonrecoverable thread is attempting to update a recoverable file, it executes the proper system call to start a step and convert the thread into a recoverable thread. These operations are performed on explicit and implicit UDS threads MCB with Optional Multiple INITAL Commands If you use MCB with an explicit UDS thread, the MCB INITAL and TERMN8 commands must be executed outside of an active UDS step, as follows: The MCB INITAL command must be executed before the UDS BEGIN THREAD command, or after a UDS COMMIT or ROLLBACK command. The MCB TERMN8 command must be executed after the UDS END THREAD command. Programs executed in batch or demand mode are more restricted, because the MCB CONECT or INITAL command must be executed before the UDS step is started (before the UDS BEGIN THREAD command). The MCB ROLBAK, COMMIT, and TERMN8 commands cannot be used within a UDS thread. These commands are replaced by the UDS COMMIT and ROLLBACK commands. MCB can be used with RDMS, DMS, and SFS

26 Introduction to the Universal Data System In some cases, you can use multiple MCB INITAL commands within the program to avoid the overhead of executing multiple setup commands, such as with the DMS IMPART and OPEN commands or the SFS OPEN command. Once the transaction performs its initial processing, the UDS COMMIT command can be executed, followed by an MCB INITAL command to begin the next transaction process. Figure 1 4 illustrates a typical usage of MCB with UDS. Figure 1 4. Using MCB with UDS INITAL TERMN8 Makes a program known to MCB. MCB executes ER QI$NIT to create a message queue item. The program is registered for termination handling and a step is started for the program. If a batch or demand program is not connected to TIP, ER QI$CON is executed to perform the connect operation. MCB INITAL must be executed outside of an active UDS step. Note that a UDS BEGIN THREAD command starts a step. Terminates the program within MCB. MCB performs its termination handling, deregisters the program from MCB termination handling through ER TRMRG$, and disconnects from TIP if it performed the connect operation to MCB initially. This command must be executed outside of an active UDS step

27 Introduction to the Universal Data System DPS/MCB with Optional Multiple INITAL Commands Another possible explicit thread program type is a UDS program that uses DPS with MCB. This type of program can be used with RDMS, DMS, and SFS. If you use DPS for a batch or demand program in a UDS application group that uses TIP/UDS files, the program must perform the connect and disconnect operations using the TIP primitives. The connect operation must be performed before the first access to DPS or UDS. Figure 1 5 illustrates the typical structure of a DMS program using DPS/MCB with multiple MCB INITAL commands. Figure 1 5. DMS and DPS/MCB with Multiple MCB INITAL Commands D$INIT D$CLOSE Makes the program known to DPS. DPS also calls MCB, which performs the operations described for MCB INITAL (see ). DPS also connects a batch or demand program to TIP if it is not already connected. In this particular situation, this connect operation must be avoided, so the program must perform the connect operation before the D$INIT. Writes a terminal close record. Next, DPS calls MCB to perform the MCB TERMN8 command processing described in If the D$CLOSE command is executed while a UDS step is active, MCB does not perform the termination operations. If the D$CLOSE command is executed and a UDS step is not active, MCB terminates its operations. Finally, DPS disconnects from TIP if it performed the connect operation

28 Introduction to the Universal Data System Implicit DMS/MCB and DMS/DPS/MCB Programs Since DMS commands allow for the implicit execution of COMMIT, ROLLBACK, BEGIN THREAD, and END THREAD commands, you can use MCB or DPS/MCB with recoverable DMS programs. The operations of these programs are like those described in , except that the thread control operations are implied. If you use DPS for a batch or demand program in a UDS application group that uses TIP/UDS files, the program must perform the connect and disconnect operations using the TIP primitives. When you use MCB without DPS for an online batch or a batch or demand program in a UDS application group that uses TIP/UDS files, the program must execute an MCB CONECT or INITAL command before the DMS IMPART command. Figure 1 6 illustrates the program flow for typical DMS program implicit thread control with MCB. Figure 1 6. DMS Implicit Thread Control Flow with MCB

29 Introduction to the Universal Data System Figure 1 7 illustrates the program flow for typical DMS program implicit thread control with DPS/MCB. Figure 1 7. DMS Implicit Thread Control with DPS/MCB Distributed Transaction Processing UDS supports the Distributed Transaction Processing (DTP) model. DTP allows a single application program to safely access and update data on more than one machine, or in more than one environment on a single machine (for example, in multiple application groups). In the DTP model, a transaction manager (TM), such as the Open Distributed Transaction Processing product, coordinates updates made by a resource manager (RM) such as UDS. The application program (AP) uses the transaction manager to coordinate the updates. Figure 1 8 illustrates how this works. Figure 1 8. Distributed Transaction Processing

30 Introduction to the Universal Data System To ensure that updates are properly coordinated, UDS implements the two-phase commit protocol. In a two-phase commit, the following steps occur: 1. The application program makes updates through the resource managers involved. 2. The application program informs the transaction manager that it is ready to commit. 3. The transaction manager asks each resource manager to prepare to commit. The resource managers ensure that they can commit the requested updates, and they respond to the transaction manager. If any resource manager finds that it cannot enter the prepared state at which a commit can be guaranteed, the transaction manager requests all resource managers to roll back the updates. If all resource managers are able to enter the prepared state, the transaction manager tells all the resource managers to commit the updates. For more information, see Open Distributed Transaction Processing Getting Started Locking The locking subsystem controls access to data and other system resources. There are a number of different levels and types of locks. For example, locking is supported at the file, page, and record level. Which locks are used and how they are used are determined by the logical data manager. For more information about how locking is used for a particular LDM, see the administration guide for that LDM Queuing The queuing subsystem resolves locking conflicts. A locking conflict occurs when two threads want locks on the same data or system resource simultaneously. The locking subsystem allows the caller to specify how to resolve any locking conflicts. The caller is any internal caller; the caller can also be a user program, because some data models offer this feature to users. Two strategies for resolving locking conflicts are available: Immediate return of control to the caller Internal queuing until the conflict is resolved The normal strategy is internal queuing. Internal queuing means that the programs attempting to access the data are queued or ordered. One must wait while the other accesses the data. If a locking conflict arises, the locking subsystem resolves the conflict by immediately returning control to the caller, or by queuing the access request. If the queuing subsystem is called, it queues the thread so that each thread can access the data or resource in turn

31 Introduction to the Universal Data System If the conflict cannot be resolved by queuing (that is, if a deadlock occurs), the system checks all threads holding the lock and resolves the conflict by releasing (rolling back) one of the programs. A deadlock is a special kind of conflict that arises when thread A has resource 1 and thread B has resource 2, but each must access the other resource. Neither thread can get out of the situation. Deadlock detection involves checking for lock cycles in the list of user threads. Deadlocks can result from locks set by any LDM. The system resolves the deadlock by selecting one of the participating threads for rollback. The selection strategy is specified through DSR. These are the deadlock resolution strategies: MINIMUM-WASTED-EFFORT UPDATES PRIORITY The thread that consumes the least number of standard units of processing (SUP) is selected for rollback processing. The thread that makes the least number of updates is selected for rollback processing. This strategy is available only for DMS programs. The program itself specifies the priority of a program. When a deadlock occurs, the program with the lowest priority is selected for rollback processing. Another deadlock problem can occur between a UDS application and the file control super structure (FCSS) facility, when two UDS threads (A and B) holding or attempting to hold both UDS and FCSS resources simultaneously become deadlocked. The deadlock occurs because thread A queues in UDS for UDS resources held by thread B, while thread B is in its user program (without having ended its UDS thread) queuing in FCSS for resources held by thread A. The background SERVICE run periodically samples UDS threads and forces rollback in the event of deadlock errors in threads that remain queued longer than a preconfigured timeout period. The run attempts to eliminate false deadlocks by checking thread B, to determine whether thread B is working inside or outside of UDS. It also checks whether the thread B command count is increasing over time. If it is increasing, the run does not roll back thread A. Both the sampling rate and timeout period for FCSS deadlocks are configurable through DSR. For more information about the SERVICE run and DSR, see Section 10 Repository for ClearPath OS 2200 Administration Guide

32 Introduction to the Universal Data System Table Control System The table control system (TCS) is the run-time manager of the description tables used by UDS Control and LDMs. These tables contain encoded descriptions and definitions of storage areas, relational tables, and other UDS tables. The file description table (FDT), for example, contains information about user database files and is used by UDS Control and all LDMs. Some description tables, on the other hand, are useful only for a specific LDM. The relation description table (RDT), for example, contains definitive information about a user-defined RDMS table and is referenced only by RDMS and its SRM. UREP constructs description tables from user-supplied definition statements, or from information from an LDM such as RDMS. UREP passes these tables to the TCS for storage in one of the UDS database files (for example, FDTs in the FDT$ file and RDTs in the RDT$FILE file). As programs are executed, description tables are retrieved from the database when needed and placed in memory. When a table is no longer needed, it is removed from memory. The TCS, along with other UDS Control components, manages the retrieving, accessing, updating, deleting, and storing of description tables Cache Management UDS Control improves database throughput in the application group by moving large amounts of data into memory where access to data is at instruction processor speed, and not slowed down by numerous time-consuming I/O operations. UDS Control dedicates various sizes of memory to your system for the cache. The cache manager subsystem manages the cache. In this process, the cache manager processes memory requests and I/O requests for database pages from the LDMs. As part of this process, the LDM writes updated database pages back to the appropriate database file; see Figure 1 9. Figure 1 9. Cache Manager

33 Introduction to the Universal Data System The cache manager also maintains database files in recoverable condition. Some functions of the cache manager are Rolling back the database updates for the executing program Generating audit trail records Performing short recovery operations Memory Management UDS memory is composed of banks in the UDS subsystem. A bank is a contiguous address space that contains either code and instructions (I-bank), or data (D-bank), or both. UDS Control has the following types of banks: I-banks hold executable code. UDS uses many I-banks. The UDS Control D-bank (also referred to as the DCSD bank) is the global D-bank for UDS Control. It contains data that is shared throughout UDS to control processing. Thread D-banks contain unique, nonshared data for each thread executing within UDS Control. Each active thread has one thread D-bank. Page D-banks contain data shared by all threads executing in UDS Control. The banks contain only user data from the site s database files. Small page banks are a subset of page banks; small page banks contain small pages, such as RDMS allocation pages. Schema D-banks hold schema and subschema tables and Data Capture tables (DCT). Their storage is managed by DMS. Schema D-banks are allocated dynamically by UDS. TCS D-banks contain table control system tables (for example, FDTs and RDTs). Lock D-banks contain UDS locks. FPTE D-banks contain internal control structures for cache management. An encryption D-bank is used for RDMS encryption Addressing You do not have to allocate banks explicitly. Banks are automatically allocated as follows: The number of page banks allocated is determined by the CACHE-WORDS attribute you specify in the UDS configuration, by the number of banks dedicated to specific files, and by the SMALL-PAGE-WORDS attribute. The number of thread banks is determined by the number of threads configured (MAX-THREADS), one bank per thread. Other bank types are allocated as needed, up to internal limits or sizes specified by DSR

34 Introduction to the Universal Data System Dedicated Files The dedicated files feature of UDS Control can greatly improve the performance of your database system. Through the DSR process, you can specify that a single file, part of a file, or group of files reside in a particular page D-bank cache. For an explanation of how to dedicate files to memory banks, see the Repository for ClearPath OS 2200 Administration Guide. For example, if you have a database system of 200 files, but one of those files is accessed by every program that is executed, you can dedicate that file to its own cache (page D-bank). The cache contains only the pages of the dedicated file. If the entire dedicated file fits into the page bank, it becomes a candidate for the large I/O processing feature, which reads in the entire dedication upon the first reference to a page in the dedication. No other files can use the dedicated cache. The number of I/O operations performed to access that file decreases greatly, improving the performance of your system File Management The following topics describe how UDS Control assigns and frees UDS files, how UDS Control enables and disables UDS files and pages, and how to use TIP files Assigning UDS Files UDS Control assigns shared Exec files to the UDS domain, whenever a thread must access a file and the file is not already assigned to the UDS domain. The UDS domain for a UDS application group is an Exec common name section. A domain is an entity associated with a list of files. Files can exist exclusively in either the UDS or USER domain, or in both domains. Files exclusively in the UDS domain are assigned by UDS and can be accessed by several threads within UDS at the same time. UDS assigns files that exist in both the UDS and USER domain; users can assign these files at the same time. Such files are called USER-UDS files, because both UDS and user threads can access them concurrently. Files exclusively in the USER domain must be assigned by the user, before UDS can perform I/O operations in the USER domain

35 Introduction to the Universal Data System Figure 1 10 illustrates UDS domains. Figure UDS Domains When a file is assigned to the UDS domain, it is accessible for I/O requests, if the program is executing from within UDS code, but not after control is returned to the user program. When a user program is executing from within UDS code and attempts to access data from a USER-UDS file, UDS switches from the USER domain to the UDS domain. When program control is returned to the user program, UDS switches back to the USER domain if necessary. A file can be assigned to both domains. UDS does not assign USER files. Users must assign USER files before UDS Control can perform I/O operations. For file assignments, the following apply: If the domain field on the FDT is USER, the file is nonshared and UDS Control does not assign it. If the domain field on the FDT is USER-UDS, the file is shared and UDS Control assigns it using statement. Users can also assign it. If the domain field on the FDT is UDS, UDS Control assigns it exclusively to the UDS domain (@ASG,AXZ). Users cannot assign the file. The domain field in the FDT for each file indicates how UDS must assign a file. You define the domain attribute using UREP commands; see the Repository for ClearPath OS 2200 Administration Guide. UDS Control also accommodates the application definition table (ADT) domain. Only one file, UDS$$SRC*ADT-FILE, is assigned exclusively to the ADT domain. The ADT contains information about all UDS application groups in use at your site. All executing application groups share it, and it is accessible only through special UDS code that executes in the ADT domain. The file assignment mechanism described earlier is used only for Exec files. TIP files are not assigned to UDS; they are permanently assigned to the Exec

36 Introduction to the Universal Data System Freeing UDS Files An Exec file is freed from UDS Control only in the following cases: The limit of 4096 files assigned to the UDS common name section is exceeded. The file description table (FDT) for the file is deleted by a UREP PROCESS command. The file is downed by the IRU down command. The file is freed by a SUDS FF command. Files can thus remain assigned to UDS for a considerable length of time, even after the programs that were using them have terminated. You can use IRU to free an Exec file, by first disabling and then enabling the file. During execution of the DOWN command, all pages of the file are purged from the UDS Control cache. The following sequence of commands illustrates down file qualifier*file-name; act appl application-group-name; up file qualifier*file-name; act appl application-group-name; end; Enabling and Disabling UDS Files and Pages You can use IRU UP and DOWN commands to enable or disable any file or pages of a file controlled by UDS Control. Individual LDMs and other components of UDS Control can disable files and pages when database corruption is suspected and recovery is required. The IRU DOWN command disables files or pages. All access to the file or page is denied. The optional FROM UPDATE and IMMEDIATE clauses are allowed only on files. The FROM UPDATE clause places a file in the down-from-update state; the file can be read but not updated. The IMMEDIATE clause of the DOWN command forces any thread accessing the files to roll back. The UP command places files or pages in the UP state and thus allows access to them. For more information on the UP and DOWN commands, see the Integrated Recovery Utility Operations Guide. The TCS component of UDS Control manages enabling and disabling files and pages and maintains a list of all disabled files and pages. During execution of the IRU DOWN command, all pages of a file are purged from the UDS Control cache; the file is freed from the UDS domain. If the IMMEDIATE clause is not used, the DOWN command is queued until the file or page is not in use, and then the file or page is disabled. After a page is disabled, either

37 Introduction to the Universal Data System by IRU or by another component of UDS, the UP command for a page purges the page from the UDS cache. Individual LDMs and other components of UDS Control can call TCS to execute the DOWN commands. The specific request depends on the LDM associated with the file, and whether page-range recovery is configured for the application group. SFS MSAM files can only be disabled (DOWN). For more information on configuring page-range recovery, see the Repository for ClearPath OS 2200 Administration Guide Exec and TIP Files You can use both Exec and TIP files in your database system. The file type you use is specified when UREP creates the FDT for the file. Exec files are easy to create and require no preparation for their use. TIP files are used by transaction programs and require careful creation and management. TIP files are referred to as UDS/TIP files. Either Exec or TIP files can be duplicated (duplex files). When you duplex a file, two identical copies (legs) are created. If a program issues a read, the read is directed to one of the legs. If the read fails because of an I/O processing error, the system automatically reads duplicate data from the other leg. This allows the program to continue its processing. You can use Exec or TIP files for UDS Control system files, such as the retention files. For a more complete description of how to specify and use TIP files, see the Repository for ClearPath OS 2200 Administration Guide Using TIP Files The FDT for the file informs the cache manager subsystem which type of file it is. Based on this information, the cache manager uses the correct Exec function to access the file. Each UDS/TIP file, in addition to being cataloged, must be registered and reserved using the TIP utility processor FREIPS. TIP files are permanently assigned to the operating system and do not need to be assigned to the UDS domain. A third class of files are TIP files directly accessed through TIP file control superstructure (FCSS). UDS Control does not control these files, and they do not have a file description table (FDT). These files can be recoverable, however. IRU coordinates the recovery of these files with FCSS during short recovery in the same way that UDS Control coordinates for UDS/TIP files. IRU has some functions, such as COMPARE, that operate only on TIP files. Other functions, such as LIST, have formats or capabilities for TIP files different from those for Exec files. If you use the format of the command intended for TIP files, even though the file is a UDS/TIP file, IRU executes the command without calling UDS. You might find this useful for commands such as COPY, COMPARE, and LIST, but you must not attempt this with DUMP, RELOAD, or RECOVER commands

38 Introduction to the Universal Data System Role of the Repository (UREP) The Repository for ClearPath OS 2200 (UREP) maintains all data definitions for UDS. UREP provides commands for defining and reporting on RDMS, DMS, and SFS databases, as well as on your corporate information resources. The UREP database, called the repository, contains information about the data in your organization and about your application groups and files. UDS Control uses this information to provide an integrated system for defining user database files. The following information is stored in internal UDS Control tables: Application definition table (ADT) System file (SYS-FILE) File description table (FDT) Relation description table (RDT) The ADT and SYS-FILE contain information about your application groups, including entry points, sizes, and internal files used. This information is called a configuration. FDTs contain information about your files, including the kind of files they are, whether to audit I/O operations to the files, the page sizes, and the data formats. This information is called a storage area. RDTs are machine-readable table definitions used by RDMS that correspond to information stored in symbolic form in the repository for user reports. UDS Control relies on the UREP PROCESS command to place information in some of these internal tables. The PROCESS command calls either of two processes: If you use configurations, the PROCESS command calls the dynamic system reconfiguration (DSR) process. If you use storage areas, the PROCESS command calls the data storage definition (DSD) process. DSR and DSD are transparent to you. You must know how to use the PROCESS command; this command is described in detail in the Repository for ClearPath OS 2200 Administration Guide. The RDMS table definition commands use UREP to create RDTs

39 Introduction to the Universal Data System Figure 1 11 illustrates the relationship between UREP processes and UDS Control internal tables Application Groups Figure UREP-UDS Relationship An application group is a partitioning of files, program executions, and messages associated with your system. It is a working environment that acts as an independent system. You designate an application group to contain a particular set of files and program executions. IRU integrates and coordinates the recovery of files and messages as a unit within an application group. This guarantees that you have consistent file updates and message processing for all program executions in the application group. You can maintain all of your organization s data in one application group, or you can isolate databases in separate application groups. Two components of UDS, the application definition table (ADT) and intercept and connect routines (ICR), make this possible. UDS Control manages application groups by referring to information held by the ADT, along with other information held by the application group system file (SYS-FILE) and the file description tables (FDT). UDS Control supports the 16 application groups allowed by the operating system. Each application group requires its own set of D-banks, audit files, meta-database, and other support components. An application group can contain several databases. Some databases are explicitly defined (for example, a DMS schema). For DMS, this means that the Data Definition Language (DDL) and the Subschema Data Definition Language (SDDL) define the database. Other databases are defined implicitly because of the manner in which a program references certain files (for example, collections of SFS files). In these SFS databases, your user program defines the record layout. Databases in an application group do not need to be related, either physically or logically; however, the entire database must reside in the same application group. You cannot divide one database among application groups

40 Introduction to the Universal Data System See the Integrated Recovery Conceptual Overview for more information about application groups Application Definition Table The ADT contains information about all UDS application groups in use by UDS. At run time, ICRs reference the ADT with each command to UDS Control. The ADT contains the information for the ICR on the appropriate application group to which to send the thread. The thread must remain with that application group. The ADT also plays a role in the UREP dynamic system reconfiguration (DSR) process. The ADT is a common D-bank with a backup file on mass storage. During initialization, UDS Control reads the current ADT from the backup file. If you installed a new configuration with the UREP PROCESS... INSTALL command, UDS Control completes the configuration by updating both the ADT common D-bank and its backup file. The common D-bank that contains the ADT and the access routines that reference it is named UDS$ADTCDB. Both DSR and UDS Control reference the ADT bank during reconfiguration and initialization. ICRs also reference the ADT bank each time a thread enters UDS. The ADT backup file, UDS$$SRC*ADT-FILE, contains a copy of the ADT on mass storage. Both DSR and UDS Control keep this file up to date. The ADT consists of three lists: Active ADT entries Transparent ADT entries Application group aliases Each application group has an active ADT entry. The active ADT entry defines the active configuration for the application group. For details about the role of the ADT in reconfiguration, see the Repository for ClearPath OS 2200 Administration Guide. Figure 1 12 illustrates how these ADT lists are related. You can have up to 16 active entries, one for each application group. You can have one or more aliases for each active entry, and one or more aliases for each transparent entry in use. Figure ADT Lists Relationships

41 Introduction to the Universal Data System ADT Alias List The list of ADT aliases contains one or more alternate names for each application group. For each transparent ADT entry for an application group, there is also a set of transparent and active aliases. ICRs retrieve information about an application group by specifying either the application group name or one of its aliases. A DMS schema name is frequently used as an alias. For SFS, the ICR BDI is used as an alias. You can update the alias list through DSR without installing a new configuration; see the Repository for ClearPath OS 2200 Administration Guide Active ADT List The list of active ADT entries is the most important information in the ADT. Each entry in the active ADT list describes the active configuration for an application group. You cannot view ADT entries directly. You can, however, use UREP reporting commands to view them. Active ADT entries contain the following information about each application group: Active application group name Application group number UDS Control I-bank (code) bank descriptor index (BDI) UDS status flags (control flags such as the reconfiguration flag used by UDS Control) UDS system file (SYS-FILE) qualifier and file name, or UDS/TIP file number Miscellaneous reconfiguration and initialization information Transparent ADT Entries A transparent ADT entry describes a proposed configuration for an application group. The DSR process creates a transparent ADT entry each time a PROCESS CONFIGURATION... INSTALL command, which initiates the reconfiguration process, is executed successfully. Transparent ADT entries exist only until the configuration becomes active; then the transparent entry replaces the former active ADT entry to become the new active entry for the specified application group. The new active entry contains the same information that was in the transparent entry. See the Repository for ClearPath OS 2200 Administration Guide for more information

42 Introduction to the Universal Data System

43 Section 2 Files Used in the UDS Environment This section discusses the four categories of files used in the UDS environment and provides a description of each file within its category. At the end of the section, file assignment limits are identified. Tables 2 1 through 2 10 summarize the characteristics of each file Categories of Files Files used in the UDS environment fall into four categories: Files used by the Exec Files used by IRU Files shared by all application groups Files unique to each application group within each UDS product The UDS standard, recommended application group file qualifiers for the application groups are as follows: 1 UDS$$ONE 2 UDS$$TWO 3 UDS$$SRC (default application group) 4 UDS$$FOR 5 UDS$$FIV 6 UDS$$SIX 7 UDS$$SVN 8 UDS$$OCT 9 UDS$$NIN 10 UDS$$ UDS$$ UDS$$ UDS$$ UDS$$

44 Files Used by the Exec 15 UDS$$ UDS$$016 The file names used in this section are for the UDS default application group, typically application group 3, as in the following example: UDS$$SRC*SYS-FILE User-designated file qualifiers and file names are in italics, as in the following example: project-id*iru$pfrun-id Product files are not automatically backed up. As a safeguard against lost disk packs after installing products and before using them, you must back up the files Files Used by the Exec To identify and control processing steps within an application group and provide for their recovery, the Exec requires several supporting system files, one file per application group. The two categories of Exec files are step control files and audit control files Step Control File This subsection describes the required step control file, the periodic savefile. File periodic-savefile Assigned Cataloged by Deleted Freed Restored Exclusively to step control after cataloging. Also assigned on reboot if it already exists. Step control during an initialization bootstrap procedure. If a TIP periodic savefile is used, you can create it when TIP files are initialized during a jump key 7 reboot. You can also register a TIP periodic savefile with the TIP utilities once the reboot process has recovered the system. If you use TIP utilities to register the periodic savefile, do not attempt to respond to the outstanding system console message concerning application group recovery (INIT, SUTIL, or NONE) during the reboot until the periodic savefile is registered. Never Once the file is assigned, never UDS recovery and auditing are not performed because this file is under Exec control. A dump is not required, and the file does not have to be reloaded

45 Files Used by the Exec Exec step control uses the periodic savefile to periodically save snapshots of the step control queues for the application group. These snapshots, when taken, represent the state of all program steps in the system at that moment. The snapshot represents a recovery point, identified by a timestamp, and corresponds to a periodic summary record also written to the audit trail file at the same time. The periodic savefile is used whenever the application group is active. Step control uses this file to periodically save its queue structures (interval defined in the Exec generation). Subsequently, step control (and sometimes IRU) uses it to recover these queues following a system failure. Recovery of queue items takes place during the autorecovery bootstrap process. The file is initialized during the initial bootstrap procedure. You can designate the periodic savefile as an Exec file or a TIP file by using the STEPCONTROL SGSs. A TIP savefile, which you can define as simplex or duplex, requires one or two associated STEPCONTROL SAVEFILE SGSs to describe the Exec files that contain the TIP savefile. You must define the savefile as a mass storage, word- addressable file. If you configure a TIP savefile for an application group, you must ensure that Exec configuration values set for TFPMAX and TIPMEF are large enough to include all newly created TIP files. Although you must not manually back up the periodic savefile, safeguards do exist must the file be corrupted or lost. The best safeguard is to declare the savefile as a TIP duplex file. If both legs of the periodic savefile are lost or corrupted, you must reinitialize and rebuild it. After reinitializing it, you can use the IRU queue-item recovery procedure (without database recovery) to build the file, followed by the short recovery procedure. If you must recatalog the periodic savefile, you must use the INIT command for application group recovery during a system reboot. The following example illustrates how to catalog, register, and reserve a duplex TIP periodic savefile with a TIP file name of AP3$SVFILE and TIP file number 300. The two legs of the savefile are TIP$*AP3$SVFILEL1 and TIP$*AP3$SVFILEL

46 Files Used by the 3 rel 300,ap3$svfile dreg TIP$*ap3$svfilel treg TIP$*ap3$svfilel1.,fix treg TIP$*ap3$svfilel2.,fix res The length of each record must be one word. Depending on step control configuration parameters, the 200,000 words might not be sufficient to handle the I/O to the periodic savefile (if not, an I/O ERROR 022 occurs) Audit Control Files This subsection describes the required audit control files used in an integrated recovery environment. Files SYS$h*AT$trail-idLn (1 9) SYS$h*ATtrail-idLn (10 16) SYS$h*AUDIT$nn where: h is the host-id (A through H), for concurrent application groups; for local or switchable application groups, this is not part of the file name. trail-id is the unique audit trail in the range 1 to 16. n is the leg number; 1 for leg 1 of a duplex audit trail or simplex, 2 for duplex leg 2. nn is the application group number (01 to 16). If concurrent application groups are used, the host-id h must be specified after SYS$ in the file name. Host-id h is A through H. Examples of File Names This example indicates an audit control file for leg 1 of a duplex audit trail in application group 3: SYS$*AT$3L

47 Files Used by the Exec This example indicates an audit control file for leg 1 of a duplex audit trail in application group 16: SYS$*AT16L1 This example indicates an audit control file of a tape audit trail on application group 1: SYS$*AUDIT$01 STD# or SHARED# is placed before SYS$ as a directory-id for MHFS systems. Assigned Cataloged by Deleted Freed Restored To the Exec (usually exclusively) whenever the application group is in use (the audit trail file is OPEN). Reassigned during autoboot recovery procedures. If the step control recovery procedures (PANIC or REBUILD) fail, the Exec frees the file and IRU assigns it to reconstruct the queues for step control (short recovery). IRU also assigns it during recovery procedures and during collect, move, verify, and FSAH processing. Next F-cycle of a mass storage audit trail cataloged each time it is opened or swapped. If it is a tape file, it is never cataloged but temporarily assigned. Generally, never. An occurrence of the file is usually deleted, however, when backing up one of its F-cycles (the default on the IRU MOVE command). F-cycle wraparound occurs with a mass storage audit trail. If the maximum number of cataloged F-cycles is reached (system default is 32), the system console operator is prompted to either allow the next F-cycle to be cataloged or not. Accepting F- cycle wraparound destroys the oldest cataloged F-cycle, therefore deleting audit data. Use the IRU MOVE command to archive the audit trail to tape before permitting any wraparound. (1) Whenever audit control swaps to a new cycle as a result of filling the file or swap keyin; (2) whenever the audit trail is closed or down; (3) by IRU, following recovery procedures and collect, move, verify, and FSAH processing. UDS recovery and auditing are not performed because this file is under Exec control. Exec audit control catalogs an Exec audit trail file for each application group, either on mass storage or on tape. The audit trail file is a log of the recoverable processing events occurring within an application group. This log of events is used to restore the database for the application group and to requeue any messages active at the time of system failure. Exec audit control continuously records entries made by components of the integrated recovery application group (for example, Exec step control, FCSS, and UDS Control). IRU reads the file during recovery procedures and during collect, move, verify, and FSAH processing. You can back up the audit trail file with the IRU MOVE command if the storage medium is mass storage. Once an F-cycle of a mass storage audit trail file is saved to

48 Files Used by the Exec tape (IRU MOVE), it does not have to be brought back to mass storage. IRU can use the tape to perform recovery. Entries on the audit trail file include the following information: Periodic savefile summary records that define a recovery point Step control state change records or sentinels that record program progress for recovery purposes User program log entries Database after-looks that record a snapshot of a database page after the update is applied by the database control software Database recovered after-looks, snapshots that indicate how the database page must look after recovery is applied Audit control record sentinels that indicate the point of failure and reboot start/completion Data Capture records when the DMS Data Capture feature is configured Mass storage audit trail files do not have expiration date protection and cannot be hardware write-protected. The following file protections are provided: The current mass storage audit file F-cycle assigned to audit control is assigned with the X and G options, as well as other appropriate options. READ/WRITE keys of application-name/application-name are used when cataloging the ACI file and the mass storage audit files, which have a corresponding step control application. If security is configured in the Exec, mass storage audit files and the ACI file created by audit control have the following security attributes: Clearance level 63 Compartment set ALL (Security Option 2 or 3) IRU, or any other program requiring access to mass storage audit trail files, must have clearance level 63 (the most restrictive) with a compartment set of ALL. Once established, a privileged run can replace the default security attributes with an access control record (ACR). Files SYS$*ACI$n SHARED#SYS$h*ACI$n where: n is the audit trail in the range 1 to 16. h is the host-id (A through H). A leading zero is present for audit trails 1 to

49 Files Used by the Exec Assigned by Cataloged by Deleted Freed by Restored Exec audit control when the audit trail is opened. IRU when accessing the file. Exec audit control when the audit trail is opened and the file does not exist. The Exec catalogs a new F-cycle and reinitializes if a FACILITIES REJECT error occurs or if an I/O error is encountered on the ACI file. Must not be deleted. Exec audit control when the audit trail is closed. IRU following processing that reads the ACI file. Does not have to be dumped or reloaded. This audit control interface (ACI) file records all audit trail file changes that occur. Whenever a media change occurs for a leg of an audit trail, an entry is made in this file. Thus, entries are made whenever a leg is opened, switched (swap for tape, F-cycle for mass storage), or closed. Step control also uses this file during audit-only recovery processing. An ACI file exists for cooperative use by audit control and IRU for each application group. The ACI file is cataloged with read and write keys as follows: read-key write-key Step control application group name, if configured, or TIPWRD, if TIP is configured. If neither TIP nor step control is configured, a read key is not used. Step control application group name, if configured, or TIPWRD, if TIP is configured. If neither TIP nor step control is configured, a write key is not used. The ACI file does not have expiration date protection and cannot be hardware write-protected. The following file protection is provided: The current F-cycle assigned to the ACI file is assigned with the G option, as well as other appropriate options. If security is configured in the Exec, the ACI file created by audit control has the following security attributes: Clearance level 63 Compartment set ALL (Security Option 2 or 3) IRU, or any other program needing to access the ACI file, must therefore have clearance level 63 (the most restrictive) with a compartment set of ALL. Once established, a privileged run can replace the default security attributes with an ACR

50 Files Used by the Exec Files SYS$*ARF$nn SYS$h*ARF$nn where: n is the audit trail in the range 1 to 16. h is the host-id (A through H). A leading zero is present for audit trails 1 to 9. Assigned by Cataloged by Deleted by Freed by Restored Exec audit control when the application or audit trail is initialized or recovered. Exec audit control when the application or audit trail is initialized or recovered. Exec audit control if it is found to be corrupt. It is immediately recataloged. Exec audit control when the application and audit trail is deferred. Does not have to be dumped or reloaded. Repopulated from Exec audit trail configuration when file is recataloged. The audit recovery file (ARF) defines the structure and maintains the state of the audit trail. If the system stops or fails, audit control uses the ARF to recover the state of the audit trail. Audit control automatically updates the ARF when the audit-trail environment changes (for example, an audit trail changes from open to closed or an audit trail swap occurs). For an application group audit trail, the ARF also contains information used for the Exec and IRU short and medium database recovery coordination, and information about XPC or XPC-L. File rollback-page-file Assigned Cataloged Deleted Freed Restored Exclusively to the Exec following Exec registration as a TIP file. Also reassigned to the Exec following system failure as part of the autorecovery bootstrap process. Must be cataloged by the site and registered with the Exec as a TIP file before initializing the application group. Never Never UDS recovery and auditing are not performed because this file is under Exec control. A dump is not required, and the file does not have to be reloaded. The rollback page file must be a TIP file. You must specify its file code on a STEPCONTROL ROLLBACK SGS. You need this file only if you use TIP file control superstructure (FCSS) recoverable files

51 Files Used by the Exec This file is used for TIP FCSS rollback recovery; it can also affect the ability of IRU to recover a UDS application group. If you do not configure the rollback page file for the application group, you do not have to create it. This file is available when the application is active and user programs are accessing FCSS files. It is also used during the short recovery process by FCSS to recover FCSS file updates. This file can be cataloged as word- or sector-addressable. Its size in words is equal to n1 times n2 plus 1,120, where n1 is the number of words per page and n2 is the number of file pages available to roll back. The additional 1,120 words allow enough space for TIP file control information. The following runstream uses TIP number 301 and other information to register and assign a duplex TIP rollback page file. You must possess the appropriate security privileges to execute the TIP utilities used in the runstream. The FCSS file name in this runstream must be the file name used in the Exec configuration STEPCONTROL n ROLLBACK PAGEFILE ID IS treg qual*exec-file1.,fix treg qual*exec-file2.,fix res The reserve format in the FREIPS utility is RES,options TIP-file-number,number-of-records,record-length, TIP-file,Exec-file-leg1/Exec-file-leg2 Reserve enough space for the extra 1,120 words used by TIP file control. In this example, two extra records of 89 words each were added to the 200 mass storage pages required resulting in 202 records being reserved by FREIPS. If you attempt IRU short recovery with a rollback page file configured in the Exec configuration but not registered and assigned to TIP, the following error message appears: *ERROR* 5808 SHORT RECOVER ER MQF$ function xx status 025 Code 25 indicates an FCSS error

52 Files Used by IRU 2.3. Files Used by IRU To perform offline recovery of databases (files managed by UDS or FCSS) or messages, IRU requires several files to be present on the system. Two of these files, the audit trail file and the ACI file, as already discussed, belong to the Exec audit control component. Although these files are managed by audit control, they are also read offline by IRU. IRU directs offline and background-related functions to Rebuild step control queue items and coordinate other short recovery activity Reconstruct a database (files, selected records or pages) from the dump tapes and the audit trail Reconstruct the Message Control Bank (MCB) message retention files (MRF) from the audit trail Restore global transaction information in the TIP rollback page file and the UDS retention files from the audit trail Archive F-cycles of a mass storage audit trail file to tape, allowing the mass storage file space to be reused Enable (UP/CLEAR), disable (DOWN/SET), dump, and reload database files IRU uses two categories of files internally: files used for all application groups and files unique to an application group (that is, files that have separate copies for each application group) IRU Files Used for All Application Groups This subsection describes the IRU files that are used for all application groups. File SYS$LIB$*IRU Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec to your run when you call IRU (@IRU) SOLAR installation of IRU (mode IRU) SOLAR deinstallation of IRU (mode IRU) Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the IRU product object module and APPREC absolute. This file is created when you specify the IRU installation mode IRU. Your site can maintain more than one level of IRU on a system; however, you do not have to install a separate IRU for each UDS application group; you can use one IRU to maintain all 16 UDS application groups. If your site has more than one IRU on a system, you must specify which IRU is to be accessed by call during the SOLAR installation

53 Files Used by IRU File SYS$LIB$*FSAH Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec to Common Name Section of FSAH subsystem when FSAH subsystem is loaded SOLAR installation of FSAH (mode FSAH) SOLAR deinstallation of FSAH (mode FSAH) Exec when FSAH subsystem is deactivated or deinstalled SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD function This file contains the FSAH object module, subsystem, and copy elements required to create an FSAH program. This file is created when you specify the IRU installation mode FSAH. File SYS$LIB$*ALTFSAH Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec to Common Name Section of alternate FSAH subsystem when alternate FSAH subsystem is loaded SOLAR installation of FSAH (mode ALT-FSAH) SOLAR deinstallation of FSAH (mode ALT-FSAH) Exec when FSAH subsystem is deactivated or deinstalled SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD function This file contains the FSAH object module, subsystem, and copy elements required to create an FSAH program. This file is created when you specify the IRU installation mode ALT-FSAH. File SYS$*MCB Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec SOLAR installation of MCB. Installation of IRU (mode IRU) catalogs this file if it is not present on the system. SOLAR deinstallation of MCB Exec FURPUR or FAS to save dummy absolutes placed in this file during the installation of IRU or live absolutes placed in this file during the installation of MCB. FURPUR or FAS

54 Files Used by IRU This file contains live or dummy banks for MCB, which performs message staging, control, and retention. It is included here because the contents of this file affect IRU execution. The Communications Management System (CMS 1100) uses MCB as its interface to the application group for both recoverable and nonrecoverable messages. IRU uses two predefined alternate file common banks (AFCB) for each application group to coordinate message recovery with MCB, a short message recovery bank for use during short recovery and a long message recovery bank for use during long recovery. IRU determines whether an MCB AFCB environment is configured for an application group by finding a relocatable element CBEP$$MCBn, where n is the application group number, in the MCB/IRU AFCB communication file SYS$*MCB. Installing MCB level 5R1 creates the relocatable element, which contains the AFCB bank descriptor indexes (BDI) for the short and long message recovery banks. File project-id*iru$afrun-id where: project-id run-id is the project id associated with the run-id. is the generated run-id. Assigned by Cataloged by Deleted by Freed by IRU IRU on any execution of IRU with the A option present. If a user executes IRU multiple times, IRU catalogs new F-cycles of this for each execution. Not automatically deleted. You must delete this file when you no longer need the contents. IRU at the end of the IRU session. Note: A use name of IRU$AF is attached to the filename. This use name is not freed at the end of the IRU session. This is the IRU alternate print file. It contains a copy of all input and output generated during an IRU session. A new F-cycle of this file is automatically generated each time you call IRU with the A option

55 Files Used by IRU File project-id*fsah$view where: project-id is the project id associated with the run-id. Assigned by Cataloged by Deleted by Freed by IRU IRU (FSAH) when the caller specifies an alternate print file. IRU during FSAH-TERM processing. IRU during FSAH-TERM and FSAH-SETUP processing. This file contains messages generated by IRU during an FSAH session. You can use an editor to view the contents of this file, to see messages that precede a prompt that appears on the console or demand terminal. IRU performs a breakpoint to this file at each prompt, so this file contains only messages issued since the previous prompt, or since the beginning of the FSAH session. File project-id*dmp$pfrun-id where: project-id run-id is the project id associated with the run-id. is the name of the run. Assigned by Cataloged by Deleted by Freed by IRU IRU when a user responds DUMP to an error recovery query. Not automatically deleted. You must delete this file when you no longer need the contents. IRU at the end of the session. This file contains the octal dump of the buffer (for example, audit block) that encountered an error

56 Files Used by IRU File project-id*pmd$pfrun-id where: project-id run-id is the project id associated with the run-id. is the name of the run. Assigned by Cataloged by Deleted by Freed by IRU IRU on encountering an IRU ERROR message if the P option is present. Not automatically deleted. You must delete this file when you no longer need the contents. IRU This file contains the IRU contingency dump and contingency information. File project-id*diag$run-id where: project-id run-id is the project id associated with the run-id. is the generated run-id. Assigned by Cataloged by Deleted by Freed IRU IRU contingency processing when the D option is present. If a user executes IRU multiple times, IRU catalogs a new F-cycle of this file for each execution. Not automatically deleted. You must delete this file when you no longer need the contents. Not freed This file contains a copy of the DIAG$ file generated during IRU contingency processing. IRU generates a new F-cycle of this file each time a session ends in contingency and you specified the D option on the IRU call for that session. Normal contingency processing creates a temporary DIAG$ file. This DIAG$ file is reused for subsequent processor executions and deleted on run termination; this means that information can be lost when additional processors are called or the run terminates. Use the D option to preserve the DIAG$ file in the next F-cycle of DIAG$run-id

57 Files Used by IRU If you specify the D option, the following ECL commands are executed after the IRU contingency handler detects a critical DIAG$PF. If the run is executing in an environment with Security Option 3 or common bank protection set, statement does not include the P option, so the file is cataloged as a private file. File project-id*iru$pfrun-id where: project-id run-id is the project-id associated with the run-id. is the name of the run. Assigned by Cataloged by Deleted by Freed by IRU IRU on first execution of IRU processor if the S option is present; otherwise, it is assigned as a temporary file by IRU. IRU (or freed if it is assigned as a temporary file) whenever an IRU session terminates normally. IRU This is the execution packet file used by the IRU checkpoint-restart capability. It retains the IRU command packet on all IRU commands. During the processing of the DUMP, RELOAD, and RECOVER commands, restart information is periodically saved in the execution packet. The S option on the IRU processor call activates the checkpoint-restart capability. If IRU was initially executed with the S option and the IRU session terminates abnormally, a subsequent execution of IRU (with or without the S option specified) causes IRU to reexecute the original command. The reexecution commences at a subcommand level for the DUMP, RELOAD, and RECOVER commands, which allows IRU to begin execution from a checkpoint within the DUMP, RELOAD, or RECOVER processing. Other IRU commands are restarted at the command level and repeat the entire processing as specified by the original IRU command. The file created by IRU contains your run-id. To take advantage of the IRU checkpointrestart capability, you must either reexecute IRU under the same run-id or use statement on the packet file, project-id*iru$pfrun-id, as iru$pf,new-project-id*iru$pfnew-run-id

58 Files Used by IRU IRU Files Dependent on Application Groups This subsection describes IRU files associated with application groups. Most systems have one of these files for each application group configured. Files application-group-name*dhf-exec-filename (The default dhf-exec-filename is IRU$DH.) dhf-tip-file-number Assigned Cataloged Deleted Freed by Dumped by Reloaded by Whenever an IRU command that accesses it executes Exec files must be cataloged, and TIP files must be registered and reserved with TIP before any IRU commands that access them are executed. Never IRU User: Back up Exec history files with FURPUR or FAS, if available. Use the TIP TFCIO utility to copy TIP history files to tape format. Same processor used to save (that is, FAS, FURPUR, TFCIO) IRU records information about each database DUMP, DUMP CHANGES, and RELOAD command into the dump history file. Dump information includes tape numbers, files dumped, associated audit trail identifiers and dates. These history file records can be used later for automated or history-directed long recovery. Each application group has its own dump history file. During the COMUS build of IRU, COMUS asks whether the history files are configured as Exec or TIP files. The IRU release tape specifies Exec as the default type for history files for all application groups. You can use the IRU ASSUME command to change the name or type of the IRU dump history file for an IRU session. For more information about the IRU ASSUME command, see the Integrated Recovery Utility Operations Guide. The following IRU commands access the dump history file: CLEAR DELETE DISABLE DUMP DUMP CHANGES ENABLE RECOVER (long recovery) RELOAD REPORT UP

59 Files Used by IRU Files qualifier*mhf-exec-filename (The default mhf-exec-filename is IRU$MH.) mhf-tip-file-number where qualifier is the application group name for step control audit trails or the audit trail file name for non-step-control audit trails and moves using an alternate audit trail file name. Assigned Cataloged Deleted Freed by Dumped by Reloaded by Whenever an IRU command or FSAH request that accesses it executes. Exec files must be cataloged, and TIP files must be registered and reserved with TIP before any IRU commands that access them are executed. Never IRU User: Back up Exec history files with FURPUR or FAS, if available. Use the TIP TFCIO utility to copy TIP history files to tape format. Same processor used to save (that is, FAS, FURPUR, TFCIO) If you execute a history file MOVE command, IRU records information about the mass storage audit trail F-cycles and the tapes where IRU moved these F-cycles in the move history file. IRU uses this information to assist in recovery automation. The IRU audit handler also accesses the move history file through the freestanding audit handler (FSAH) interface. Each application group can have its own move history file. During the COMUS build of IRU, COMUS asks whether the history files are configured as Exec or TIP files. The IRU release tape specifies Exec as the default type for history files for all application groups. TPM, COD, and ALAT audit trails cannot use TIP move history files. The following IRU commands access the move history file: COLLECT MOVE RECOVER (long recovery) MEDIUM RECOVER REPORT AUDIT VERIFY You can use the IRU ASSUME command to change the name or type of the IRU move history file for an IRU session. For more information about the IRU ASSUME command, see the Integrated Recovery Utility Operations Guide

60 Files Used by IRU File directory-idiru$nn*filenm$mxxhh where: directory-id nn filenm xx h is SHARED# for concurrent application groups and STD# for local and switchable application groups with multi-host file sharing. This value does not apply for other application groups. is a unique number related to both the MHF set and leg being locked. Numbers 1 to 9 include a leading zero. is the first 6 characters of the move history file name (Exec) or number (TIP) $-filled to 6 characters (both Exec and TIP). is the application group number. Application groups 1 to 9 include a leading zero. is the host-id. Hh applies only for concurrent application groups. Assigned Cataloged Deleted Freed by Dumped by Reloaded by Whenever IRU executes a history file MOVE or REPLICATE command. Whenever IRU executes a history file MOVE or REPLICATE command. At the end of a MOVE or REPLICATE command execution. IRU Not applicable Not applicable The MOVE and REPLICATE commands are the only IRU commands that access this file. This file prevents multiple history file moves at the same time using the same move history file set, leg, and host combination, thus preventing move history file inconsistencies. Files directory-idfilenm*iru$nnnnxxhh directory-idiru$tipnum*iru$nnnnxxhh where: directory-id filenm tipnum nnnn is SHARED# for concurrent application groups and STD# for local and switchable application groups with multi-host file sharing. This value does not apply for other application groups. is the DHF-EXEC-FILENAME (Exec dump history file). is the DHF-TIP-NUMBER (TIP dump history file) zero-filled on the left. is a unique number (range ) associated with the current DUMP command zero filled on the left

61 Files Used by IRU xx h is the application group number. Application groups 1 to 9 include a leading zero. is the host-id. Hh applies only for concurrent application groups. Assigned Cataloged Deleted Freed by Dumped by Reloaded by Whenever IRU executes a DUMP command for a base dump. Whenever IRU executes a DUMP command for a base dump. At the end of a DUMP command execution. IRU Not applicable Not applicable This file prevents execution of simultaneous DUMP commands for a file using the same dump history file. The DUMP command is the only IRU command that accesses this file. Files application-group-name*kf-exec-filename (The default kf-exec-filename is IRU$KF.) kf-tip-file-number Assigned Cataloged Deleted Freed by Dumped by Reloaded by Whenever an IRU command that accesses it executes. If it is an Exec file, you must catalog it before executing a COLLECT command. If it is a TIP file, you must register and reserve it with TIP before executing a COLLECT command. Never IRU User: Back up an Exec key file with FURPUR or FAS, if available, or use the TIP TFCIO utility to copy a TIP key file to tape format. Same processor used to save The following IRU commands access the key file: COLLECT DUMP CHANGES DUMP REPORT KEY FILE The COLLECT command reads the audit trail and collects a list of each page or record that has changed since the last base dump of a file and stores the list in a key file. The key file contains information about the specific page or record updated. Each application group has a key file; each updated page or record within each file has an entry in the key file

62 Files Used by IRU The DUMP CHANGES command dumps the pages or records identified in the key file as having changed since the last base dump. The DUMP command deletes keys stored in the key file for the files being dumped. The key file is not required for the DUMP command, and is only accessed if it is present. During the COMUS build of IRU, COMUS asks whether the key files are configured as Exec or TIP files. The default values for key file configuration variables on the IRU release tape specify the file type as Exec for all application groups. You can use the IRU ASSUME command to change the key file name or type for an IRU session. For more information about the IRU ASSUME command, see the Integrated Recovery Utility Operations Guide. File dir-idiru$*med$rec$nnhh where: dir-id nn h is SHARED# for concurrent applications, STD# for local and switchable applications in a Multi-Host Sharing File (MHFS) environment, and blank otherwise. is the application group number (a leading zero is added for application groups 1 to 9). is the host identifier (A,B, C, or D). The Hh is present only for a concurrent application group. Assigned by Cataloged by Deleted by Freed by IRU IRU IRU IRU This is the recovery lockout file for medium recovery. This file is used to prevent concurrent medium recoveries for a single application group/host, to delay a short recovery until medium recovery is complete, and to prevent simultaneous conflicting long recoveries

63 Files Used by IRU File IRU$*SHRT$$RECYnn where nn is the application group number (a leading zero appears for application groups 1 to 9). Assigned by Cataloged by Deleted by Freed by IRU IRU IRU IRU This is the recovery lockout file for short recovery. This file is used to prevent multiple concurrent short recoveries as well as to prevent other simultaneous conflicting recoveries. File application-group-name*iru$kftip$lk Assigned by Cataloged by Deleted Freed by IRU User or IRU. You might want to catalog this file before executing IRU if you have a TIP key file. If you do not catalog the file, IRU catalogs it during the execution of a DUMP, DUMP CHANGES, or COLLECT command. Never IRU This is a 1-track Exec file required by TIP key files for file-level locking

64 Files Shared by All Application Groups 2.4. Files Shared by All Application Groups This subsection describes the files that are shared by all application groups. File UDS$$SRC*ADT-FILE Assigned by Cataloged by Deleted Freed by Dumped by Reloaded by Application definition table (ADT) code, when necessary for read or write access. Write accesses are caused by the UREP DSR process only. SOLAR installation of UDS Control or UDS security utility prior to initial SOLAR installation if a Security Option 3 system. The V option is used to prevent it from being rolled out. Never. Overwritten by subsequent installation of UDS Control for the default application. ADT code as soon as the read or write access is complete. (This can be subverted by console X keyins). The SUDS FF command can be used to free this file; however, use it only under exceptional conditions. See Free File from UDS Domain (FF) in Section 8 for more information. FURPUR or FAS Same procedure used to dump The ADT, a common data bank, maintains and uses file ADT-FILE (also called the ADT backup file) on mass storage. ADT-FILE is the only UDS file that affects all UDS application groups. The version of file ADT-FILE on the standard release tape contains a single entry for UDS Control, namely, the standard application group (named UDSSRC for application group 3). UDS$ADTCDB is the common data bank that contains the ADT and access routines that reference it. The UREP PROCESS command and UDS Control reference the ADT bank during configuration and initialization. The intercept and connect routines (ICR) also reference the ADT bank. For more information about how to install the ADT bank when Security Option 3 is configured, see the Universal Data System Configuration Guide. File ADT-FILE contains an active entry for each application group in use, a list of alias names for each application group, and transparent entries for application groups recently configured but not yet activated. This file is closely associated with the ADT bank that controls access to UDS. During initialization, UDS Control reads the current ADT from the file. During the UREP dynamic system reconfiguration (DSR) process, a copy of the updated ADT bank is written to this file. You must protect this file; if it becomes corrupted, access to UDS is lost for all application groups

65 Files Shared by All Application Groups You must dump this file after every installation of an application group or after dynamically reconfiguring your system through the UREP dynamic system reconfiguration (DSR) process. The UDS Control utility file contains two Dump Analysis Procedure (DAP) functions, ADTAPPL and ADTALIAS, with which to look at the contents of file ADT-FILE. ADTAPPL displays information relating to the active and transparent entries in the file. ADTALIAS lists the alias names associated with each application group. Use the following sequence of commands to execute ADTAPPL and temp*adt-file. *restore uds$$src*util$. adtappl Caution Always copy ADT-FILE to a temporary file, as in the preceding example. Do not use DAP functions to look at the permanent version of file ADT-FILE. This could cause errors, or it could cause the application group to hang because DAP assigns the file. The ADT must assign file ADT-FILE exclusively whenever it updates it. See also the caution note in File UDS$$SRC*ABSADT$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains absolutes for the ADT AFCB, which are used when UDS common banks are loaded. This is the alternate file for the UDS Control application definition table (ADT) common bank

66 Files Shared by All Application Groups File UDS$$SRC*SECURE-FILE Assigned by Cataloged by Freed by Dump/Reload ADT, DSR, and SUDS SOLAR installation of UDS Control on a system that has Security Option 3 configured. You must save the file. DSR or SUDS following their execution Not required because the file contains no information. If your system has Security Option 3 configured, the security file must be on the system at all times. If this file is not on the system and Security Option 3 is configured, users receive an error whenever they attempt the following SUDS and DSR commands: SUDS DA DSR ADD ALIAS PROCESS CONFIGURATION... INSTALL PROCESS CONFIGURATION... DELETE File UDS$$SRC*UREP$BDI Assigned by Cataloged by Freed by Reload UREP, Universal Compiling System (UCS), Display Processing System (DPS), IPF SQL Interface, and Structured Query Language (SQL*) products SOLAR installation of UREP UREP, UCS, DPS, IPF SQL Interface, or SQL* products FURPUR or FAS This file contains BDIs of the UREP ICR and the RDMS SQL banks called by users. This file is used by UREP to determine the correct UREP common banks to use for an application group. This file is used by UCS to identify which application groups have UREP and the RSA component of RDMS available, and to determine how to access their respective common banks. This file is used by IPF SQL as well to retrieve the BDI for the RSA SQL BDI for bank C$RDMRPLB

67 Files Shared by All Application Groups File STD#UDS$$SRC*INTERFACESEC Assigned by Cataloged by Deleted by Freed by Reload Not applicable UDS security utility prior to initial SOLAR installation if a Security Option 3 system Never Not applicable Not necessary The UDS interface security file applies only to Security Option 3 systems. Users with write access to this file have all UDS Control command privileges. See File STD#UDS$$SRC*RUBSECURITY Assigned by Cataloged by Deleted by Freed by Dump/Reload Not applicable UDS security utility prior to initial SOLAR installation if a Security Option 3 system Never Not applicable Not necessary The RUB security file applies to the XTC system and Security Option 3 systems and ensures that only the RUB run performs RUB-only thread control commands. The RUB run user ID must be the only nonprivileged user ID with write access to this file

68 Files Used Exclusively by Each Application Group 2.5. Files Used Exclusively by Each Application Group This subsection discusses the files that are duplicated for each application group. Each application group has its own copy of UDS Control. The files are presented by product. In general, each file falls into one of three categories: Product files refer to the product itself: the product source, relocatable, and absolute code. Also, utility programs required to generate, install, and run a product are found in product files. UDS source files contain definitions to define the data in your databases. For example, you use UREP commands to create the symbolic form of the data definition, Data Definition Language (DDL) clauses to create a DMS source schema, and Subschema Data Definition Language (SDDL) clauses to create a DMS source subschema. You can use UREP commands to update and report your source definitions. For example, you can produce formatted reports of UREP storage area definitions, your UDS system configuration, RDMS table definitions, or DMS schema and subschema definitions. UDS object files are derived from the encoded form of your source definition files. Use the UREP PROCESS command with the INSTALL option to create the object files. The file description table (FDT) is an example of a UDS object file. For information about how to use the PROCESS command, see the Repository for ClearPath OS 2200 Administration Guide UDS Control Files This subsection describes the UDS Control files. File application-group-qualifier*abs$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the UDS Control I-bank absolutes and the UDS Control utility programs, SUDS and TRCCTL. This file is the alternate file for the UDS common banks and is used during the loading of UDS common banks as well as during the execution of SUDS and TRCCTL

69 Files Used Exclusively by Each Application Group File application-group-qualifier*udsc$pfgsdef Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the UDS Control subsystem in this file SOLAR installation of UDS Contro SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the gate definitions object module for the UDS Control protected fixed-gate subsystem. File application-group-qualifier*udsc$pfgscod Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the UDS Control subsystem in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the code object module for the UDS Control protected fixed-gate subsystem. File application-group-qualifier*udsc$cfgsdef Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the UDS Control subsystem in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the gate definitions object module for the UDS Control chameleon fixed-gate subsystem

70 Files Used Exclusively by Each Application Group File application-group-qualifier*udsc$cfgscod Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the UDS Control subsystem in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the code object module for the UDS Control chameleon fixed-gate subsystem. File application-group-qualifier*abslib$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file UDS security utility or SOLAR installation of UDS Control depending on first need SOLAR deinstallation of UDS Control Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This is the alternate file for the UDS Control thread control intercept and connect routine (ICR) common bank. This file is used during the loading of UDS common banks. Files application-group-qualifier*dumpn(cycle) application-group-qualifier*dumpnpnn(cycle) Assigned by Cataloged by Deleted by Freed by UDS Control UDS Control dump facility User (left cataloged by UDS Control for future analysis) UDS Control The UDS Control dump routine writes dumps to a mass storage file. The dump file names for the default application group are in UDSSRC*DUMPn(cycle) format, where n is a number from 0 to 9 and cycle is the file cycle. If the dump does not fit in one file, additional files with names in the UDSSRC*DUMPnPnn(cycle) format are created, where nn is a 2-digit integer. File numbering starts with

71 Files Used Exclusively by Each Application Group When UDS Control writes a dump, the dump routine takes n as 0 and tries to catalog a file cycle with that name. If cataloging is unsuccessful, n increases by 1 and the dump routine tries to catalog the new file name. The dump routine continues increasing the number by 1 and retrying until it catalogs a file or tries all 10 dump file names. You can use UDS Control dump analysis functions to examine this file. This file is cataloged at 262K tracks with an initial reserve equal to the number of tracks needed in the dump file. The initial reserve calculatation depends directly on the number and size of UDS D-banks expected to be written to the dump file. If you migrate to a Security Option 3 environment, delete all file cycles of the dump file. This ensures that UDS Control catalogs all future cycles as private. If a dump file cataloged public already exists on the system, all future dump files are cataloged public rather than private. File application-group-qualifier*rollbacknnnn Assigned by Cataloged by Deleted Freed by UDS Control UDS Control Never UDS Control UDS Control assigns a set of retention files, depending on the configuration. A retention file contains quick-before-looks and paged deferred updates for a thread. These files can be composed of TIP, Exec, or both file types. UDS Control installation catalogs and initializes retention files. UDS Control also writes to and reads from retention files. The contents of the retention file are used when a step is rolled back or committed. Retention files are empty before the step begins and after the step ends. After a rollback or commit, the file returns to its initial size if it expanded during step execution. During short recovery, UDS uses the contents of the retention file to recover partially completed steps. The UREP configuration attributes used to specify the name, TIP code, prep factor, initial size, maximum size, and qualifier of a retention file are as follows: RETENTION-FILENAME RETENTION-FILE-TIP-CODE RETENTION-FILE-PREP-FACTOR RETENTION-INITIAL-POSITIONS RETENTION-MAXIMUM-POSITIONS RETENTION-QUALIFIER

72 Files Used Exclusively by Each Application Group Additional UREP configuration attributes used to describe the structure and handling of retention files are as follows: RETENTION-FILE-ALGORITHM RETENTION-FILE-FIXED-SEG-SIZE RETENTION-FILE-WARNING-LEVEL-TRACKS NUMBER-RETENTION-FILE-DEVICES For information about modifying UREP configuration attributes, see the Repository for ClearPath OS 2200 Administration Guide. The UREP configuration attribute NUMBER-RETENTION-FILE-DEVICES is used by UDS Control to determine who is responsible for cataloging the retention files. If the attribute value is 1, UDS Control catalogs and assigns the retention files. If the attribute value is greater than 1, UDS Control assumes that the user has cataloged the retention files and UDS Control only needs to assign the retention files. UDS Control catalogs retention files with position granularity. The UREP configuration attributes RETENTION-INITIAL-POSITIONS and RETENTION-MAXIMUM-POSITIONS pertain to the single-file retention file algorithm. The RETENTION-INITIAL-POSITIONS attribute determines the initial reserve for single-file retention files. For the retention file pool algorithm, UREP determines the total number of tracks necessary for each retention file, using the RETENTION-MAXIMUM-POSITIONS attribute to determine the initial reserve. When UDS Control catalogs retention files, the number of tracks for each retention file is rounded to the next multiple of positions and the retention file is cataloged with position granularity. For example, a retention file specified as less than 64 tracks is cataloged as 1 position (64 tracks); a retention file specified as 65 tracks is cataloged as 2 positions (128 tracks). File application-group-qualifier*sys-file Assigned by Cataloged by Deleted Freed by Dumped by Reloaded by First user accessing the application group after installation assigns the file. It is also assigned during the UREP dynamic system reconfiguration (DSR) process and by UDS Control. Initial SOLAR installation of UDS Control, or UDS security utility prior to initial SOLAR installation if a Security Option 3 system, for the default application group. The UREP PROCESS CONFIGURATION command, or UDS security utility if a Security Option 3 system, prior to SOLAR installation of UDS Control for an alternate application group. Reinitialized by any UDS Control installation UDS Control and dynamic system reconfiguration (DSR) User Same procedure used to dump

73 Files Used Exclusively by Each Application Group This file contains information based on the UDS applications configuration. In addition to current configuration information, this file also includes transparent configuration information, and is a backup for important UDS Control and DMS main storage tables. This file is used during the UREP DSR process and whenever an application group is initialized. It must be dumped after every installation of an application group or after dynamically reconfiguring the system through the UREP DSR process. Each application group has its own system file. The DSR writes to it; UDS Control reads and updates it. File application-group-qualifier*tracefile Assigned by Cataloged by Deleted by Freed by TRCCTL (the trace control program) TRCCTL User User The trace file is created when the trace control program (TRCCTL) is used. You can change the size (initially 128 tracks) and name of the trace file during the trace session, which starts when you turn on trace. For more information about how to use TRCCTL, see Section 7. This file contains diagnostic and statistical information collected during the execution of TRCCTL. This file is treated as a circular buffer with fixed-size blocks. File application-group-qualifier*util$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by User through DUMPER for dump processing SOLAR installation of UDS Control SOLAR deinstallation of UDS Control User after UDS dump files are processed SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This UDS Control utilities file contains dump analysis routines, COMUS build routines, SOLAR installation routines, and other miscellaneous elements used during UDS dump processing. This file also contains the symbolic code for the SERVICE run

74 Files Used Exclusively by Each Application Group RDMS Files This subsection describes RDMS files. Files SYS$LIB$*RDMS alternate-application-group-qualifier*rdms Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of RDMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of RDMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the RDMS product Dump Analysis Procedure (DAP) functions and is used during the accessing or updating of relational data. This file also contains addstreams, which are added during UREP installation to create storage areas, and relational views used by RDMS. Files SYS$LIB$*RDMS$CFGSCOD alternate-app-group-qualifier*rdms$cfgscod Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the RDMS subsystem in this file UDS security utility or SOLAR installation of RDMS depending on first need SOLAR deinstallation of RDMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the RDMS and RSA product chameleon subsystems. The file is used during the accessing or updating of relational data

75 Files Used Exclusively by Each Application Group Files SYS$LIB$*RDMS$CFGSDEF alternate-app-group-qualifier*rdms$cfgsdef Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to the RDMS subsystem in this file UDS security utility or SOLAR installation of RDMS depending on first need SOLAR deinstallation of RDMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the RDMS and RSA product chameleon subsystem public gates. The file is used during the accessing or updating of relational data. Files SYS$LIB$*SYS$LIB$*RDMSLIB alternate-app-group-qualifier*rdmslib Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of RDMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of RDMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the RDMS intercept and connect routine (ICR) absolutes for both basic mode and extended mode. The file is used when accessing or updating relational data

76 Files Used Exclusively by Each Application Group Files SYS$LIB$*RSA alternate-app-group-qualifier*rsa Assigned by Cataloged by Freed by Deleted by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of RDMS or UDS security utility prior to SOLAR installation if a Security Option 3 system Exec SOLAR deinstallation of RDMS SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream The RSA component of RDMS responds to subroutine calls in user programs containing relational commands and submits the relational commands to RDMS. This file is used during the accessing and updating of relational data. This file also contains the extended mode object module (RSAC-UCSEMOM), which is called by all Universal Compiling System (UCS) programs. Files application-group-qualifier*ecm$file application-group-qualifier*eeam$file application-group-qualifier*frdt$file application-group-qualifier*rdt$file Assigned by Cataloged by Deleted Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS when RDMS or UREP is used UREP during installation Never UDS Control if no threads are accessing the file and all pages are flushed from memory. Also freed by an IRU DOWN command. TRUE TRUE IRU DUMP command IRU RELOAD command The ECM$FILE, EEAM$FILE, and FRDT$FILE files are interdependent and must be dumped along with the repository meta-database files and the RDMS files listed below. The RDT$FILE file is related to RDMS storage areas and the repository meta-database. These files are interdependent and must be dumped and recovered together

77 Files Used Exclusively by Each Application Group This file also contains all RDMS table descriptions and is used during the accessing and updating of relational data. You must recover this file when you recover the repository meta-database and the following RDMS files: application-group-qualifier*auth$file application-group-qualifier*dep$file application-group-qualifier*lob$sa$file application-group-qualifier*null$file application-group-qualifier*params$file application-group-qualifier*part$file application-group-qualifier*rdm$dropfile application-group-qualifier*routine$file application-group-qualifier*sch$file application-group-qualifier*stats$file application-group-qualifier*trig$file application-group-qualifier*trigcol$file application-group-qualifier*viewdep$file You must also dump the storage areas that were affected by the SQL CREATE INDEX, DROP INDEX, ALTER TABLE ADD CONSTRAINT UNIQUE, and ALTER TABLE ADD PARTITION commands. When recovering a storage area of a partitioned table, use the RDMUTL DETACH statement to detach the partition from the table. This can be accomplished either before or after the recovery of the storage area. After recovering the storage area, use the RDMUTL ATTACH statement to reattach the partition. This process verifies that the storage area is in the proper format

78 Files Used Exclusively by Each Application Group Files application-group-qualifier*auth$file application-group-qualifier*dep$file application-group-qualifier*lob$sa$file application-group-qualifier*null$file application-group-qualifier*params$file application-group-qualifier*part$file application-group-qualifier*rdm$dropfile application-group-qualifier*routine$file application-group-qualifier*sch$file application-group-qualifier*stats$file application-group-qualifier*trig$file application-group-qualifier*trigcol$file application-group-qualifier*viewdep$file Assigned by Cataloged by Deleted Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS Control when RDMS or UREP is used UREP during installation Never UDS Control when no threads are accessing the file and all pages are flushed from memory. Also freed by an IRU DOWN command. TRUE TRUE IRU DUMP command IRU RELOAD command The contents of these files are as follows. File AUTH$FILE DEP$FILE LOB$SA$FILE NULL$FILE PARAMS$FILE Contents Access authorization information (GRANT and REVOKE statement information) for RDMS tables that have controlled data access. It is used whenever RDMS accesses a table for which data access control is active. AUTH$FILE is a relational file. The owner of RDMS.AUTHTABLE can view the authorization records within the table. List of all dependent SQL routines (stored procedures and functions) and triggers for each related table. Table RDMS_LOB_STORAGE_AREAS, which contains storage area names for all BLOB columns. Table used internally by RDMS. Table RDMS_PARAMETERS, which includes a list of parameter attributes for each SQL routine

79 Files Used Exclusively by Each Application Group File RDM$DROPFILE ROUTINE$FILE SCH$FILE STATS$FILE TRIG$FILE TRIGCOL$FILE VIEWDEP$FILE Contents Table RDMS_DROPPED_OBJECTS, which contains information about schema objects either explicitly or implicitly dropped during database and security maintenance operations. Table RDMS_ROUTINES, which includes a list of all SQL routines and their attributes (for example, the number of parameters). List of schema names that were created. Table STATS, which contains table statistics used by the RDMS optimizer if the command SET STATISTICS ON is in effect. Table RDMS_TRIGGERS, which contains a list of triggers and the SQL routines invoked by them, together with the schema that owns each trigger. Table TRIGGERED_COLUMN, which contains a list of all triggers and columns related to them. Table VIEWDEPS, which lists the dependent views for each relational table. It is updated whenever views are created and dropped. It is used by RDMS for processing the SQL statements CREATE VIEW, DROP VIEW, ALTER TABLE, DROP TABLE, FUNCTION, PROCEDURE, DROP FUNCTION, DROP PROCEDURE, GRANT, and REVOKE. All these files are interdependent, so you must recover these files together whenever you recover the repository meta-database and application-group-qualifier*rdt$file. For more information about these tables, see the Relational Database Server for ClearPath OS 2200 Administration Guide

80 Files Used Exclusively by Each Application Group DMS Files These DMS components use the files identified in this section. Data Management Routine (DMR), the online network data manager DDL and SDDL processors Data manipulation languages preprocessors (ADMLP and FDMLP) Data Management Utility (DMU) Data Reorganization Utility (DRU) File application-group-qualifier*dmrmt$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec when loading DMS logical data manager (LDM) banks and accessing DDL and SDDL processors. Also assigned by UREP. Optionally accessed by the DML processors (ADMLP and FDMLP) during a run unit compilation to place information in the UREP metadatabase. SOLAR installation of DMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of DMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This absolute file, which SOLAR installs during DMS installation, is the alternate file for the DMS common banks. File application-group-qualifier*dmslib$ Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of DMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of DMS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This is the alternate file for the DMS ICR (UDS$DMRICR), DMS shell (UDS$DMRSHELL), and DMS linker (UDS$DMRLINKER) common banks. This file is read when DMS common banks are loaded

81 Files Used Exclusively by Each Application Group File application-group-qualifier*d$mr Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by User SOLAR installation of DMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of DMS User SOLAR LIBSAVE runstream SOLAR LIBLOAD runstream This file contains the CBEP$$DMS element that is registered with the Collector at installation and used when user programs are collected. This file is registered with the Collector for the default application group. See the Software Products Installation Guide for more information on preventing Collector registration. This file also contains the DMSSHELL BDI/OM element that links the UCS programs. File application-group-qualifier*dms$util Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by User while processing a dump generated by UDS SOLAR installation of DMS or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of DMS User after dump processing SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This DMS utility file contains routines required to process DMS tables in a dump and is used whenever a UDS dump is processed

82 Files Used Exclusively by Each Application Group Files application-group-qualifier*ddl$qlp application-group-qualifier*ddl$sch application-group-qualifier*ddl$scr application-group-qualifier*ddl$srec application-group-qualifier*ddl$ssrec application-group-qualifier*ddl$sub Assigned by Cataloged by Deleted Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS Initial SOLAR installation of UREP Never. Subsequent SOLAR installation of UREP checks for the file's existence. If it is not cataloged, a new file is cataloged. UDS Control when no threads are accessing these files and all pages are flushed from memory. Also freed by an IRU DOWN command. TRUE FALSE IRU DUMP command IRU RELOAD command To provide protection for meta-database information in a Security Option 3 environment, these six files are cataloged as private files. This prevents unauthorized access to this information from outside the UDS environment. These files are public files in all other security configurations. Following the DMS installation, if you wish to have these files cataloged with an initial reserve, you must first save the original files to temporary files and then delete the files. After recataloging the files, copy them from the temporary files. The following example shows how to catalog one of these files with an initial application-group-qualifier*ddl$qlp.,f/3000//3000 If the application group is configured to allow shared mass storage files, the files must be cataloged as shared. You must reload all shared mass storage files together whenever it is necessary to reload one or more. These six areas contain the database created while processing a source schema with the DDL processor. The database is referred to as the meta-database and is used by the SDDL processor when processing source subschemas. These six areas must be available during DDL or SDDL execution. The repository also accesses these areas for some UREP commands

83 Files Used Exclusively by Each Application Group Note: On systems with a cache/disk subsystem, the SOLAR installation of UREP catalogs the six meta-database areas with the S option (storethru) to ensure that the files are stored through to the disk whenever one of the files is updated. All functions that write to the file store through to the disk, thus facilitating cache/disk recovery. If you do not require this capability, you can recatalog the six areas without the S option. However, your areas can remain cataloged with the S option even though you do not have a cache/disk subsystem, without any adverse effects. When you create a schema, the Data Definition Language (DDL) processor updates the meta-database. The Subschema Data Definition Language (SDDL) processor must access the meta-database to create subschemas for a schema. UREP accesses the meta-database areas to copy information to the repository so the repository manager can build FDTs for the schema, subschema, and database areas. The standard configuration of meta-database files specifies no auditing. You can use UREP to modify the configuration if you want the files to be audited. Each application group has a separate set of meta-database files associated with it; you must dump and reload the meta-database files for each application group along with the associated repository files. After you build the absolute schema, subschemas, and FDTs, the meta-areas are no longer required unless you plan to compile additional subschemas against the schema. After you create a source schema with the DDL processor, you must build a file description table (FDT) for each storage area declared in the schema. You must also create FDTs for the files that contain the schema and subschema absolutes. The DDL and SDDL processors yield sufficient data to permit UREP to generate DMS FDTs. In the repository, you can produce all the storage areas for a schema (plus the FDT for its absolute area) with the PROCESS SCHEMA command: PROCESS SCHEMA schema-name INSTALL. Similarly, you can use the PROCESS SUBSCHEMA command to construct the FDT for the subschema file: PROCESS SUBSCHEMA subschema-name FOR SCHEMA schema-name INSTALL. The following rules apply for determining the qualifier created in an FDT by the PROCESS... INSTALL command: When you create a schema, subschema, or storage area in the repository, use the respective user-defined qualifier as an attribute for the entity. For the PROCESS SCHEMA or PROCESS SUBSCHEMA commands, the system uses the information generated by the DDL and SDDL processors to create the FDTs. The repository, therefore, contains no qualifiers for areas. In the source schema or subschema, you can specify qualifiers for the schema and subschema files. The system places the qualifier in the FDT for the file. You can use UREP commands to add a qualifier after you build the FDT for the file. If you have not specified a qualifier in the repository, the LDM-QUALIFIER value defined for the DMS-LDM entity type is used

84 Files Used Exclusively by Each Application Group If you have not defined an LDM-QUALIFIER value for the DMS-LDM entity type, the APPL-QUALIFIER value of the configuration is used. The APPL-QUALIFIER value is the default LDM-QUALIFIER value for the DMS-LDM entity type. After you process a schema or subschema with the DDL or SDDL processor, ensure that the LDM-QUALIFIER value defined for the DMS-LDM entity type contains the correct entry before you issue a PROCESS SCHEMA or PROCESS SUBSCHEMA command. File application-group-qualifier*sys-chg-file Assigned by Cataloged by Deleted Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS Control during execution of test mode program Initial SOLAR installation of UREP Never. Subsequent SOLAR installation of UREP checks for the existence of this file. If it is not cataloged, a new file is cataloged. UDS Control when no threads are accessing the file and all pages are flushed from memory. Also freed by an IRU DOWN command. TRUE FALSE User: FURPUR or FAS User: FURPUR or FAS To provide protection of the database information in a Security Option 3 environment, the DMS system change file SYS-CHG-FILE is cataloged as a private file. This prevents unauthorized access to this information from outside of the UDS environment. This file is a public file in all other security configurations. Following the UREP installation, if you wish to have this file cataloged with an initial reserve, you must first save the original file to a temporary file and then delete the original file. After recataloging the file, copy it from the temporary file. The following example shows how to catalog the file with an initial application-group-qualifier*sys-chg-file.,f/3000//3000 This file, the system change file, is used whenever a program is executed in test mode and a user change file is not specified

85 Files Used Exclusively by Each Application Group UREP Files This subsection describes the UREP files. Files SYS$LIB$*UREP alternate-application-group-qualifier*urep$abs Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of UREP or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR deinstallation of UREP Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the UREP product absolutes (that is, the UREP processors). This file serves as the file for the UREP AFCBs, and is used whenever the repository is accessed. UREP processors exist apart from application groups. One copy of this file can, therefore, support multiple application groups. Files UREP*UTILITY alternate-application-group-qualifier*urep$util Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by User when executing the repository examples in the file. DDFCONFIG runstreams when reconfiguring UREP. SOLAR installation of UREP SOLAR deinstallation of UREP User SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This UREP utilities file contains examples that illustrate how to use UREP. This file is also used during UREP installation and by the DDFCONFIG processor. This file also contains sample temporary correction files (TCF) for generating UREP for an alternate application group

86 Files Used Exclusively by Each Application Group File application-group-qualifier*fdt$ Assigned by Cataloged by Deleted by Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS Control on the first access to an application group file UREP during installation Never. Reinitialized by SOLAR installation of UREP. IRU DOWN command TRUE (set during UREP installation) FALSE IRU DUMP command IRU RELOAD command This file descriptor table (FDT) file and its associated files maintain the machine-readable representation of storage area definitions. You use the UREP data storage definition (DSD) process to create storage area definitions, where file attributes are recorded. This information is compiled into the FDT. This file is the directory of UDS files for the application group. This file is used by the UREP PROCESS command. From this file, UDS Control obtains information about each storage area. IRU commands that work with UDS files also access and manipulate this file. Caution Use care when disabling the FDT$ file with IRU. Once it is disabled, no other file can be accessed because the FDT entries for all other files are contained in the FDT$ file

87 Files Used Exclusively by Each Application Group Files application-group-qualifier*urep$me$name application-group-qualifier*urep$a$types application-group-qualifier*urep$e$types application-group-qualifier*urep$r$types application-group-qualifier*urep$me application-group-qualifier*urep$me$id application-group-qualifier*urep$qen application-group-qualifier*urep$entname application-group-qualifier*urep$name$id application-group-qualifier*urep$ent application-group-qualifier*urep$ent$ord application-group-qualifier*urep$rela application-group-qualifier*urep$rel$ord application-group-qualifier*urep$ea application-group-qualifier*urep$ea$qen application-group-qualifier*urep$ea$desc application-group-qualifier*urep$ra application-group-qualifier*urep$ra$qen application-group-qualifier*urep$ra$desc application-group-qualifier*urep$acl Assigned by Cataloged by Deleted Freed by UDS Recovered Status UDS Audited Status Dumped by Reloaded by UDS Control to the UDS Control banks DDFCONFIG during initial SOLAR installation of UREP Never. Reinitialized by a subsequent Mode B SOLAR installation of UREP. UDS Control banks when the FDT entry is freed (no thread is accessing the file) and all pages are flushed from UDS buffer space. Also freed by an IRU DOWN command. TRUE. All 20 files are set to TRUE during installation of UREP. TRUE. All 20 files are set to TRUE during installation of UREP. IRU DUMP command IRU short recovery. If recovery fails, you can use IRU long or selective recovery (RELOAD/RECOVER) as long as the file was saved by the IRU DUMP command. You must dump the FDT$ file with the repository files whenever you make significant storage area changes, or changes to RDMS table definitions, in UDS files. You must define the repository files as recoverable and must include them in the plan for dumping and reloading

88 Files Used Exclusively by Each Application Group You must also recover the repository files when you recover the following system files: application-group-qualifier*auth$file application-group-qualifier*dep$file application-group-qualifier*ecm$file application-group-qualifier*eeam$file application-group-qualifier*frdt$file application-group-qualifier*lob$sa$file application-group-qualifier*null$file application-group-qualifier*params$file application-group-qualifier*part$file application-group-qualifier*rdm$dropfile application-group-qualifier*rdt$file application-group-qualifier*routine$file application-group-qualifier*sch$file application-group-qualifier*stats$file application-group-qualifier*trig$file application-group-qualifier*trigcol$file application-group-qualifier*viewdep$file File application-group-qualifier*ddl$ Assigned by Cataloged by Deleted by Freed by Dump Reload UDS to common bank SOLAR installation of UREP Reinitialized by a subsequent SOLAR installation of UREP IRU DOWN command FURPUR or FAS (you cannot use IRU to dump the schema file) Same processor used to dump To provide protection of database information in a Security Option 3 environment, the system catalogs the DDL$ file as a private file. This prevents unauthorized access to this information from outside of the UDS environment. This file remains a public file in all other security configurations. The DMS absolute elements, SCHEMATA, SCHEMATADMU, SUB-DDS, SUB-DDL, and SUB-SDDL, must be in a file named DDL$. These elements are used by UREP, Data Definition Language (DDL), Subschema Data Definition Language (SDDL), and Data Management Utility (DMU). Each application group can have different SCHEMATA specifications, making the qualifier, therefore, the application group qualifier. This file is accessed when executing the DDL and SDDL processors. It can also be accessed by some UREP commands

89 Files Used Exclusively by Each Application Group File application-group-qualifier*urep$abslib Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of UREP or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR removal of UREP Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the absolute for the UREP ICR bank AFCB. This file is not shared by different application groups. In a Security Option 3 environment, this file always has the security attributes of the library subsystem. File application-group-qualifier*urep$absd Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file SOLAR installation of UREP or UDS security utility prior to SOLAR installation if a Security Option 3 system SOLAR removal of UREP Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the absolutes for the UREP subsystem AFCBs (including the UREP gate bank). In a Security Option 3 environment, this file always has the security attributes of the UDS subsystem

90 Files Used Exclusively by Each Application Group File application-group-qualifier*urep$elmsabs Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec during first access to an AFCB in this file UDS security utility or SOLAR installation of UREP depending on first need SOLAR removal of UREP Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains the ELMS messages for UREP. This file can be shared by different application groups. In a Security Option 3 environment, this file always has the security attributes of the library subsystem. File application-group-qualifier*secure-urep Assigned by Cataloged by Deleted Freed by Dumped by Reloaded by UREP during a privileged operation such as installation SOLAR installation of UREP Never UREP Not required, file contains no information Not required, file contains no information This file provides security to certain sensitive interfaces to UREP. This file is not shared by different application groups. In a Security Option 3 environment, this file has the security attributes of UDS$$SRC*SECURE-FILE. If security is a concern, you can use TeamQuest SIMAN to change the security attributes of this file. Only users privileged to do installations or major application group maintenance, for example, DDFCONFIG, must have privileges to assign this file

91 Files Used Exclusively by Each Application Group File application-group-qualifier*urep$dumpn Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by UREP when a contingency occurs causing a dump UREP when a contingency occurs causing a dump User UREP Not required, file is needed only for problem analysis Not required, file is needed only for problem analysis The UREP dump routine writes dumps to a mass storage file in DIAG$ format. The dump file names for the default application group are UDS$$SRC*UREP$DUMPn(cycle), where n is an integer from 0 to 9 and cycle is the file cycle. The dump routine starts with n at 0 and increments the number until the file is successfully cataloged. When a UREP dump is processed, the dump file name and cycle are displayed in the PRINT$ file for the run executing the dump SFS File This subsection describes the SFS file. Files SYS$LIB$*SFSLIB alternate-application-group-qualifier*sfslib Assigned by Cataloged by Deleted by Freed by Dumped by Reloaded by Exec SOLAR installation of SFS SOLAR deinstallation of SFS Exec SOLAR LIBSAVE runstream once after installation SOLAR LIBLOAD runstream This file contains SFS intercept and connect routine (ICR) (C2PICR) AFCBs Absolutes for the SFS interface modules (C2SFSM$ and C2SFSD$) The absolute for the SFS table conversion module (C2P$) The error code module (C2SFSE$) Relocatable and omnibus CBEP$$SFS elements

92 File Assignment Limits 2.6. File Assignment Limits The maximum number of Exec files that can be assigned by a UDS application group at the same time is 4,096. This is also the maximum number of files that can be assigned to a large common name section. For individual systems, the number is probably lower owing to other system resource limits. For information about using removable disc pack files, see the Exec Administration Reference Manual Summary of Files and Characteristics Table 2 1 through Table 2 10 summarize the files already described in this section Executive Control Files Table 2 1 describes the Exec control files. Table 2 1. Executive Control Files File Type Cataloged By / When Updated Audit Status Saved Periodic savefile Audit trail files Audit control interface file Rollback page file TIP/Exec Exec / initial boot Exec/tape Exec / first access Exec Exec / first access TIP User / before use Yes n/a No Yes n/a Yes (Saved by IRU MOVE, or n/a) Yes n/a No Yes n/a No

93 Summary of Files and Characteristics Default Product Files Note: All of the following applies to Table 2 2 through Table 2 9. File Names File names correspond to the default or standard application group 3. Symbols * File saved by LIB-SAVE # File can be saved by FURPUR, FAS, or TIP utilities (for TIP files) + File saved by IRU DUMP & File saved by LIB-SAVE dump Numbered Notes in Tables The following notes apply to the tables. (1) You can configure history and key files as Exec or TIP. If one is an Exec file, use FURPUR or FAS to back it up. If one is a TIP file, create duplicate file legs. For added protection, use the TIP load/dump utility program TFCIO TIPOUT to copy a TIP file to tape format. History files must exist if you plan to use history-directed commands. (2) You must save files ADT-FILE and SYS-FILE to tape whenever you configure or reconfigure your systems. (3) You can use FURPUR and FAS to dump this file. (4) You can use FURPUR, FAS, or TIP utilities to dump file SYS-FILE or SECURE-FILE. If your TIP SYS-FILE file becomes corrupt when it is flagged as "do not read" (DNR) and "do not write" (DNW), you cannot reload your TIP SYS-FILE file until the DNR/DNW flags are cleared. To clear these flags, you must free the file from TIP, delete it, recatalog file SYS-FILE, reload file SYS- FILE from backup, and reassign the file to TIP. (5) RDMS storage areas (that is, data files); repository files; and AUTH$FILE, RDT$FILE, STATS$FILE, VIEWDEP$FILE, DEP$FILE, FRDT$FILE, LOB$SA$FILE, NULL$FILE, PARAMS$FILE, PART$FILE, RDM$DROPFILE, ROUTINE$FILE, SCH$FILE, TRIG$FILE, and TRIGCOL$FILE are closely interrelated. You must dump them all together. (6) DMS meta-database files are related; you must dump them all together. (7) The repository files and RDMS files are related; you must dump them all together. The default repository storage area attribute value of AUDITED is TRUE for UREP files. (8) The only time you must copy the schema file for SCHEMATA is when you create or change a schema or subschema. Always copy the schema file when you dump the meta-database files. You must dump a copy of the schema file and the DMS database files at the same time to reduce the risk of using a copy of the database with an incorrect version of the schema

94 Summary of Files and Characteristics (9) You can use FURPUR, FAS, or TIP utilities to dump this file. (10) If you reload the FDT$, RDT$FILE, FRDT$FILE, ECM$FILE, or EEAM$FILE, you must refresh UDS by doing one of the following: A SUDS II command, followed by IRU short recovery A SUDS IL command A UREP PROCESS CONFIGURATION... INSTALL command, followed by an activation of the new configuration IRU Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 2. Default IRU Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDSSRC*IRU$DH (1) TIP/Exec User / before use UDSSRC*IRU$MH (1) TIP/Exec User / before use UDSSRC*IRU$KF TIP/Exec User / before use Yes False Periodic# Yes False Periodic# Yes False Periodic# UDS Control Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 3. Default UDS Control Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDS$$SRC*ABS$ Exec UDS security utility or SOLAR install UDS$$SRC*INTERFACESEC Exec UDS Security Utility before install UDS$$SRC*RUBSECURITY Exec UDS Security Utility before install No n/a After install* Yes n/a After install# Yes n/a After install#

95 Summary of Files and Characteristics Table 2 3. Default UDS Control Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDS$$SRC*ABSADT$ Exec UDS security utility or SOLAR install UDS$$SRC*UDSC$PFGSDEF Exec UDS security utility or SOLAR install UDS$$SRC*UDSC$PFGSCOD Exec UDS security utility or SOLAR install UDS$$SRC*UDSC$CFGSDEF Exec UDS security utility or SOLAR install UDS$$SRC*UDSC$CFGSCOD Exec UDS security utility or SOLAR install UDS$$SRC*ABSLIB$ Exec UDS security utility or SOLAR install UDS$$SRC*ADT-FILE (2,3) Exec UDS security utility or SOLAR install No n/a After install* No n/a After install* No n/a After install* No n/a After install* No n/a After install* No n/a After install* Yes n/a Periodic# UDSSRC*DUMPn UDSSRC*DUMPnPnn Exec UDSC dump No n/a No UDS$$SRC*ROLLBACKnnnn TIP/ Exec UDSC initialization Yes n/a No UDS$$SRC*SECURE-FILE Exec UDS Security Utility before install No n/a After install# UDS$$SRC*SYS-FILE (4) TIP/ Exec UDS security utility or SOLAR install Yes n/a Periodic# UDSSRC*TRACEFILE Exec TRCCTL execution No n/a No UDS$$SRC*UTIL$ Exec SOLAR install No n/a After install*

96 Summary of Files and Characteristics RDMS Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 4. Default RDMS Application Group Files File Type Cataloged By / When Updated Audit Status Saved SYS$LIB$*RDMS Exec UDS security utility or SOLAR install SYS$LIB$*RDMSLIB Exec UDS security utility or SOLAR install SYS$LIB$*RSA Exec UDS security utility or SOLAR install No n/a After install* No n/a After install* No n/a After install* UDS$$SRC*RDT$FILE (5, 10) Exec UREP install Yes True Periodic+ UDS$$SRC*AUTH$FILE (5) Exec UREP install Yes True Periodic+ UDS$$SRC*STATS$FILE Exec UREP install Yes True Periodic+ SYS$LIB$*RDMS$CFGSCOD Exec UDS security utility or SOLAR install SYS$LIB$*RDMS$CFGSDEF Exec UDS security utility or SOLAR install No n/a After install* No n/a After install* UDS$$SRC*VIEWDEP$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*DEP$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*ECM$FILE (10) Exec UREP install Yes True Periodic+ UDS$$SRC*EEAM$FILE (10) Exec UREP install Yes True Periodic+ UDS$$SRC*NULL$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*PARAMS$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*ROUTINE$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*SCH$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*TRIGCOL$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*TRIG$FILE Exec UREP install Yes True Periodic+ UDS$$SRC*FRDT$FILE (10) Exec UREP install Yes True Periodic+ UDS$$SRC*RDM$DROPFILE Exec UREP install Yes True Periodic+ UDS$$SRC*LOB$SA$FILE Exec UREP install Yes True Periodic

97 Summary of Files and Characteristics Table 2 4. Default RDMS Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDS$$SRC*PART$FILE Exec UREP install Yes True Periodic DMS Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 5. Default DMS Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDS$$SRC*DMRMT$ Exec UDS security utility or SOLAR install UDS$$SRC*DMSLIB$ Exec UDS security utility or SOLAR install UDS$$SRC*D$MR Exec UDS security utility or SOLAR install UDS$$SRC*DMS$UTIL Exec UDS security utility or SOLAR install No n/a After install* No n/a After install* Yes n/a Periodic* No n/a After install* UDS$$SRC*DDL$QLP Exec UREP install Yes False Periodic+ UDS$$SRC*DDL$SCH Exec UREP install Yes False Periodic+ UDS$$SRC*DDL$SCR Exec UREP install Yes False Periodic+ UDS$$SRC*DDL$SREC Exec UREP install Yes False Periodic+ UDS$$SRC*DDL$SSREC Exec UREP install Yes False Periodic+ UDS$$SRC*DDL$SUB Exec UREP install Yes False Periodic+ UDS$$SRC*SYS-CHG-FILE TIP/ Exec UREP install Yes False Periodic &

98 Summary of Files and Characteristics UREP Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 6. Default UREP Application Group Files File Type Cataloged By / When Updated Audit Status Saved SYS$LIB$*UREP Exec UDS security utility or SOLAR install No n/a After install* UREP*UTILITY Exec SOLAR install No n/a After install* UDS$$SRC*FDT$ (10) TIP/ Exec UREP install Yes False Periodic+ UDS$$SRC*UREP$BDI (9) Exec UREP install Yes n/a After install# UDS$$SRC*UREP$ME$NAME Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$A$TYPES Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$E$TYPES Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$R$TYPES Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ME Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ME$ID Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$QEN Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ENTNAME Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$NAME$ID Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ENT Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ENT$ORD Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$RELA Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$REL$ORD Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$EA Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$EA$QEN Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$EA$DESC Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$RA Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$RA$QEN Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$RA$DESC Exec UREP install Yes True Periodic+ UDS$$SRC*UREP$ACL Exec UREP install Yes True Periodic

99 Summary of Files and Characteristics Table 2 6. Default UREP Application Group Files File Type Cataloged By / When Updated Audit Status Saved UDS$$SRC*DDL$ (7,8,9) Exec UREP install No n/a After install# UDS$$SRC*UREP$ABSLIB Exec UDS security utility or SOLAR install UDS$$SRC*UREP$ABSD Exec UDS security utility or SOLAR install UDS$$SRC*UREP$ELMSABS Exec UDS security utility or SOLAR install No n/a After install* No n/a After install* No n/a After install* UDS$$SRC*SECURE-UREP Exec UREP install No n/a After install# UDS$$SRC*UREP$DUMPn Exec UREP dump No n/a No SFS Files See for explanation of symbols. Table 2 7. Default SFS Application Group Files File Type Cataloged By/ When Updated Audit Status Saved SYS$LIB$*SFSLIB Exec UDS security utility or SOLAR install No n/a After install* Storage Areas and User Files See for explanation of symbols. Table 2 8. Default Application Group Files File Type Cataloged By / When Updated Audit Status Saved RDMS Applications: Storage Areas TIP/Exec User before use Yes Optional Periodic+ DMS Applications: Schema file TIP/Exec User before use Yes n/a Periodic#

100 Summary of Files and Characteristics DMS Applications: Areas TIP/Exec User before use Yes Optional Periodic+ SFS Applications: User files TIP/Exec User before use Yes Optional Periodic Summary of Product System Files Numbers in parentheses refer to the numbered notes in Also see that subsection for explanation of symbols. Table 2 9. Summary of Product System Files Product System Files Audited Dump Processor IRU UDSSRC*IRU$DH (1) UDSSRC*IRU$MH UDSSRC*IRU$KF No No No n/a n/a n/a TIP/FURPUR/FAS TIP/FURPUR/FAS TIP/FURPUR/FAS UDS Control UDS$$SRC*ADT-FILE (2) UDS$$SRC*SYS-FILE UDS$$SRC*SECURE-FILE UDS$$SRC*INTERFACESEC UDS$$SRC*RUBSECURITY n/a No No No No n/a n/a n/a n/a n/a FURPUR/FAS (3) FURPUR/FAS/TIP (4) FURPUR/FAS FURPUR/FAS FURPUR/FAS RDMS (5) UDS$$SRC*AUTH$FILE UDS$$SRC*STATS$FILE UDS$$SRC*VIEWDEP$FILE UDS$$SRC*DEP$FILE UDS$$SRC*FRDT$FILE (10) UDS$$SRC*LOB$SA$FILE UDS$$SRC*NULL$FILE UDS$$SRC*PARAMS$FILE UDS$$SRC*PART$FILE UDS$$SRC*RDM$DROPFILE UDS$$SRC*ROUTINE$FILE UDS$$SRC*SCH$FILE UDS$$SRC*TRIG$FILE UDS$$SRC*TRIGCOL$FILE UDS$$SRC*RDT$FILE (5, 10) UDS$$SRC*ECM$FILE (10) UDS$$SRC*EEAM$FILE (10) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP DMS (6) UDS$$SRC*DDL$SCH UDS$$SRC*DDL$SUB UDS$$SRC*DDL$SCR UDS$$SRC*DDL$QLP UDS$$SRC*DDL$SREC UDS$$SRC*DDL$SSREC UDS$$SRC*SYS-CHG-FILE No No No No No No No Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP

101 Summary of Files and Characteristics Table 2 9. Summary of Product System Files Product System Files Audited Dump Processor UREP (7) UDS$$SRC*DDL$ (8) UDS$$SRC*UREP$BDI UDS$$SRC*FDT$ (10) UDS$$SRC*UREP$ME$NAME UDS$$SRC*UREP$A$TYPES UDS$$SRC*UREP$E$TYPES UDS$$SRC*UREP$R$TYPES UDS$$SRC*UREP$ME UDS$$SRC*UREP$ME$ID UDS$$SRC*UREP$QEN UDS$$SRC*UREP$ENTNAME UDS$$SRC*UREP$NAME$ID UDS$$SRC*UREP$ENT UDS$$SRC*UREP$ENT$ORD UDS$$SRC*UREP$RELA UDS$$SRC*UREP$REL$ORD UDS$$SRC*UREP$EA UDS$$SRC*UREP$EA$QEN UDS$$SRC*UREP$EA$DESC UDS$$SRC*UREP$RA UDS$$SRC*UREP$RA$QEN UDS$$SRC*UREP$RA$DESC UDS$$SRC*UREP$ACL UDS$$SRC*SECURE-UREP No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No n/a n/a Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static Dynamic/static n/a FURPUR/FAS/TIP (9) FURPUR/FAS IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP IRU DUMP FURPUR/FAS Processor Files In Table 2 10, numbers in parentheses refer to the following notes: (1) These files are created by DDFCONFIG and used by DDFINIT. They are usually deleted after use. (2) UREP also accesses these files when creating FDTs. (3) These files are required only if the UREP interface is used (a run-id is used). (4) These files are required if DMU is used to access the meta-database files

102 Summary of Files and Characteristics Table Default Application Group Files for Processors Processor Files Required IRU SUDS TRCCTL DUMPER UDSSRC*IRU$DH UDSSRC*IRU$MH UDSSRC*IRU$KF UDS$$SRC*ABS$ UDS$$SRC*ADT-FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*ABS$ UDS$$SRC*ADT-FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UTIL$ UDSSRC*DUMPn UDSSCR*DUMPnPnn UDS$$SRC*DMS$UTIL SYS$LIB$*RDMS UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*TRACEFILE (UDS Control utility file) (User dump file) (User dump file if a multiple-file dump) (If DMS is installed) (If RDMS is installed) DD DDFCONFIG DDFINIT UDS$$SRC*DDL$ UDS$$SRC*SYS-FILE UDS$$SRC*ADT-FILE UDS$$SRC*FDT$ SYS$LIB$*UREP UDS$$SRC*DMRMT$ UDS$$SRC*ABS$ UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*ABSLIB$ UDS$$SRC*DMSLIB$ UDS$$SRC*RDT$FILE user-qualifier*ddf$tables user-qualifier*ddf$add* UDS$$SRC*UREP$ME$NAME UDS$$SRC*UREP$A$TYPES UDS$$SRC*UREP$E$TYPES UDS$$SRC*UREP$R$TYPES UDS$$SRC*UREP$ME (1) UDS$$SRC*UREP$ME$ID UDS$$SRC*UREP$QEN UDS$$SRC*UREP$ENTNAME UDS$$SRC*UREP$NAME$ID UDS$$SRC*UREP$ENT UDS$$SRC*UREP$ENT$ORD UDS$$SRC*UREP$RELA UDS$$SRC*UREP$REL$ORD UDS$$SRC*UREP$EA UDS$$SRC*UREP$EA$QEN UDS$$SRC*UREP$EA$DESC UDS$$SRC*UREP$RA UDS$$SRC*UREP$RA$QEN UDS$$SRC*UREP$RA$DESC UDS$$SRC*UREP$ACL UDS$$SRC*UREP$ABSLIB UDS$$SRC*UREP$ABSD UDS$$SRC*UREP$ELMSABS UDS$$SRC*SECURE-UREP UDS$$SRC*FRDT$FILE UDS$$SRC*LOB$SA$FILE UDS$$SRC*PART$FILE DDL SDDL SRT UDS$$SRC*DMRMT$ UDS$$SRC*DDL$SCR UDS$$SRC*DDL$SCH UDS$$SRC*DDL$SUB UDS$$SRC*DDL$QLP UDS$$SRC*DDL$SREC UDS$$SRC*DDL$SSREC UDS$$SRC*DDL$ UDS$$SRC*FDT$ UDS$$SRC*SYS-FILE (2) (2) (2) (2) (2) (2) (2) UDS$$SRC*ADT-FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*ABSLIB$ UDS$$SRC*DMSLIB$ UDS$$SRC*ABS$ User schema and subschema files

103 Summary of Files and Characteristics Table Default Application Group Files for Processors Processor Files Required ADMLP FDMLP UDS$$SRC*DMRMT$ User schema and subschema files UDS$$SRC*ABS$ UDS$$SRC*DDL$ UDS$$SRC*FDT$ UDS$$SRC*SYS-FILE UDS$$SRC*ADT-FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF (3) (3) (3) (3) (3) (3) (3) UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*ABSLIB$ UDS$$SRC*DMSLIB$ UDS$$SRC*UREP$ME$NAME UDS$$SRC*UREP$A$TYPES UDS$$SRC*UREP$E$TYPES UDS$$SRC*UREP$R$TYPES UDS$$SRC*UREP$ME UDS$$SRC*UREP$ME$ID UDS$$SRC*UREP$QEN UDS$$SRC*UREP$ENTNAME UDS$$SRC*UREP$NAME$ID UDS$$SRC*UREP$ENT UDS$$SRC*UREP$ENT$ORD (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) ADMLP FDMLP (cont.) UDS$$SRC*UREP$RELA UDS$$SRC*UREP$REL$ORD UDS$$SRC*UREP$EA UDS$$SRC*UREP$EA$QEN UDS$$SRC*UREP$EA$DESC UDS$$SRC*UREP$RA (3) (3) (3) (3) (3) (3) UDS$$SRC*UREP$RA$QEN UDS$$SRC*UREP$RA$DESC UDS$$SRC*UREP$ACL UDS$$SRC*UREP$ABSLIB UDS$$SRC*UREP$ABSD UDS$$SRC*UREP$ELMSABS (3) (3) (3) (3) (3) (3) DMU UDS$$SRC*FDT$ UDS$$SRC*SYS-FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*ABSADT$ UDS$$SRC*ABSLIB$ UDS$$SRC*DMSLIB$ UDS$$SRC*ADT-FILE UDS$$SRC*DMRMT$ UDS$$SRC*ABS$ User schema and subschema files UDS$$SRC*DDL$ UDS$$SRC*DDL$QLP UDS$$SRC*DDL$SCH UDS$$SRC*DDL$SCR UDS$$SRC*DDL$SREC UDS$$SRC*DDL$SSREC UDS$$SRC*DDL$SUB (4) (4) (4) (4) (4) (4) (4) (4) DRU UDS$$SRC*DMRMT$ and user area files

104 Preparing a Dump Plan Table Default Application Group Files for Processors Processor RDMSLOAD, RDMUTL SYS$LIB$*RDMS SYS$LIB$*RDMSLIB SYS$LIB$*RDMS$CFGSCOD SYS$LIB$*RDMS$CFGSDEF UDS$$SRC*RDT$FILE UDS$$SRC*AUTH$FILE UDS$$SRC*FDT$ UDS$$SRC*ADT-FILE UDS$$SRC*SYS-FILE UDS$$SRC*ABS$ UDS$$SRC*ABSADT$ UDS$$SRC*ABSLIB$ UDS$$SRC*STATS$FILE UDS$$SRC*VIEWDEP$FILE UDS$$SRC*DEPFILE UDS$$SRC*ECM$FILE Files Required UDS$$SRC*EEAM$FILE UDS$$SRC*NULL$FILE UDS$$SRC*PARAMS$FILE UDS$$SRC*ROUTINE$FILE UDS$$SRC*SCH$FILE UDS$$SRC*TRIG$FILE UDS$$SRC*TRIGCOL$FILE UDS$$SRC*UDSC$PFGSDEF UDS$$SRC*UDSC$PFGSCOD UDS$$SRC*UDSC$CFGSDEF UDS$$SRC*UDSC$CFGSCOD UDS$$SRC*FRDT$FILE UDS$$SRC*LOB$SA$FILE UDS$$SRC*PART$FILE UDS$$SRC*RDM$DROPFILE 2.8. Preparing a Dump Plan Since each application group in UDS operates as a separate system, you must prepare a dump plan for each application group, and test it, before you encounter hardware or software errors. When writing a dump plan, consider the following suggestions: Include each user database and system file in the plan. Record each dump as soon as it is produced. You can maintain this list manually or you can use the IRU dump history file. The list must contain an accurate account of the dumps produced for specific files. Manage related files as a group; you must dump and restore them together. You can use the GROUP feature in IRU to create lists of related files to be manipulated as a set. Determine the procedure for restoring any file or group of related files. The plan must clearly indicate, for example, whether you must reload the dump into a retention file, or use the audit file to recover the data. Include your operations staff in planning and implementation of the procedure. Determine how much protection your database requires. You need more protection for files that are critical to your application group, difficult to reestablish, or required to be restored quickly

105 Preparing a Dump Plan Recovery Types and Procedures UDS offers two basic types of file recovery: The first uses information stored in retention files; the second uses information stored on the audit trail. Updates are kept separate from the database itself in both the retention file and audit trail, enabling you to recover data after user errors or system failure. You can also use the IRU recovery procedures: short recovery, medium recovery, selective recovery, and long recovery. Short recovery is based on retention files, and long recovery is based on the audit trail. For more information about IRU recovery procedures, see the Integrated Recovery Utility Operations Guide. You must specify the type of recovery you want when configuring the system, when defining the UREP storage area attributes for each data file, and when developing programming guidelines and procedures. The methods for defining recovery depend on the type of database (RDMS, DMS, or SFS) you are using. Generally, the RDMS, DMS, and SFS data models support the same UDS recovery types and IRU recovery procedures to ensure data integrity. However, the method you use to define recovery depends on the data model used. In addition, an important consideration for all types of databases in any dump plan is whether the file is audited or not. You can recover an audited file through IRU from the last dump tape up to the point of failure. However, a file that has not been audited can be returned only to its state at the time of the last dump. For an RDMS database file, you specify the recovery type by defining recovery-related UREP storage area attributes (such as RECOVERED and AUDITED) and by including recovery-related SQL thread control statements in your program. For more information about including storage area attributes, see the Repository for ClearPath OS 2200 Administration Guide. For more information about how to specify SQL thread control statements, see the Relational Database Server for ClearPath OS 2200 SQL Programming Reference Manual. After altering an RDMS table definition (for example, ALTER TABLE, CREATE INDEX, DROP INDEX), you must dump the RDMS and UREP system files and all storage areas for the table. Doing so allows you to recover to the point of the dump. You cannot recover the storage areas to a point before you altered the table definition without also recovering the RDMS and UREP system files to that point. For a DMS database file, you specify values for the UREP storage area attributes RECOVERED and AUDITED, and define recovery-related schema clauses of the DMS Data Definition Language (DDL). You also need to determine the data manipulation language (DML) clauses the programmer must specify in the DML program (such as the SAVE DATA clause). For more information about how to ensure the integrity of DMS databases, see the Network Database Server for ClearPath OS 2200 Administration and Support Guide. For an SFS database, you specify values for the UREP storage area attributes RECOVERED and AUDITED. To use deferred updates, you indicate deferred updates on the BEGIN THREAD command. You cannot use before-looks with SFS, however

106 Preparing a Dump Plan Creating and Maintaining Dump Tapes You can make backup copies of database files in several ways. You can use the IRU, FURPUR, or FAS utilities to dump files to tape. Use the same processor to restore the files back to mass storage. You must keep the dump tapes as long as you keep the associated audit trail. The length of time you must keep dump tapes and audit trail tapes depends on How much time it takes you to recover by using old dump tapes How many tapes are available for dump tapes How much space your site has available to store dump tapes Based on database size, activity, and importance, determine a practical time limit for recovering a database. If you are not sure, use three or four days as a guideline. Also include a process to check the database, on a regular basis, to ensure that the dumps are copying valid data. If you know that the new dump contains valid data, you can discard the previous database dump. Highly volatile databases, particularly those that must be audited, require special planning for recovery. Volatile databases must be dumped as frequently as is practical. Store the dump tapes in a safe environment and secure them from unauthorized use. The time it takes to recover the database depends on the frequency of dumping. Each site must balance between the average number of audit trail tapes or files generated since the last dump and the frequency of the dumps. The more frequent the database dumps, the less audit trail information is generated between dumps. With less audit information to process, recovery is quicker. The less frequent the dumps, the more audit trail information is generated between dumps. With more audit information to process, database recovery is more time-consuming. You can configure the six DMS meta-database files for auditing. If these files need to be audited, include them in your recovery plan also. If you have hardware or software problems, ensure that the UDS Control, repository, and user database files are recovered at the same time so that they remain consistent. If you lose one or more of these files, or if an internal file gets corrupted, you cannot access the database

107 Section 3 Monitoring UDS During Normal Operations 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 Check UDS files periodically by combining commands in a user runstream

108 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 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 APP 3 status usage steps recovery mcbstatus datetime where: status is the state of the application group, as follows: UP DN RCV NOT CONFIGURED The application group is up (enabled). The application group is down (disabled). Recovery is in progress for the application group. 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 IRU:status

109 Monitoring UDS During Normal Operations where status has one of the following values: PND INP IRU execution is pending. 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 SUTIL REBLD PANIC Blank The application group was initialized. Exec and IRU used information from the older half of the periodic savefile and audit trail to recover the application group. Exec used information from the periodic savefile and the audit trail to recover the application group. Exec used information from the panic dump to recover the application group. 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 UP AIP Absent MCB is down (disabled). MCB is up. MCB has an abort in progress. 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 hhmmss is year, month, and day. 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: APP n NOT CONFIGURED - AP KEYIN IGNORED

110 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 Exec Operations Reference Manual

111 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 ClearPath OS 2200 Programming Reference Manual

112 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 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 :57 AT 3 L2 FIX(29,92) 38% PL:A2 1920:02 AT 3 L2 BLK 844 TBSN :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 L2 BLK FIX TBSN is the leg-id for leg 1 of a duplex audit trail. is the leg-id for leg 2 of a duplex audit trail. is the file block number. means fixed mass storage media. 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

113 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 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 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. END UREP ( 0 ) FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 0 )REMARKS

114 Monitoring UDS During Normal Operations 3.5. Monitoring Status of Active Threads To observe UDS thread activity, execute the UDS supervisor program 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, INPUT APPLICATION NAME (6 CHARS) udssrc INPUT FUNCTION rc ORG-ID/GEN-ID TIME SEQUENCE UPDATES LOCKS UDSMSG STATUS 5JLS /5JLS SOS DONE 5KMG /5KMGA INITIALIZE 5BCM /5BCM 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

115 Monitoring UDS During Normal Operations 3.6. Verifying Creation of New Cycle of Application Group Dump File To verify the creation of a new cycle of the dump file for the application group, enter the first udssrc*dump0. * * PROJ: //////////// ACCNT: //////////// * * UDSSRC*DUMP0(3),F/1946/TRK/ MODES: PUBLIC OWNER: SUBSYS NO. OF GRANULES ASG-D: 1946 GP2=1946 HIGHEST GRANULE ASG-D: 1945 TOTAL ASSIGNMENTS: 3 HIGHEST TRACK WRITTEN: 1945 CAT: mm/dd/yy AT hh:mm:ss, LAST REF: mm/dd/yy AT hh:mm:ss Enter the next udssrc*dump0. MAX-RANGE= 32 CUR-RANGE= 2 NO. OF F CYCLES= 1 3, *2, *1 These commands alert you to possible abnormal conditions existing in UDS. UDS provides a general dump facility that is automatically initiated as the result of a contingency or internal error within either UDS Control or one of its logical data manager (LDM) products. The dump file cataloged by the dump facility has a file name of DUMP0 to DUMP9, with the name of the application group in which the dump occurred as the file qualifier. Any new F-cycle appearing in the output warrants further investigation. The dump consists of multiple dump files if the dumped D-banks were not placed into one dump file. Use the dump functions supplied in the utility file of the UDS Control release tape. See Section 4 for more information on processing dumps. The maximum F-cycle range is 32, but for this dump file, it is 2. This means that only the last two copies of this dump file are retained. F-cycle 3 is the only F-cycle available. F-cycles 2 and 1 were deleted, as denoted by the asterisk. Your site might be using the REFRESH runstream to recover an application group after an application group aborts and a dump is initiated. A refresh flag is set in file ADT-FILE whenever UDS aborts. The next access to the application group causes the REFRESH runstream to be executed. You might not be aware that an abort has taken place if you monitor application group activity after the REFRESH runstream has recovered the application group. For more information about the REFRESH runstream, see the Universal Data System Configuration Guide

116 Monitoring UDS During Normal Operations An application group dump to the dump file, however, can be triggered without aborting the application group. Therefore, not all F-cycles appearing in the dump file are created by an abort of the application group. The SUDS program contains a DP command, which dumps all UDS Control D-banks to the application group dump file while the application group is operating normally Listing BDIs and Bank Attributes You can use the SOLAR common bank definition (CBD) processor or the SOLAR online reports to ascertain which BDIs are associated with the UDS AFCB product files installed by SOLAR as well as the bank attributes associated with each print$ The following example is a partial listing of the output from the CBD processor with a view of the FILE-BDI$ scratch. ED 16R1E FRI-04/01/02-15:00:47-(0,) l p 1 DEFINE FILE UDS$$SRC*ABS$. WITH BDIS ; exit END ED. NO CORRECTIONS APPLIED You can also view the BANK-BDI$ element for a look at bank attributes. For more information about the CBD processor and the SOLAR online reports, see the SOLAR End Use Reference Manual. You can use an editor to view the CO$INSTALL$/COMUS$ element. The following example shows the part of this element that lists BDI and system registration information about products installed on the system by sys$*data$.co$install$/comus$ FILE IN FIELD 1 IN USE BY ANOTHER RUN READ-ONLY MODE ED 16R1E FRI-04/01/02-15:00:47-(0,) l FILE,UDS$$SRC*UTIL$ -4 p

117 Monitoring UDS During Normal Operations INSTALL ; PRODUCT,UDSC, 12R2; MODE,AP3,DEFAULT ; TIME, , FILE,UDS$$SRC*UTIL$(20),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*ABS$(21),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*UDSC$PFGSDEF(1),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*UDSC$PFGSCOD(1),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*UDSC$CFGSDEF(1),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*UDSC$CFGSCOD(1),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE ; FILE,UDS$$SRC*ABSLIB$(9),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE; FILE,UDS$$SRC*ABSADT$(7),9999,PACK,NOPREP,NOROLLOUT,NOTWRITEABLE; l REGISTER p 2 REGISTER,REG_CBD,'''','''','''' ; $FIN 1 l FILE,UDS$$SRC*D$MR -4 p 8 INSTALL ; PRODUCT,DMS,18R1 ; MODE,A,DEFAULT ; TIME, , ; FILE,UDS$$SRC*D$MR(24),9999,PACK,PREP,NOROLLOUT,NOTWRITEABLE; FILE,UDS$$SRC*DMRMT$(23),9999,PACK,PREP,NOROLLOUT,NOTWRITEABLE; FILE,UDS$$SRC*DMSLIB$(9),9999,PACK,PREP,NOROLLOUT,NOTWRITEABLE; FILE,UDS$$SRC*DMS$UTIL(23),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE; l REGISTER p 2 REGISTER,REG_CBD,REG_LIBD,REG_COLLECTOR,'''' ; $FIN exit END ED. NO CORRECTIONS APPLIED Each product installed on the system through SOLAR appears as a stream generation statement (SGS) with INSTALL as the label. The REGISTER subfield of each INSTALL SGS indicates whether the product is registered with the Exec, the Collector, or both. For a list of BDIs for UDS products installed into application group 3, see the Universal Data System Configuration Guide

118 Monitoring UDS During Normal Operations 3.8. Displaying Status of UDS Files with FDTs To report the status of UDS files with file descriptor tables (FDTs), enter these list status file uds$$src*fdt$; act appl udssrc; end; IRU displays a message similar to the following: File UDS$$SRC*FDT$ UP The IRU LIST command can display the status of all UDS files that have FDTs entered in FDT$. It can also display the status of FDT$ itself (FDT$, however, contains no FDT for FDT$). UDS$$SRC*ADT-FILE and the system file for application group 3, UDS$$SRC*SYS-FILE, do not have FDTs in FDT$ and their status cannot be displayed with the LIST command. If a file was placed in a DOWN state with the IRU DOWN command, the LIST command indicates the DOWN status. If a file was placed in a DOWN FROM UPDATE state with the IRU DOWN command, the LIST command shows READ-ONLY as the status of the file. Although the retention files do not have an FDT entry, they can be listed by the IRU. The internal retention file list entry format is translated into an FDT and displayed as if it were a normal file. The down segments are translated into down page ranges. You can also use the LIST command to obtain information about files under TIP control (for example, a TIP periodic savefile). The output received from the LIST command when used with files under TIP control can be quite different from that which is received when used with files under UDS control. For more information about the IRU LIST command, see the Integrated Recovery Utility Operations Guide Reporting IRU History File Information You can use the IRU REPORT command to report IRU dump history file information on backup dumps in the form of either a file or tape dump report. The IRU REPORT command presents information maintained in the IRU dump history file that is accessed during a database recovery process. You can use the IRU REPORT AUDIT command to get information from the IRU move history file on archived mass storage audit trails. With the IRU REPORT ACI command you can see audit trail information from the Exec ACI file. For instructions on how to use the IRU REPORT command, see the Integrated Recovery Utility Operations Guide

119 Monitoring UDS During Normal Operations Determining File Security Status If TeamQuest Site Management Complex (SIMAN) is installed on your system, you can use its full-screen interface menus to determine the file security status of any UDS file. After calling the TeamQuest SIMAN processor, follow the menu dialogue for "Cataloged File Security" to display the security of a file related to UDS. As an alternative to the full-screen interface, you can use the batch, command-driven interface for determining file security. The batch interface is useful in a batch runstream in which you are making requests for all files related to UDS. To call the batch interface, use the B option on the TeamQuest SIMAN processor call, as in the following display In the preceding example, TeamQuest SIMAN reports security information for the file, such as who owns the file, the security clearance level (and associated clearance name, if defined), and any actions to be taken on file access. When displaying the security information for a mass storage audit trail file such as SYS$*AT$3L1, TeamQuest SIMAN reports that the Exec cataloged the file with the maximum security clearance level of 63 (clearance level numbers range from 0 to 63). Users with a clearance level number less than 63 are denied all access to this file. The file used in the preceding example is an audit trail file that typical UDS users never access. The Exec and IRU access this file. Users executing IRU must therefore have a run-id with clearance level 63 if they issue a command that accesses this audit trail (for example, the IRU SHORT RECOVER command). UDS Control is a protected subsystem. This means that when UDS Control assigns a file, the security attributes of the protected subsystem determine whether or not the file can be assigned. In short, the UDS subsystem must be able to assign files. For more information about security considerations, see Section 9 in this manual and the Security Administration for ClearPath OS 2200 Help

120 Monitoring UDS During Normal Operations Using a Runstream to Check UDS Files Periodically You can create your own runstream to monitor your UDS environment. The runstream can include any files used or accessed by a UDS application group. You can use a runstream similar to CHECK*UDS.ENVIRONMENT (not included on any UDS product release tape) used in the example in this subsection to monitor the entire UDS environment in an application group. This example, based on application group 3, contains commands you can include in your runstream. You must include other application groups in your runstream and add your list of database files to the set of recoverable system files. For application groups other than 3, adjust the qualifiers; the file names are the same. Also, you must change the name of the UREP product file from UREP to UREP$ABS and the name of the UREP utility file from UTILITY to UREP$UTIL. Frequent execution of the runstream provides an updated reference point for UDS environment files. If an abnormal situation arises in the UDS environment, reexecuting the runstream and comparing the results to the most recent reference point helps you to resolve the check*uds. check*uds.environment Checking files of a UDS FAS must be installed for the FAS examples to work. In addition, runstream must have the This example checks the availability of the application group periodic savefile and mass storage audit trail The file names are in the Exec configuration for group 3 and any of the other application groups you may configured in The file name for the audit control interface (ACI) file is listed here. The Exec catalogs it with the qualifier and a file name of ACI$nn, where nn is the application May not be configured

121 Monitoring UDS During Normal Operations Note: If you define a GROUP for UDS system files, you can replace the list of file names in the LIST command with the following command: LIST GROUP uds-system, FILE Next, the IRU call lists the status of the periodic This example assumes the savefile is a duplex TIP with a TIP file code LIST STATUS TIP FILE 300; ACT APPL If SIMAN is installed, you can list the security status of files. Since the the Exec catalogs the the Exec owns the files and their security clearance level TEMP.TEMP DISPLAY FILE=TIP$*AP3$SVFILEL1.; DISPLAY FILE=TIP$*AP3$SVFILEL2.; DISPLAY FILE=SYS$*AT$3L1.; DISPLAY FILE=SYS$*AT$3L2.; @. UDSC Files : Check the existence of files associated UDS$$SRC*ADT-FILE.. Qual UDS$$SRC for all UDS$$SRC*ABSADT$.. Qual UDS$$SRC for UDS$$SRC*ROLLBACK

122 Monitoring UDS During UREP Files : Check the files associated UDS$$SRC*UREP$BDI.. This file is for UDS$$SRC*SECURE-UREP. DMS Files : Check the files associated @. RDMS Files : Check the files associated SYS$LIB$*RDMSLIB

123 Monitoring UDS During Normal @. SFS FILES : Check the files associated @. The following files are recoverable files and are thus with UDSC and have FDT entries generated. The following checks availability through LIST STATUS FILE UDS$$SRC*FDT$, DDL$, UREP$ME$NAME, UREP$A$TYPES, UREP$E$TYPES, UREP$R$TYPES, UREP$ME, UREP$ME$ID, UREP$QEN, UREP$ENTNAME, UREP$NAME$ID, UREP$ENT, UREP$ENT$ORD, UREP$RELA, UREP$REL$ORD, UREP$EA, UREP$EA$QEN, UREP$EA$DESC, UREP$RA, UREP$RA$QEN, UREP$RA$DESC, UREP$ACL, DDL$SCH,

124 Monitoring UDS During Normal Operations DDL$SCR, DDL$SUB, DDL$QLP, DDL$SREC, DDL$SSREC, SYS-CHG-FILE, RDT$FILE, DEP$FILE, ECM$FILE, EEAM$FILE, FRDT$FILE, LOB$SA$FILE, NULL$FILE, PARAMS$FILE, PART$FILE, RDM$DROPFILE, ROUTINE$FILE, SCH$FILE, TRIG$FILE, TRIGCOL$FILE, AUTH$FILE, STATS$FILE, VIEWDEP$FILE; ACT APPL Assuming FAS is installed, here is additional information the backups for files associated non-recoverable UDS files, which means the system does recover them; therefore, your site may want to FAS for recovering the files, as shown in ROLLBACK is not in following non-recoverable file list. If these files are available (or are lost), you can recatalog them to particular size or let the system do it during system You do not have to back up @FAS,EF LIST CRITERIA=[FILE='SYS$LIB$*IRU', 'UDS$$SRC*ADT-FILE', 'UDS$$SRC*ABSADT$', 'UDS$$SRC*UREP$BDI', 'UDSSRC*IRU$DH', 'UDSSRC*IRU$MH' 'UDS$$SRC*ABS$', 'UDS$$SRC*ABSLIB$', 'UDS$$SRC*UDSC$PFGSDEF', 'UDS$$SRC*UDSC$PFGSCOD', 'UDS$$SRC*UDSC$CFGSDEF', 'UDS$$SRC*UDSC$CFGSCOD', 'UDS$$SRC*UTIL$',

125 Monitoring UDS During Normal Operations 'UDS$$SRC*SYS-FILE', 'SYS$LIB$*UREP', 'UREP*UTILITY', 'UDS$$SRC*UREP$ABSLIB', 'UDS$$SRC*UREP$ABSD', 'UDS$$SRC*UREP$ELMSABS', 'UDS$$SRC*SECURE-UREP', 'UDS$$SRC*DMRMT$' 'UDS$$SRC*DMSLIB$', 'UDS$$SRC*DMS$UTIL', 'UDS$$SRC*D$MR', 'SYS$LIB$*RDMS', 'SYS$LIB$*RDMS$CFGSCOD', 'SYS$LIB$*RDMS$CFGSDEF', 'SYS$LIB$*RDMSLIB', 'SYS$LIB$*RSA', 'SYS$LIB$*SFSLIB']; @. If SIMAN is installed, you can check the security of key system data files. These files and all other files must be cataloged with a security clearance level that all users to DISPLAY FILE=UDSSRC*IRU$DH., UDSSRC*IRU$MH., UDSSRC*IRU$KF., UDS$$SRC*ADT-FILE., UDS$$SRC*SYS-FILE., UDS$$SRC*ROLLBACK0001., UDS$$SRC*ROLLBACK0002., UDS$$SRC*ROLLBACK0003., UDS$$SRC*ROLLBACK0004., UDS$$SRC*ROLLBACK0005., UDS$$SRC*ROLLBACK0006., UDS$$SRC*ROLLBACK0007., UDS$$SRC*ROLLBACK0008., UDS$$SRC*ROLLBACK0009., UDS$$SRC*ROLLBACK0010., UDS$$SRC*DDL$., UDS$$SRC*DDL$SCH., UDS$$SRC*DDL$SCR., UDS$$SRC*DDL$SUB., UDS$$SRC*DDL$QLP., UDS$$SRC*DDL$SREC., UDS$$SRC*DDL$SSREC., UDS$$SRC*SYS-CHG-FILE.,

126 Monitoring UDS During Normal Operations UDS$$SRC*FDT$., UDS$$SRC*RDT$FILE., UDS$$SRC*DEP$FILE., UDS$$SRC*ECM$FILE., UDS$$SRC*EEAM$FILE., USD$$SRC*FRDT$FILE., UDS$$SRC*LOB$SA$FILE., UDS$$SRC*NULL$FILE., UDS$$SRC*PARAMS$FILE., UDS$$SRC*PART$FILE., UDS$$SRC*RDM$DROPFILE., UDS$$SRC*ROUTINE$FILE., UDS$$SRC*SCH$FILE., UDS$$SRC*TRIG$FILE., UDS$$SRC*TRIGCOL$FILE., UDS$$SRC*AUTH$FILE., UDS$$SRC*STATS$FILE., UDS$$SRC*VIEWDEP$FILE., UDS$$SRC*UREP$ME$NAME., UDS$$SRC*UREP$A$TYPES., UDS$$SRC*UREP$E$TYPES., UDS$$SRC*UREP$R$TYPES., UDS$$SRC*UREP$ME., UDS$$SRC*UREP$ME$ID., UDS$$SRC*UREP$QEN., UDS$$SRC*UREP$ENTNAME., UDS$$SRC*UREP$NAME$ID., UDS$$SRC*UREP$ENT., UDS$$SRC*UREP$ENT$ORD., UDS$$SRC*UREP$RELA., UDS$$SRC*UREP$REL$ORD., UDS$$SRC*UREP$EA., UDS$$SRC*UREP$EA$QEN., UDS$$SRC*UREP$EA$DESC., UDS$$SRC*UREP$RA., UDS$$SRC*UREP$RA$QEN., End You may now run this example @

127 Section 4 Processing UDS Dumps UDS provides a general dump facility that automatically initiates a dump of the UDS banks whenever an error results in a serious contingency, or whenever certain errors are detected by the code within UDS Control or one of the logical data managers RDMS, DMS, or SFS. This dump facility initiates dumps on an application group basis. In addition to the application group error conditions, problems may also occur in the ADT code, which is on a system basis. An automatic mechanism to dump the ADT bank does not exist, but a utility is provided that has the ability to dump the ADT bank. This section explains these two dumping facilities Application Group Dump Initiation Whenever UDS Control initiates a dump, the dump facility catalogs a file to contain the dump. This UDS dump lets you review the contents of main storage. Dumps are useful for determining why a problem occurred, as well as in deciding how to fix it. You can format and print a dump using the dump functions supplied in the utility file of the UDS Control release tape, provided the Dump Analysis Procedure (DAP) is installed on your system. A nonfatal error condition can be set dynamically to trigger a dump. You set the error condition using the UDS supervisor program (SUDS) add error (AE) command. The AE command is defined in When a nonfatal error occurs to an executing thread, the dump is produced and control returns to the interrupted thread to continue processing. UDS Control initiates an internal dump whenever a contingency, internal error, SUDS Add Error (AE) condition, SUDS dump (DP) command, or SUDS II command is detected. For information on how to control SUDS AE and II dumping, see Section 8. At the time of the dump, the UDS Control contingency handler initiates a dump and displays the following message: UDS DUMP TAKEN yy/mm/dd hh:mm:ss qual*dumpn(cycle)[-dumpnpmm(cyclem)] where: yy/mm/dd hh:mm:ss is the date and time of the dump. qual*dumpn is the fully qualified name of the main dump file

128 Processing UDS Dumps cycle is the file cycle number. DUMPnPmm(cyclem) is the last file of the dump and is only present when a large UDS configuration requires more than one file for a dump. Here mm is a two-digit integer (for example, 01). cyclem is the file cycle number of the last dump file in the dump. The dump file name for the main dump file is application-group-name*dumpn(cycle) where n is a number from 0 to 9 and cycle is the file cycle number. Ten unique default dump file names are available. Whenever a dump is required, the dump routine starts with n equal to zero, and attempts to catalog the next file cycle. If the catalog request fails (for example, because of a security error), n increases by one and an attempt is made to catalog the next cycle of the new file. This procedure is repeated until a dump file is successfully cataloged, or until all 10 dump file names are used. If the dump requires more than one file application-group-name*dumpn(cycle) is the first (main) dump file application-group-name*dumpnpmm(cyclem) is the last dump file If there are more than two files, the other files are DUMPnPii, where ii is between 01 and mm. You can determine the names and cycles of the additional dump files by using the diag$. *restore application-qualifier*util$. diag$

129 Processing UDS Dumps 4.2. Processing Dumps After the dump facility produces the dump file, you can use one of two methods to format, print, or display the contents of the dump file. You can process dumps with the DUMPER runstream or use selective dump processing. This subsection describes both methods. Your user-id must have the proper security attributes to process the dump. If Security Option 3 is configured on your system, the security attributes of your user-id must match the security attributes of the UDS secure subsystem that produced the dump. See Section 9 for more information about security. The run used to format the dump need not be the same as the run that produced the dump. Since the dump facility does not delete any dump files, you can format dumps as long as the dump file remains cataloged. It is your responsibility to delete dump files when you no longer need them. The following files must be available to format a dump: UDS Control utility file (default value UDS$$SRC*UTIL$) UDS dump file or files (default value UDSSRC*DUMPn) RDMS absolute file (required if running RDMS; default value SYS$LIB$*RDMS) DMS utility file (required if running DMS; default value UDS$$SRC*DMS$UTIL) UDS utility files contain dump analysis functions developed for the UDS dump facility

130 Processing UDS Dumps Using the DUMPER Runstream Most formatted dumps are produced using the DUMPER runstream because it requires minimal information about the UDS dump file and the dump functions. The DUMPER runstream can format the dump file either as a full dump or as a Remote System Support (RSS) dump. When you choose the RSS dump, UDS Control registers it with the Remote System Support facility. RSS transfers support files between your computer system and the Unisys Support Center. The DUMPER runstream calls the RSS batch processor RSSDIR to process a UDS Control system dump file, creating and registering RSS files for possible transmission to Unisys. These files are the RSS dump file and any raw dump files. The processed dump file contains a subset of information pertaining to the specific error that caused the dump. For information about how to transmit an RSS dump file to Unisys, see the RSS Operations Guide. To begin interactive DUMPER runstream generation, uds$$src*util$.dumper The runstream solicits UDS product names and the associated DAP function file name for each product installed on your system. However, the runstream assumes default file names for all UDS products, which are illustrated in the examples that follow. You must enter DAP function file names only for files you provide as alternates. The runstream produces a print file named UDS$*DUMP(cycle) containing the processed dump information. You can look at this file online or print it. If you select an RSS dump, the runstream also produces RSS registered files containing the processed UDS system dump and the raw dump. In addition to processing dumps, the DUMPER runstream provides these utilities to simplify dump handling, particularly for multifile dumps: List dump files Lists all the dump files in a program file element Delete dump files Deletes all raw dump files related to a dump Copy dump files to tape Copies all raw dump files related to a dump to a tape To use any of these utilities, you supply only the name of the main dump file

131 Processing UDS Dumps Examples The following examples show typical runstream dialogues. No entry means that the default value is used. User input is in bold type. For Example 1 and Example 2, assume that your dump file is in UDSPROD*DUMP0(3). Example 1 The first example shows how to create a dump registered by RSS. The files containing DAP functions for each UDS product are accepted by uds$$src*util$.dumper The smaller RSS-DUMP can be registered and transmitted to a remote software support center (SSC) for analysis. Indicate the dump type or utility desired: 1 - full dump (include page banks) 2 - all threads (formatted and octal) 3 - all threads formatted, erroring thread's dbank 4 - erroring thread only (formatted and octal) 5 - rss (default) 6 - list dump files 7 - delete dump files 8 - copy dump files to tape Enter dump processing number? For multi-part dumps, prefix the file name with "+" to enter more than one file name, for example "+qual*filename(cycle)". (The "+" is not necessary if files have original names and cycles.) Which file { Qual*Filename() } contains your dump? udsprod*dump0(3) Based upon file assigns of the standard release configuration files, the following UDS products are installed: PRODUCT FILE NAMES UDSC UDS$$SRC*UTIL$ RDMS SYS$LIB$*RDMS DMS UDS$$SRC*DMS$UTIL SFS SYS$LIB$*SFSLIB Do you wish to use alternate product files? YES or <NO> Please indicate which UDS product is associated with this dump RDMS, DMS, SFS or <UDSC> END SSG... dump is now being processed

132 Processing UDS Dumps Example 2 The second example illustrates a full dump. Note that the user file UDSPROD*UTIL$, containing dump analysis routines, replaces the standard UDS dump analysis routines for UDS Control. The standard RDMS DAP file is accepted by default, whereas the DMS and SFS DAP files are not assigned because the products are not uds$$src*util$.dumper The smaller RSS-DUMP can be registered and transmitted to a remote software support center (SSC) for analysis. Indicate the dump type or utility desired: 1 - full dump (include page banks) 2 - all threads (formatted and octal) 3 - all threads formatted, erroring thread's dbank 4 - erroring thread only (formatted and octal) 5 - rss (default) 6 - list dump files 7 - delete dump files 8 - copy dump files to tape Enter dump processing number? 1 For multi-part dumps, prefix the file name with "+" to enter more than one file name, for example "+qual*filename(cycle)". (The "+" is not necessary if files have original names and cycles.) Which file { Qual*Filename() } contains your dump? udsprod*dump0(3) Based upon file assigns of the standard release configuration files, the following UDS products are installed: PRODUCT FILE NAMES UDSC UDS$$SRC*UTIL$ RDMS SYS$LIB$*RDMS DMS UDS$$SRC*DMS$UTIL SFS SYS$LIB$*SFSLIB Do you wish to use alternate product files? YES or <NO>... y Source file for UDSC Flit functions <UDS$$SRC*UTIL$>...udsprod*util$ Is RDMS installed at your site? YES or <NO>...y Source file for RDMS Flit functions <SYS$LIB$*RDMS>... Is DMS installed at your site? YES or <NO>... Is SFS installed at your site? YES or <NO>... END SSG... dump is now being processed

133 Processing UDS Dumps Example uds$$src*util$.dumper The smaller RSS-DUMP may be registered and transmitted to a remote software support center (SSC) for analysis. Indicate the dump type or utility desired: 1 - full dump (include page banks) 2 - all threads (formatted and octal) 3 - all threads formatted, erroring threads dbank 4 - erroring thread only (formatted and octal) 5 - rss (default) 6 - list dump files 7 - delete dump files 8 - copy dump files to tape Enter dump processing number? 1 For multi-part dumps, prefix the file name with "+" to enter more than one file name, for example "+qual*filename(cycle)". (The "+" is not necessary if files have original names and cycles.) Which file { Qual*Filename() } contains your dump? appsvn*dump0 Based upon file assigns of the standard release configuration files, the following UDS products are installed: PRODUCT FILE NAMES UDSC UDS$$SRC*UTIL$ RDMS SYS$LIB$*RDMS DMS UDS$$SRC*DMS$UTIL SFS SYS$LIB$*SFSLIB Do you wish to use alternate product files? YES or <NO> y Source file for UDSC Flit functions <UDS$$SRC*UTIL$>... util$ Is RDMS installed at your site? YES or <NO>... Is DMS installed at your site? YES or <NO>... y Source file for DMS Flit functions <UDS$$SRC*DMS$UTIL>. uds$$svn*dms$util Is SFS installed at your site? YES or <NO>... END SSG. ERRORS: 0 WARNING 0 SYNTAX 0 NO-FIND 0 MERGE/CORRECT LINES: 213 INTERPRETED 46 OUTPUT TIME: STORAGE: TEMP. W: file is already DAP 12R2A ( :57) yyyy mmm dd day hhmm:ss Copyright (c) Unisys Corporation. All rights reserved. UNISYS CONFIDENTIAL

134 Processing UDS Dumps INPUT ************************************************************ *** UDS CONTROL DATA BANK DUMP *** *** *** *** DUMP FILE: APPSVN*DUMP0( 64) *** *** APPSVN*DUMP0P01( 8) *** *** TAKEN BY: 5JAFO 5JAFOA *** *** TAKEN ON: mm/dd/yy AT hh:mm:ss *** *** LEVEL ID: UDSC13DEV1-2 *** *** PRINTED ON: mm/dd/yy AT hh:mm:ss *** *** *** *** DUMP REASON: SUDSDP (R2) *** *** SUDS DP request *** ************************************************************ NUMBER OF BANKS (INCLUDES PCT) WAIT- DUMP FORMATTING IN PROGRESS Example 4 For this example, assume appsvn*dump0(64) was previously copied to file dump0. appsvn*dump0p01(8) was previously copied to file uds$$src*util$.dumper The smaller RSS-DUMP may be registered and transmitted to a remote software support center (SSC) for analysis. Indicate the dump type or utility desired: 1 - full dump (include page banks) 2 - all threads (formatted and octal) 3 - all threads formatted, erroring threads dbank 4 - erroring thread only (formatted and octal) 5 - rss (default) 6 - list dump files 7 - delete dump files 8 - copy dump files to tape Enter dump processing number? For multi-part dumps, prefix the file name with "+" to enter more than one file name, for example "+qual*filename(cycle)". (The "+" is not necessary if files have original names and cycles.) Which file { Qual*Filename() } contains your dump? +dump0 Enter the additional dump file parts in order (P01, P02, etc.) Enter a blank file name when you are done. Enter the next file { Qual*Filename() } of the dump dump1 Enter the next file { Qual*Filename() } of the dump

135 Processing UDS Dumps Example 5 This example shows how to use the DUMPER utility to copy a raw UDS dump to uds$$src*util$.dumper SSG 24R1 ( :51) :57 Copyright (c) Unisys Corporation. All rights reserved. UNISYS CONFIDENTIAL skel The smaller RSS-DUMP may be registered and transmitted to a remote software support center (SSC) for analysis. Indicate the dump type or utility desired: 1 - full dump (include page banks) 2 - all threads (formatted and octal) 3 - all threads formatted, erroring threads dbank 4 - erroring thread only (formatted and octal) 5 - rss (default) 6 - list dump files 7 - delete dump files 8 - copy dump files to tape Enter dump processing number? 8 Which file { Qual*Filename() } contains your dump? appsvn*dump0 Copy the dump file(s) to tape. Enter the assign options, equipment type, and reel number. For example: T,HICL,899C Do not use spaces. Enter asg-options,equip-type,reel-number for the tape uds$tape,hicl,15924c Based upon file assigns of the standard release configuration files, the following UDS products are installed: PRODUCT FILE NAMES UDSC UDS$$SRC*UTIL$ RDMS SYS$LIB$*RDMS DMS UDS$$SRC*DMS$UTIL SFS SYS$LIB$*SFSLIB Do you wish to use alternate product files? YES or <NO>? yes Source file for UDSC Flit functions <UDS$$SRC*UTIL$>...? uds$$svn*util$

136 Processing UDS Dumps Selective Dump Processing Selective dump processing requires additional information to generate a formatted dump, but it allows for complete or selective dump processing. The name of the standard main dump file is application-group-name*dumpn(cycle) where n is a number from 0 to 9 and cycle is the file cycle number. Whenever a dump is initiated, it creates a new F-cycle for the dump file. Therefore, you can have more than one dump file on the system. Whenever you perform dump processing, therefore, be sure to note and specify correctly the F-cycle and dump name increment (n) of the dump file. If more than one file is required for a dump, the additional files are named application-group-name*dumpnpmm(cycle) where mm is a two-digit number of the dump file part, starting with 01. Note that the cycle number of these additional dump files may be different from the main dump file. See 4.1 for a runstream that finds the cycle numbers of the additional dump files. Example The following sample dump shows the standard application group. Line numbers in parentheses refer to the explanation that follows the example. udsdump,udssrc*dump0(25). udsfunc,uds$$src*util$. udsprint,userprint. udsprint.,f///10000 udsprint. udsfunc.uds$diag (7) DAP 12R2 (8) INPUT (9) WAIT FOR DAP TO RETURN CONTROL (Dump label displayed)... (10) ENTER YOUR DAP COMMANDS (11)!UDS$DCSD.. (any other routines to process). (12) END DAP udsprint,,pr

137 Processing UDS Dumps Explanation (1), (2), (3) Attaches names of UDSDUMP, UDSFUNC, and UDSPRINT to the dump file, the utility file, and an alternate print file. If there are multiple files associated with the dump, there are two cases: If the dump files have their original qualifiers, names and cycles, you only need command for the main dump file, as in (1). If the qualifiers, names, or cycles are different, you must do command for each file in the dump. command for the main dump file is like (1). Each additional dump file must also have command like the udsdumppmm,dumpfilepartmm where dumpfilepartmm is the name of the dump file that was originally named application-group-name*dumpnpmm(cycle), and mm is 01, 02, 03, and so on. (4), (5) Catalogs and assigns your print file. (6) Adds a runstream that executes DAP, loads the dump functions for DAP, and sets up an alternate file for the print formatted in DAP (UDSPRINT). (8) After this line, a dump header appears on your screen. This dump header shows the dump file name, the run-id initiating the dump, the time the dump was produced, and the level of UDS Control producing the dump. (9), (10) Message lines that appear before and after the dump label. (11) Produces the formatted dump by entering various dump functions. The exclamation point (!) indicates that the formatted dump is produced in an alternate print file (UDSPRINT). To generate a formatted dump and display it on your screen, enter the dump functions without the exclamation points. (13) Sends a paper copy of the formatted dump. This line is not required to generate a formatted dump and display it

138 Processing UDS Dumps 4.3. DAP Functions UDS Control supplies a set of DAP functions adapted specifically for UDS, which you can use to print and analyze all or part of the dump file in various formats. Table 4 1 describes these DAP functions. Table 4 1. DAP Functions Supplied by UDS DAP Function UDS$ALL UDS$DCSD UDS$DPBDI(bdi) UDS$LBL dumpfiles Result Produces a formatted octal dump of all banks in the dump file. Produces a formatted octal dump of the UDS Control D-banks. Produces a formatted octal dump of the bank with the specified bank descriptor index (BDI). Specify the BDI in octal (prefixed with a zero) or decimal. Produces a tabular display that identifies the dump, when it was produced, and so on. UDS$LBL executes automatically whenever you add UDSFUNC.UDS$DIAG. The element contains the addstream that copies the dump file to a temporary file and executes DAP. Produces runstreams for use with multifile dumps. It has one optional parameter, which has the following values: 0 List names of all raw dump files for the dump 1 Generate a runstream to delete all the raw dump files 2 Generate a runstream to copy the raw dump files to the tape file with the name UDS$TAPE For example, the following runstream saves the names of the raw dump files in the temporary SDF file *restore uds$$svn*util$. *alt

139 Processing UDS Dumps 4.4. Dump File Format The dump file is formatted with a header similar to the format of a generic postmortem dump (PMD) DIAG$ file. The rest of the dump file consists of copies of UDS Control structures that define the content of the rest of the file and the actual UDS bank contents. The following figure illustrates the format of the UDS Control postmortem dump file header. The line numbers are explained following the illustration. Main Dump File Header Format 00 PMD$$$ Program file name 03 Mass storage address of absolute element 04 Type Level Version ASA address 05 TDATE 06 Condition word nnn UDS Control structures that define the content of the rest of the file... Content of UDS banks... Line Numbers Word 0 Words 1, 2 Word 3 A Fieldata sentinel verifying that the table is present. UDS-Control sets this word to Fieldata PMD$$$. Internal file name of the program file that contains the absolute element. UDS-Control sets this word to Fieldata CSINTNAME$. Relative sector address of the program header table. UDS-Control sets uses this word to locate the structures in the file that define the format of the rest of the file

140 Processing UDS Dumps Word 4 Word 5 Word 6 Information relating to the last activity to terminate. UDS-Control stores the information about the activity that took the dump. S1 S2 S3 H2 Program type Switching level Version of the PDM header. Version 1 supports multiple dump files. PCT relative address of the last activity to terminate (PCT is the program control table, which contains control information about each active run in the system and any program being executed within the run.) Time and date in TDATE format. Information about the condition of the program when the last activity terminated. UDS-Control actually stores the information about the condition of the program when the dump was executed. T1 S2 S2 If zero, program terminated normally. If set to E, last activity terminated in error. If set to X, last activity aborted. A dump can include the bank types in the following list. Cache banks (dedicated, small, and general page banks) are not in the dump if the application group specifies NO-PAGE-BANKS in a dump. Refer to the Repository for ClearPath OS 2200 Programming Reference Manual for more information about the UREP DUMP-TYPE attribute. Non-application-level D-banks that are not associated with the dumping activity are never dumped. For example, activity-level RDMS scratch banks allocated to a thread that is not dumping are not dumped, because the dumping activity cannot access the non-application-level banks of other activities. In the following list, an asterisk (*) indicates a bank associated with the activity that is dumping: PCT bank* UDS Control D-banks (DCSD and XDCSD) TCS D-banks FPTE banks Thread D-banks Page banks Dedicated page banks Schema D-banks Lock D-banks Contingency bank

141 Processing UDS Dumps Small page D-banks Encryption D-bank UDS Monitor (UMON) caller D-bank* Activity local stack (ALS) bank* RDMS physical file D-banks* RDMS logical file D-banks* RDMS scratch D-banks Note: Some dump types do not dump all bank types Dumping the ADT Bank Whenever an error situation occurs that affects more than one application group, it is probably a problem with the ADT code. It is important to dump the contents of the ADT bank when this occurs. If you are running in an XTC environment, you must capture the ADT bank on all hosts. Use the following commands to dump the ADT util$.dump-adt/bank The results are placed into file UDS$*ADT$$DUMP for your analysis

142 Processing UDS Dumps

143 Section 5 Terminating Programs and Handling Errors Most programs executed in UDS terminate without error. A program may, however, terminate because of a UDS rollback, a program timeout, or an external request to stop the program from a demand terminal or from the system console. This section explains how to terminate programs. It also discusses the types of UDS error messages and explains how to add or change them Idling UDS Application Groups Idling a UDS application group means that no UDS threads are allowed to execute in the application group. Generally, you idle a UDS application group during installation of the UDS products, but you may have other reasons for wanting to idle a UDS application group. To properly idle a UDS application group and ensure database consistency, you must enter the following app-name INPUT FUNCTION ii II WILL PUT APPLICATION DOWN (SHORT RECOVER TO UP IT) ARE YOU SURE YOU WANT TO DO AN II KEYIN - Y,N? y UDS DUMP TAKEN 02/04/01 12:34:56 app-name*dump0(13) The application group will be aborted. The UDS Protected Fixed-gate Shared Subsystem will be deactivated. SHORT RECOVERY is needed for cleanup. EXITING SUDS

144 Terminating Programs and Handling Errors This command disables the application group, terminates any programs that are executing, and deactivates the UDS protected fixed-gate subsystem. This proper termination ensures database integrity in the UDS environment. Refer to for more information on the SUDS II command. Note: It is not acceptable to idle a UDS application group with AP application-group-number DN keyin. This keyin has no integration with UDS. UDS does not recognize that the application group is down until it issues a subsequent step control call Terminating Programs To terminate a UDS program executing from a demand terminal Press the FCC GENERATE/MSG WAIT key. After the **INTERRUPT** line, with any of its options (I, O, C, T). UDS Control rolls back and abnormally terminates the program. Any uncommitted updates made before the termination are rolled back. You can terminate a UDS program from a system console with the E keyin, which causes UDS to roll back and terminate the user program in error. If this occurs, you receive the following message on your screen indicating that the program is being terminated in error with the specified run-id: E run-id run-id*appnin APT OUTSIDE OF UDS, THREAD ROLLBACK BEING ATTEMPTED run-id*appnin APT THREAD TERMINATION COMPLETED Operators should never use an X keyin to terminate a UDS program. If this occurs, the operator receives the message: Are you sure you want to X this run-id? If the operator responds YES, you receive a message on your screen indicating abnormal program termination. An X keyin by the operator prevents UDS Control from rolling the program back. Consequently, it may leave some files in an inconsistent condition. An X keyin also disrupts UDS Control processing. If this occurs, the operator must immediately enter the following app-name ii ap application-group-number up short recover; act appl application-group-name; end;

145 Terminating Programs and Handling Errors 5.3. Abnormal Program Termination Abnormal program termination occurs whenever a program is executing a thread and attempts to terminate or exit UDS without first completing its processing. When abnormal program termination occurs, UDS issues the following messages: ABNORMAL PROGRAM TERMINATION (APT) HAS OCCURRED WITHOUT A UDS END THREAD OR DMS DEPART. APn APT OUTSIDE OF UDS, THREAD RB BEING ATTEMPTED. THREAD nnnnrollback IS ATTEMPTED (1) THREAD nnnnin PROCESS OF ROLLBACK (2) APn APT THREAD TERMINATION COMPLETED (3) The thread is then rolled back and processing is terminated. Termination can occur as a result of T entry An operator E keyin terminating the run The user program executing an ER ERR$ A timeout error A contingency in a user program that is not processed by the program The first message (1) appears when the thread does not start rollback processing within a specific time allotted by UDS Control. The second message (2) appears when the thread does not complete rollback processing within a time period allotted by UDS Control. The third message (3) appears when the thread has completed rollback processing. In most cases, it means that the thread successfully completed rollback. Under some abnormal conditions, for example, encountering an I/O error on database files during rollback, UDS Control sends appropriate messages to the console. These messages include notification that a database file is marked DOWN. Even under these abnormal conditions, message (3) is issued when the rollback processing is complete. If the first or second message appears more than once, the thread probably encountered some UDS Control problem such as a hang or infinite loop. You may need to use the SUDS utility to bring down the application to get rid of the thread. Use caution because it can take a long time for a thread to complete rollback processing

146 Terminating Programs and Handling Errors 5.4. Handling UDS Errors This subsection discusses how errors are handled and reported in UDS. UDS database products share a common error module that allows them to handle errors consistently among products. The following information explains how UDS reports error conditions back to a program in error or to the system console Contingency Errors UDS Control processes all types of contingency errors. For a complete description of contingency types and an explanation of OS 2200 contingency processing, see the ER Programming Reference Manual and the System Services Programming Reference Manual. Table 5 1 describes what happens in UDS in the case of a contingency error. These are general rules; some special circumstances may give other results. Table 5 1. Contingency Error Result Type 01-07, 010 (except for the remote BREAK C), 011, (because of the remote BREAK C) Result 1. UDS Control issues an error message to the system console, and then issues snaps of execution environment information in one or more error messages to the user program PRINT$ file. The error message describes the contingency error. 2. UDS Control sets the application group to an ABORT-IN-PROGRESS state and initiates a UDS application group dump. 3. An ER DMABT$ aborts the UDS application group. 4. UDS Control issues an APPLICATION ABORTED message to the user PRINT$ file, sets the application group to the aborted state, and deactivates the UDS protected fixed-gate subsystem. Processed like a 017 contingency. 0-12: I/O Resumes execution at the point of the I/O request to process the error. 0-12: TIP scheduling Connects user program to TIP by an ER PBCON$; resumes execution and retries the TIP ER. 0-12: Max pages Resumes execution control and avoids the ER that attempted the print request. 0-12: Failure to change bank characteristics (size, address range, etc.) Resumes execution control and avoids the ER that attempted to modify the characteristics of the bank. Sets return status information so that the ER requesting code can recognize that the request failed. 0-12: All others Performs steps 1 to 4 as described in the first entry in this table

147 Terminating Programs and Handling Errors Table 5 1. Contingency Error Result Type Result 017 A user program (thread) has attempted to terminate without returning control to UDS. This occurs when a user T, the system operator performs an E keyin for the run, or the transaction program experiences a persistent max time condition. UDS Control Issues snaps of executing environment information and issues an APT WHILE UDS error message. Places the thread in a rollback state Resumes execution control as if the contingency had never occurred, to continue processing the command. Detects that the thread is in a rollback state and rolls back the thread. Terminates the thread. 021 This contingency type is an extended-mode-only contingency. In most cases the application group is aborted. Infrequently, the UDS thread terminates in error. NA Contingencies marked as asynchronous (for example, most max time/sup contingencies are marked asynchronous) Internal Errors UDS Control performs many consistency checks during program processing. If one of these checks fails, UDS Control takes the following steps: Issues an internal error message describing the problem Performs a dump of the UDS internal tables and data banks Aborts the application Refreshes the application group Refreshing the application group means recovering the database files and messages to a consistent state after an application group failure. This process is performed by IRU short recovery. For more information, see the Universal Data System Configuration Guide. If you cannot resolve the problem, send the dump, system operation information, and any other supporting information to Unisys for analysis

148 Terminating Programs and Handling Errors 5.5. UDS Control Messages UDS Control uses messages to report anything unusual in the UDS run-time system. For compatibility, UDS Control continues to return the command status to the user program whenever appropriate. Additional message text clarifies the returned status and provides advisory information. Error messages can originate from UDS Control, UREP (DSR or DSD), or any of the logical data managers (LDM) that access UDS Control. The format of the message and the system response to the error are different, depending on where the error originates. You may want to change the text of UDS Control messages to suit local conditions. You may, for example, wish to translate the message text into another language or add special notes or instructions for users. Error messages are classified by the reason they were generated (after a rollback, for example). The four types of UDS Control messages are informative, external, rollback, and internal. The first item in the message header indicates the message type. You can also tell the message type by looking at the message number. For example, all external message numbers fall in the range to (see Table 5 2). Table 5 2. Types of UDS Control Messages Message Type Header Numbers Informative IN External EX Rollback RB Internal IT By following a few simple instructions, you can change the text of any UDS Control message without adversely affecting system performance or error handling, as instructed in

149 Terminating Programs and Handling Errors Table 5 3 explains what each type of message means. Table 5 3. Description of UDS Control Messages by Type Message Type Informative Description Advises you of a situation not typical of the normal UDS run-time environment. This situation is not an error and does not affect normal processing of the current user command. The following is an example of an informative message: APP 3 RDM IN 5020 No find or end of cursor. External Tells you that UDS Control denied the current request because the program has an error. UDS Control stops the processing, issues the message, and returns control to the user environment. The type of LDM being used determines the type of recovery (that is, command rollback). The following is an example of an external error message: APP 3 RDM EX Constants not allowed in program variable list of an OPEN (READY) command. Rollback Means that a conflict arose while processing your current command and that the only way to resolve it was to roll back the run. Usually, the conflict is with a command request from another user. The rollback cancels all your commands since your last commit point. Resubmit any commands that were rolled back. The following is an example of a rollback message: APP 3 DCS RB First command is an explicit thread control command other than BEGIN THREAD. Try a BEGIN THREAD first. Internal UDS Control produces an internal error message whenever it has detected an internal problem with UDS Control code or its internal data tables. An internal error message is sent to your print file and to the system console. After a dump is produced, an application group refresh terminates all current running under UDS Control and brings the application group back up through IRU short recovery. Following short recovery, UDS Control is ready for you to use again. The following is an example of an internal error message: APP 3 DCS IT UDS thread control issued a terminate request for a thread that is not EOS or rollback-in-progress

150 Terminating Programs and Handling Errors Message Format Each error message consists of a message header and one or more lines of message text. The header indicates the source component of the message, the number of the application group, the UDS component, and the message number. The message text clarifies the command status and provides other advisory information. The format of the message header is as follows: APP application-group-number UDS-component message-type message-number The text of the message immediately follows the header: APP 3 DCS IN 2020 message-text Scope and Impact of Errors Errors vary greatly in their scope and impact. Informative errors have minimal impact. External errors are probably caused by an error in the session, program, or application group setup. Rollback errors may be caused by user programs. They can also be caused by the UDS system recovering internally from a problem such as deadlock. UDS detects deadlocks and resolves them by rolling back one of the participating threads. A rollback, therefore, can be related to time, in which case reexecuting the program is sufficient. Internal errors should never occur, but if they do, report them to Unisys with a User Communication Form (UCF). Contingency errors are similar to internal errors. Some contingencies are handled internally within the contingency handler of UDS Control and do not really represent error conditions. Contingencies such as guard mode addressing violations (IGDM) or illegal operations (ILLOP) indicate errors in the UDS code. UDS handles these cases in much the same way it handles internal errors. Step control aborts the application group and short recovery gets things running again. Informative, external, and rollback errors affect only one program. UDS internal errors and contingency errors affect all programs active at the time of the error as well as any new programs attempting to enter the application group. Whenever possible, UDS code attempts to handle errors as rollback errors rather than as internal errors Error Message Generation UDS Control provides an error message module (EMM). All UDS components can call the EMM to add, delete, or build error messages. During normal processing of a user command, the components call the EMM to add or delete message packets to a queue of messages for a specific command. The EMM has no user interface. Instead, each LDM has its own protocol for communicating with users. When the LDM determines that a user command is completed, it asks the EMM to generate any messages. These messages are queued. The LDM then returns the message text to the user according to the rules of the data model for the LDM

151 Terminating Programs and Handling Errors 5.6. Message Text The text for all UDS Control messages resides in the UDS Control chameleon fixed-gate subsystem. All message text is in special compacted dictionary form as processed by the message control processor (MCON). UDS Control code refers to the message text by message number. As a result, you can change the message text without changing any UDS Control code Syntax Message text consists of fixed phrases that clarify the command status or provide additional information. Message text is in English, which you can translate into another language. UDS Control modifies the text of some error messages at run time by inserting parameters at specific points in the text. These parameters help to describe the situation that caused the error. In the source message text, which resides in the MCON elements described later in this section, the parameters are within brackets ( [ ] ). The information within brackets which you must not change represents a value to be inserted by UDS Control. Example The source message text contains UNQUALIFIED ITEM [dec_up1] HAS NOT BEEN SUPPLIED. The message you receive, depending on the situation, might read UNQUALIFIED ITEM S2APPLE HAS NOT BEEN SUPPLIED. UDS Control inserts the value of the parameter in place of the information in brackets in the source message text. In this example, dec_up1 was assigned the value S2APPLE Changing and Translating You can change any or all fixed phrases in the source message text to suit local conditions. You can also add advisory information or special instructions to the message text for your site. Once you change the source message text, messages are returned as translated. The source of all UDS Control message text is in the SYMBOLIC file on the UDS release tape. The following elements contain the error message text: MCON-DCS MCON-TCS UDS Control messages Table control system messages

152 Terminating Programs and Handling Errors The source of all UREP message text is in file UREP$SOURCE on the UREP release tape. The elements that contain the error message text are ERR-MSG-MCON and MESSAGE-TBL in UREP$SOURCE. For more information about UREP message translation, see the Universal Data System Configuration Guide. You can translate message text in any message text element by following these instructions: List the element and the corresponding permanent correction file (PCF) element on the release tape, where all corrections to the base level of code were made. Decide which line or lines of message text you want to change. Generate one COMUS CHG document for each message text element you are changing. For more information, see the COMUS End Use Reference Manual. Example The following example replaces the previous text of message number at line number 297 of MCON-DCS with new instructions. After you make this change, message number always returns the new message text. *MCON-DCS -297, SHORT RECOVERY FAILED - CALL J. DOE X1234. Perform a COMUS build to generate the message text change as a local fix to the appropriate product. For more information, see the COMUS End Use Reference Manual. Reinstall the regenerated product using SOLAR. You have considerable freedom and flexibility but must nevertheless follow these rules when changing error message text: You cannot change, add, or delete message numbers. UDS Control views messages as message groups. A message group is a set of messages with consecutive message numbers. You must leave at least one message number unused between each message group. Example The following example ends one message group at message number and starts another with message number At least one number must be skipped to indicate the end of one message and the beginning of the next Recovery control IO errors caused all files altered by this thread to be disabled, selective recovery may be required A retention file was found down at time of read

153 Terminating Programs and Handling Errors Each message line may be up to 132 characters long. Of these 132 characters, 20 are reserved for the header. You can add additional lines of message text as long as you do not violate the group structure. Note that this restriction does not apply to UREP messages. In UREP, lines are separated by the [skip] directive within a single message number. Some source message text has items enclosed in brackets. At run time, UDS Control replaces the bracketed items with a specific value or name. In source message text, bracketed information specifies the length and type of the value used to complete the message. For messages with variable parameters, the following rules also apply: Example Do not change any part of the message text enclosed in brackets. If a message has more than one expression enclosed in brackets, keep the relative sequence of these expressions the same as in the original message. For UREP messages, you should not remove bracketed references such as [error] and [urep-number], as these are required for proper error classification and counting. This example illustrates a valid message text translation: Illegal message number: [dec4-up1] submitted, max is [dec4-up2] The translated message is Message illegal de numero [dec4-up1] est soumis, le maximum est [dec4-up2]

154 Terminating Programs and Handling Errors Locating Messages The text for messages is in UDS$$SRC*UTIL$.MESSAGES. UDS$$SRC*UTIL$ is the standard release utility file placed on your system when UDS Control is installed. The MESSAGES element is a collection of all UDS messages and is your online reference for easy access to the text of messages. To locate a message, uds$$src*util$.messages l =component l message-number where: component is the UDS Control software component issuing the message, DCS or TCS (component name must be uppercase). message-number is the number used to locate the text. For information on how to find the message text if the message indicates an RDM message, see the Relational Database Server for ClearPath OS 2200 Administration Guide

155 Section 6 Recognizing and Correcting Abnormal Conditions Section 3 describes monitoring UDS in a normal operating environment and included suggestions for verifying that the programs in your UDS application group are performing as intended. This section describes representative abnormal operating conditions. It also describes the symptoms that help you to identify abnormal conditions, explains how to find the source of the problem, and explains the corrective action to take to return to normal operations Abnormal Condition Categories Four categories of abnormal operating conditions can occur in UDS: UDS is accessible but programs fail while executing. UDS is accessible but programs seem stalled. UDS is accessible but the database seems inconsistent. Programs cannot access UDS

156 Recognizing and Correcting Abnormal Conditions 6.2. UDS Is Accessible: Programs Fail While Executing In this category of abnormal operating conditions, a program establishes UDS session but incurs an error while executing and receives a UDS error message. The program then rolls back and cannot make further progress. This condition usually occurs in a small number of programs in the application group. Other programs are able to progress. Generally, the error message indicates either a file or deadlock problem. The following subsections describe file and deadlock problems Problem: Files Abnormal conditions that occur in this category can affect a system or database file. If the file caused the problem, the current UDS session for the program terminates in error. The system issues error messages to the program indicating the error and that the current step of a program is rolled back. Depending on the file in question, the system usually rolls back only a small number of programs until you take corrective action to make the file accessible again File Unavailable (Rolled Out) If your site does not have enough mass storage to hold all files cataloged on the system, the system rolls out unassigned files. The system also reallocates the associated mass storage as required to service current file access requests. When the system frees database or system files, the system might roll out one or more of the files. When the system again attempts to assign these files, the files are not immediately available. Progress cannot continue until the file or files get rolled back from mass storage. With few exceptions, the system does not wait for the file to be rolled back. Instead, the system rolls back the UDS session requiring access to the unavailable file and issues the appropriate messages. Symptom A program gets an error and the system rolls back the current step. The error messages indicate which file was not available. In general, this can be any database file with the exception of the UDS retention files, the UDS system file (UDS$$SRC*SYS-FILE), or the ADT backup file (UDS$$SRC*ADT-FILE). These files are always available. Analysis To check the status of the file, file-name

157 Recognizing and Correcting Abnormal Conditions Corrective Action If the file is rolled out, you can reexecute the program after the file is rolled in. Even though the program has received an error, the system continues to roll in the file. The file must be available in a few minutes. To ensure that the file is rolled in before executing the program, check the status of the file file-name File Unavailable (Assignment Conflicts) A file might be unavailable because of file assignment conflicts from users outside of UDS. If one or more runstreams have the same file assigned outside of UDS, the system does not wait for the file to be freed by other runstreams. The program gets an error and rolls back. The error message indicates the file that caused the problem. When UDS attempts to assign files UDS$$SRC*SYS-FILE, UDS$$SRC*ROLLBACK0001-n, and UDS$$SRC*ADT-FILE and assignment conflicts exist with other users, UDS waits until the files become available. The files can be assigned, but not exclusively. Programs other than UDS must not have these files assigned. For information about how files are assigned and freed, see the UDS Control Conceptual Overview. Symptom A program gets an error and the system rolls back the current step of a program. The error messages indicate which file was not available. In general, this can be any database file. Analysis If the file is assigned to a program other than UDS, the run that has the file assigned must free it. Alternatively, the run can assign the file with a compatible option. To find the source of the problem, determine whether the file is rolled out, if it is unavailable because of assignment conflicts, or if the file is lost (possibly because of disk failure). To check the file status, file-name If the file is rolled out, see above. If the file is no longer defined, it is lost (see ). If the status indicates that the file is assigned, you have file assignment conflicts with programs outside of UDS. Corrective Action A program other than UDS has the file assigned. The program must free the file so that UDS can assign it. You must use your own method to determine which active runstream has the file assigned

158 Recognizing and Correcting Abnormal Conditions File Unavailable (Security Violation) UDS catalogs and assigns its system files during installation. Therefore, for systems without Security Option 3, system files must have the same security level as the installation run. Ensure that the installation run and all subsequent UDS users have the same security level. System files remain assigned to the UDS common bank until a system failure occurs. Following a system failure, the IRU short recovery procedure must be performed so that UDS reassigns its system files. Users cannot access the application group until short recovery is run. UDS recatalogs the system files if the Exec cannot recover the files (for example, because of a disk failure). These conditions apply to both systems without Security Option 3 and to those that have common bank protection turned on. For systems that have common bank protection turned on, the system files have the security level of the owner of the files. The owner is the user-id given as the UDS subsystem user-id during installation. UDS Control is a protected subsystem. This means that when UDS Control assigns a file, the security attributes of the protected subsystem determine whether or not the file can be assigned. In short, the UDS subsystem must be able to assign files. The owner of the application group file application-group-qualifier*udsc$pfgsdef is the UDS subsystem user-id (for the default application group, for example, the owner of file UDS$$SRC*UDSC$PFGSDEF). The user-id was created when UDS Control was installed. The UDS Control subsystem must be able to read and write the retention files. The clearance level of the retention files must therefore be the same as the clearance level of the UDS Control protected subsystem. Further, when UDS Control catalogs the retention files, it catalogs them with the clearance level and compartment set of the UDS Control protected subsystem. In general, the UDS Control subsystem user-id must be able to assign the files, which means that both mandatory and discretionary security checking must allow access to the files. For further information on security user-ids required for UDS products, see the Universal Data System Planning and Installation Overview. Assume that the system failed and you initiated IRU short recovery. If the Exec is unsuccessful in recovering queue items, IRU accesses the audit trail to recover the queue items. During initial boot, the system uses the highest level of security available (clearance level 63) to catalog the audit trail file and ACI file. Therefore, any runstream calling IRU must have the same security level. If not, IRU short recovery cannot assign the audit trail file or ACI file, short recovery fails, and the application group becomes unavailable. You can use the REFRESH runstream to automatically initiate short recovery after a system failure. If you use the runstream, the security level of the runstream is assigned to recataloged UDS system files. If you do not use the runstream, the security level of the user program is assigned to recataloged UDS system files

159 Recognizing and Correcting Abnormal Conditions Ensure that the security level of the UDS system files is low enough so that all database users can access the system files. Symptoms One of the following symptoms occurs: A UDS program gets an error and rolls back if the system cannot assign a required database file. The program gets an error message indicating which file cannot be assigned. If the accompanying facility status has a value of 10 (that is, bit 3 is set), the program has incurred a security violation. Following a system failure, IRU returns an error indicating that the system cannot assign either the audit trail file or ACI file. The error message also indicates that the status word has a value of 10. The program that gets the error is either the first program triggering the REFRESH element, or if the REFRESH element is not set up, the program that explicitly invokes IRU short recovery. Following a system failure, if the database files are reassigned with a security level greater than originally cataloged, IRU cannot roll back updates from the retention files to the databases. When a program tries to write to the database files, it gets an I/O 20 error for each database file that has updates recorded in the retention files. Even though IRU messages state that short recovery is successful, the system disables each database file that encountered the error and issues the appropriate message. A UDS program gets an error and the UDS session terminates because the system cannot write to a retention file. The error messages indicate the name of the file causing the error and display an I/O error status of 20. Analysis An I/O 20 error or file assignment status of 10 indicates a file security conflict. Corrective Action If short recovery is not successful because the audit trail or ACI file cannot be assigned (status=0) when invoking the REFRESH element, you can take one of two corrective actions (the first approach is generally preferred): Use TeamQuest SIMAN to lower the security level of the audit trail file and ACI file to the security level of all other UDS users (that is, the security level of all other UDS database and system files). Follow these steps: 1. Before calling IRU, use the COMUS CLOD processor to put yourself into privileged mode; this bypasses file security so that you can assign the audit trail file and ACI file. This also ensures that all other system files are assigned at the proper security level and enables IRU to assign the audit trail file and ACI file, which have a security level of If you invoke IRU manually from a separate runstream, ensure that your security level is that of all other UDS system and database files

160 Recognizing and Correcting Abnormal Conditions 3. Remove the REFRESH element from the app-name*sym$ file for the application group and invoke the IRU short recovery procedure. If the retention file is getting I/O 20 errors, a runstream has assigned the files to the UDS common banks and used a security level that is too high. Follow these steps to free the files and assign them to a security level equal to all other UDS database files: 1. Manually abort the application group so that it is inaccessible. Execute the UDS supervisor program (SUDS) and use an II command to abort the application group and set the application group to a pending state. For more information about SUDS, see Section Ensure that you freed all retention files from the UDS common bank before running IRU short recovery. You can use the SUDS FF command to free each file. 3. Using the TeamQuest SIMAN processor, interrogate file security levels to ensure that they are cataloged at the proper security level. If they are not, set them to the same level as all database files. 4. Use IRU short recovery. When calling IRU, remember to use the same security level as all other database files Retention File Unavailable (Disabled) Although retention files have no FDT, they behave very much like normal files, and the IRU recognizes them for UP, DOWN, and LIST operations. A retention file can have a status of UP, DYING, or DOWN and a retention file segment can have a status of UP, DYING, or DEAD. If an I/O error occurs while a segment is being used by a thread, the segment status is set to DYING. When the segment is no longer in use by the thread, its status is changed to DEAD, and it is out of service. The segment status is also set to DEAD if the first write to the segment fails. Under certain conditions, when UDS Control determines that a significant percentage of the segments in a retention file have been set to DEAD, the retention file status is set to DYING. When the last thread active in the retention file releases the retention file, the retention file status is set to DOWN, meaning the retention file is out of service. Symptom The dead segments and down retention files affect the number of parallel updating threads that can run in UDS and might lead to queuing. Analysis Call IRU and enter the LIST command to check the status of the retention files. A segment status is set to DEAD, and the file status can be set to DOWN, if I/O errors occur while writing to a retention file. A read error does not set the segment status to DEAD or the file status to DOWN. Therefore, you can assume that an I/O error occurred while data was being written to the retention file

161 Recognizing and Correcting Abnormal Conditions Corrective Action Since the I/O error occurred during writing to the retention file, you might not have to perform any IRU recovery procedures. Simply ensure that rollback was completed successfully; if not, you need selective recovery. To repair a retention file, you need to delete and recatalog it. To delete the file, use the IRU DOWN command to free the file, specifying the retention file name given in the error message. Delete and recatalog the file. Ensure that you catalog it with the same security level as the rest of the retention files. Use the IRU UP command to bring up the retention file, using the same file name as on the DOWN command File Unavailable (Disabled) Each UDS file has an internal file description table (FDT) entry describing the file (except for the ADT backup file, retention files, and UDS system file). An FDT for a file contains the encoded form produced from the symbolic storage area definition for a file. The UREP repository contains the storage area definitions. When you or the system catalogs a file, its status is UP, DOWN, DOWN FROM UPDATE, or DOWN-PAGES. The status of the file is recorded in the FDT. If the status of a file is UP, UDS programs can access it. If the status of a file is DOWN, UDS programs cannot access it. The status of the file is DOWN when one or more of the following conditions exist: A program gets a fatal I/O error while writing to the file and while the system is attempting to roll back the program using quick-before-looks. A program commits database updates while using the medium recovery strategy. A program rolls back or rolls forward during short recovery (the program gets an error message, the system changes the status of the file to DOWN or DOWN PAGES, and the system rolls back the current step of the program, except for updates to the disabled file). If you are using short recovery, the status of the file is marked DOWN and processing continues. This information is passed to the IRU runstream. You can use the IRU DOWN command to explicitly set a file to the DOWN state or to the DOWN FROM UPDATE state. If a program attempts to access a file that is in the DOWN state or if a program attempts to update a file that is in the DOWN FROM UPDATE state, the system rolls back the program and issues an error message. You can use the IRU DOWN command to explicitly set a page to the DOWN state as well. If a program attempts to access a disabled page, the system rolls back the program and issues an error message

162 Recognizing and Correcting Abnormal Conditions Symptom A program gets an error message indicating that the program was rolled back because it attempted to access a file or a page in the file that is in the DOWN state. Analysis First, determine why the file or page is disabled. Did someone use the IRU command to disable the file or page? Did the system disable the file? Call IRU and enter the LIST command to check the status of a file. Whenever the file is in a DOWN FROM UPDATE state, it means that IRU was used to place the file in this state. If the status of the file is DOWN or DOWN-PAGES, you need more information. Do not enable the file or page (using IRU, for example) until you determine why the file or page is down. If the program incurred a fatal I/O error and received error messages, the system disables the page if possible; otherwise, it disables the file. If the program did not experience a fatal I/O error, check your administrative save procedures to see whether the file or any of its pages were inadvertently left in a DOWN state during a static dump. Include the IRU LIST command at the end of your save procedure to list the status of all saved files. If you cannot determine the reason for a status, you can assume that the file had an I/O error when the program rolled back or committed deferred updates. Corrective Action If the file or any of its pages were explicitly set DOWN, you can get the file online by calling IRU and performing an UP command. Once the file and all its pages are up, you can reexecute the programs that terminated in error. If the system disabled the file or a page, use the IRU selective recovery procedure. If the database file is not an audited file, use the reload procedure (see the Integrated Recovery Utility Operations Guide) File Unavailable (I/O Errors) If a program gets an I/O error while reading or writing to a database file, the system rolls back the program. If rollback is successful, the database file is left in an UP state. Two problems can occur during rollback: If the database file gets another I/O error while trying to roll back the updates, the system disables the affected page, if possible; otherwise, it disables the file. The system then issues the appropriate message and completes the rollback process

163 Recognizing and Correcting Abnormal Conditions If the program gets an I/O error while trying to read from the retention file during rollback, the system terminates the program and issues a message that specifies the I/O error and the retention file name. The system also disables all files that have quick-before-looks and after-looks recorded in the retention file, and issues messages indicating the disabled files. If a program gets an I/O error while writing to the retention file, the system sets the segment to DEAD (and possibly the file to DOWN), and attempts to recover. If the recovery is successful, the thread continues; if not, it attempts a rollback and probably fails. The DEAD segments and DOWN files affect the number of parallel updating threads that can run in UDS and might lead to queuing. A program might get a fatal I/O error while committing deferred updates to the database file. If this occurs, the system disables the affected page, if possible; otherwise, it disables the file. The system then terminates the thread and issues messages that specify the I/O error and DOWN condition of the file. Symptom An active UDS program is rolled back with accompanying error messages indicating that an I/O error occurred while the program was reading from or writing to a database file. The messages also indicate the file name, the I/O error status, and whether the database file error occurred during rollback. One example of an I/O error message is the DCS message, as follows: APP 3 DCS RB An I/O error 0152 occurred for EXEC FILE UDS$$SRC*DBFILE. at sector The I/O error status is returned by the UDS Control I/O Interface (UDS$IOW). For a description of the I/O error status, see the System Services Programming Reference Manual. If the error occurred during rollback, a message indicates that the system disabled either a page or the entire file. If an I/O error occurred while reading from a retention file, the system terminates the program. The program gets the appropriate messages stating the retention file name and the database files that were disabled because of the error. The system rolls back a program and issues appropriate messages indicating that an I/O error occurred while writing to the retention file. A fatal I/O error occurs while writing to a database file to commit deferred updates, and the system terminates the program. The system issues I/O error messages indicating that the file or a page of the file was disabled. Analysis Use the error message text to determine the file type: Is it a database or retention file? Determine also whether the I/O error occurred because of a security violation (code 20)

164 Recognizing and Correcting Abnormal Conditions Corrective Action If the I/O error occurred while writing to a recoverable database file to roll back or commit deferred updates, use the IRU selective recovery procedure (see the Integrated Recovery Utility Operations Guide). If an I/O error occurs while reading from a retention file during rollback processing, use the IRU selective recovery procedure. Selectively recover the disabled database files listed in the error messages. The system automatically deactivates the problem retention file. If the I/O error occurred while writing to a retention file, you do not have to perform any IRU recovery procedures. Ensure that the rollback was completed successfully; if not you need to use selective recovery. To correct a retention file, you need to delete and recatalog it. To delete the file, execute IRU using the DOWN command to free the file, specifying the retention file name given in the error message. Delete and recatalog the file. Ensure that you catalog it with the same security level as the rest of the retention files. Use the IRU UP command to up the retention file, using the same file name you used on the DOWN command File Unavailable (Lost or No Longer Cataloged) When UDS attempts to assign a database file, the file might no longer be cataloged or the file might be lost (hardware disabled or parts of master file directory destroyed). This condition can occur following a system failure if Exec file recovery did not recover all files after a disk failure. Also, a database file might no longer be cataloged because a user runstream inadvertently deleted it. The system frees database files whenever they are not in use. The system never frees UDS system files, however, from the common banks. If the system files are not recovered after a system or disk failure, users cannot access the application group. Symptom Established UDS programs are rolled back with accompanying error messages indicating that a file cannot be assigned. The error messages specify the file name as well as the facility assignment status. Analysis If the error message facility status indicates that bit 21 is set, the file is not defined in the system. If bit 8 is set in the status word, the file is lost because parts of the master file directory are destroyed or the physical file is destroyed

165 Recognizing and Correcting Abnormal Conditions Corrective Action If the file is not cataloged, recatalog it. Or delete the file, and then recatalog it. If the UREP storage area attributes AUDITED and RECOVERED are set to TRUE, use the IRU selective recovery procedure to recover the file. If the value of AUDITED is FALSE, use the reload procedure (see the Integrated Recovery Utility Operations Guide) Files Cannot Be Expanded (Special Case I/O Error) If a system or database file reaches the maximum allocated size, it gets an I/O error 22. The system informs the program of the I/O error and, if possible, rolls back the program that caused the file to overflow. Symptom An established UDS program rolls back with an error message indicating that an I/O error 22 has occurred. If rollback cannot occur because of additional I/O errors, terminate the program (see Section 5). Analysis When the configuration is too small for a retention file, the file is rolled back because you cannot acquire any more segments. I/O error 22 indicates that the files are cataloged too small for the defined configuration. Recatalog the file with a larger size. If a database file caused the error, the system rolls back the database updates of the program causing the overflow, leaving the database in a consistent state. Nevertheless, you probably must recatalog the file with a larger size. Corrective Action If the retention file overflowed, you can rewrite the program so that it commits updates at shorter intervals. If you cannot do this, you can expand the retention file in the configuration. For example, call the UREP processor, alter the value of RETENTION-MAXIMUM-POSITIONS, and use the UREP PROCESS CONFIGURATION...INSTALL command to replace the old value of the UREP storage area size attribute with a larger one. If you are using the RETENTION-FILE-ALGORITHM "SINGLE-FILE" you must consider changing to the "POOL" algorithm (see the Repository for ClearPath OS 2200 Programming Reference Manual)

166 Recognizing and Correcting Abnormal Conditions Example 1 In this example, it is assumed that you are changing from SINGLE-FILE @. Call UREP and add the The system default for pool structure will update configuration release. add retention-file-algorithm Now show the POOL structure generated by UREP process configuration release report. process configuration release @. Reinitialize the exit. If this is a database file, you do not have to reorganize or reload the database. For an RDMS database file, the overflow might have occurred either because the maximum logical page number was reached or the actual physical limit of the file was reached. Check your calculations to determine whether the page size times the number of pages is greater than the maximum size used when the file was cataloged. If so, you can use your own runstream to call IRU, use the IRU DOWN command for the RDMS database file, and assign the file, specifying a larger maximum file size, as in the following qualx*filex.,///new-maximum-file-size After expanding the file by reassigning it, use the IRU UP command to make the file available for online access. If you reach the maximum number of pages allocated for the file, you can dynamically expand this number by calling the UREP processor (@DD) to update the storage area to reflect a new maximum page number, followed by a PROCESS STORAGE-AREA for UPDATE to put the new, expanded file size in effect. In either case, you can rerun the programs. To expand an SFS data file, use the IRU DOWN command to disable the file, use an independent runstream to reassign the file with a larger maximum size, and then use the IRU UP command. If the file is a direct system data format (DSDF) file, your program must open the file with the EXTEND option on the OPEN command to create the expanded area. You do not need to use the EXTEND option on subsequent OPEN commands

167 Recognizing and Correcting Abnormal Conditions To expand the physical size of a DMS dynamic area record placement (DARP) area (data file), you can recatalog the file up to the maximum expandable size of the area that is specified on the Data Definition Language (DDL) ALLOCATE clause. For more information about how to allocate space and expand DARP areas, see the DMS DDL Administration, Operations, and Programming Guide. For information about increasing the number of pages in a static area record placement (SARP) area and maintaining DMS files, see the Network Database Server for ClearPath OS 2200 Administration and Support Guide. Example 2 This example illustrates how to expand the physical size of RDMS, SFS, and RDMS Case: Update the max pages allowed for the file by the storage While this is taking place, users attempting the file will be queued until the FDT describing the file is released following Before doing this update to reflect a larger however, one must DOWN the file with the IRU to a FREE of the file You can then reassign the file temporarily with bigger You then UP the file with the IRU before updating storage @. Step 1: DOWN file, ASG it with a larger max size, then file again for DOWN file exampl*exfil;act; UP file exampl*exfil; Step 2: Now you can update the storage area definition the repository to reflect this UPDATE STORAGE-AREA exfil FOR SCHEMA exampl. ALTER MAXIMUM-PAGES REPLACING 3 WITH 10. PROCESS STORAGE-AREA exfil FOR SCHEMA exampl UPDATE

168 Recognizing and Correcting Abnormal SFS Case: For either of the file formats supported by (DSDF or MSAM), the number of pages specified the storage area definition is This information is gotten from the The size of the file is merely expanded by it from UDSC and reassigning it to a larger This is done with the IRU by DOWNing the file in the The file may be again accessed by UPing the with the IRU after reassigning it with a You then UP the file with the IRU before updating storage Reaccessing the file then depends upon the format and the language supporting MSAM: The next user OPENing the file may inserting new records or updating any records and may optionally OPEN the for EXTEND (for the semantics of this should consult the programming manual). DSDF: The next user OPENing the file MUST OPEN file for EXTEND in order for SFS skeletonize all records beyond the old Again you should consult the manual you are using for the semantics EXTEND. DOWN file exampl*exfil1 ; act; UP file exampl*exfil1; DMS Case: When using DMS database files (DARP), you can get an error when indicating no more physical in the file if the maximum number of expandable defined in the schema calculates to be larger the physical file size used on the original

169 Recognizing and Correcting Abnormal When this occurs you can dynamically expand physical file space at the end without affecting database. The pages at the end of a DARP area do The procedure for physically expanding this follows the same line as a Shared You will notice the file qualifier for the file is the DMS Universal Qualifier; therefore, it different from the qualifier of the storage-area (the @. STEP 1 : Down the area with IRU to flush used pages UDS memory and to free the file from STEP 2 : Reassign the file with a higher maximum Then free STEP 3 : Up the file with the IRU to make it again for All subsequent run units may start adding DMS will allocate these new pages and these DARP overflow pages as it Once you reach the logical maximum number of specified in the schema you will need to and reload the DOWN file uds$$src*exfil2; act; UP file uds$$src*exfil2; act;

170 Recognizing and Correcting Abnormal Conditions File Unavailable (I/O Errors in IOMAX Subsystem) An RDMS program that uses the fast search feature executes I/O through the fast search subsystem (IOMAX). The system rolls back the program and UDS displays a message containing the substatus of the error that occurred in the IOMAX fast search subsystem. Symptom The user program is rolled back with an accompanying error message or APP 3 DCS EX IOMAX returned call-stat = s'failed' call-substat = APP 3 DCS EX A contingency occurred while control was in IOMAX Analysis The message indicates an error occurred while executing in the IOMAX fast search subsystem Problem: Deadlocks Deadlocks occur when more than one program requires the same system resources (such as a file, a page of a file, or memory) at the same time, but only one program can obtain the resources. To resolve a deadlock, the system rolls back all but one of the programs. The programs rolled back, of course, give up the resources they held. The one remaining program request can then be granted. Deadlock also occurs when two or more runs are queued on locks held by each other so that none of the runs can resume execution. The requests cannot be queued in the usual way. If they were, requesters cannot relinquish the resource required by other requesters and no progress can be made. Symptom An established UDS program gets an error message and is rolled back because a deadlock occurred. Analysis The error message indicates that a deadlock has occurred. Corrective Action Rerun the program that was rolled back. If a program frequently gets deadlock errors, try to not schedule conflicting programs concurrently. Unfortunately, this is difficult to do because the programs are often triggered randomly by transaction requests

171 Recognizing and Correcting Abnormal Conditions For more information about how to handle deadlocks for a specific product, see the individual product manuals for RDMS, DMS, or SFS, listed in Appendix A. See also Section Problem: UDSC Basic Mode to Extended Mode Transition Failure UDS Control and RDMS are extended mode object modules in protected fixed-gate and chameleon fixed-gate subsystems. Some functions of UDS Control, however, continue to reside in AFCBs. As such, UDS Control is a mixed-mode subsystem. Mixed-mode subsystems require controlled transitions between basic mode and extended mode. These transitions are controlled by routines available in the UCS Runtime System. They enforce the protocols required by extended mode subsystems. Symptom The following error messages are examples of failed attempts to set up the extended mode environment correctly in order to make proper calls from basic mode to extended mode within UDS Control. ***** UDS initialization/reconfiguration failed. Could not successfully set up the RTS NPE environment. Probable cause is failure to create the TCA bank. xxxxxxxxxxxx (octal) status returned from RTS$TPENPE4. ***** UDSC could not reset the RTS NPE environment in order to complete UDS initialization or reconfiguration. Probable internal error. The application is aborted. ***** UDS initialization for new thread failed. Could not successfully set up the RTS NPE environment. Probable cause is failure to create the TCA bank. xxxxxxxxxxxx (octal) status returned from RTS$TPENPE4. ***** Utility security validation failed. Could not successfully set up the RTS NPE environment. Probable cause is failure to create the TCA bank. xxxxxxxxxxxx (octal) status returned from RTS$TPENPE4. ***** DBEvent/TPAS security validation failed. Could not successfully set up the RTS NPE environment. Probable cause is failure to create the TCA bank. xxxxxxxxxxxx (octal) status returned from RTS$TPENPE4. ***** UMON initialization failed. Could not successfully set up the RTS NPE environment. Probable cause is failure to create the TCA bank. xxxxxxxxxxxx (octal) status returned from RTS$TPENPE

172 Recognizing and Correcting Abnormal Conditions ***** An invalid ALS pointer exists. B10 should contain ALS L/BDI and current ALS pointer. A previously entered extended mode environment could not be restored in order to process the current command. ***** An invalid ALS pointer exists. B10 should contain ALS L/BDI and current ALS pointer. The release of the RTS NPE environment that UDS established at begin-thread time was not successful. ***** UDSC could not set up the RTS NPE environment prior to performing APT rollback. The application is aborted to prevent possible data base inconsistency. ****** UDS SYS REFRESH - EXTENDED MODE ENVIRONMENT NEEDED Analysis Whenever UDS Control generates one of the above error messages, it indicates that further processing by UDS Control for the current command from a user activity is not possible. The extended mode environment needed for UDS Control to continue processing cannot be (re)established. Although the reasons for these situations can be varied in their details, there are two likely themes underlying the errors. First, it might not be possible for UDS Control to establish an extended mode environment the first time for a new thread. This is mostly likely due to the fact that RTS cannot create its TCA program level bank for this activity. This is a resource issue where previously acquired TCA banks were not released via the required RTS NPE exit processing. Second, B10 has been corrupted or improperly maintained between different transitions from basic mode to extended mode and back. B10 is used by RTS to save and restore its position (X10) in the activity local stack (ALS). Corrective Action If the user application itself calls a mixed-mode subsystem outside of UDS Control, then the issue in resolving any error situations detected by UDS Control is to verify that this mixed-mode subsystem abides by the rules and protocols put in force by the RTS routines for handling basic mode to extended mode transitions. The most likely cause for error is the incorrect application of the required RTS routines. The required RTS routines are RTS$NPESTAT, RTS$TPENPE, RTS$NPERESET, RTS$NPESAVE, and RTS$NPEEXIT. These are documented in the Universal Compiling System (UCS) Supplemental Programming Reference Manual, which is used mainly for Unisys internal development but is released to selected customers who need additional information for the incorporation of mixed-mode subsystems in their applications

173 Recognizing and Correcting Abnormal Conditions If there are no mixed-mode subsystems components in the user application and UDS Control reports one of the above errors, then this most likely indicates an internal situation within UDS Control itself. UDS Control engineers must report this type of problem to Unisys in the normal manner for analysis and resolution Problem: UDSC$PFGSDEF File Causes DMS Control Failure If DMS users receive E$251 external errors when using access control records (ACR) to control run unit access to database information, the UDSC$PFGSDEF file for the application group is not owned. For a description of how DMS uses the capability of ACRs to control database access, see the Data Management System (DMS 2200) Schema Data Definition Language (DDL) Administration, Operations and Programming Guide. Symptom DMS threads attempting to use the DMS capability to specify ACRs to control database access receive an E$251 external error and an R$78 rollback error. For more information about these errors, see the Network Database Server COBOL Data Manipulation Language Operations and Programming Reference Manual or the DMS FDML Operations and Programming Reference Manual. In addition, you must use the SQL BEGIN THREAD command, with message suppression, to execute the thread. If you don't specify message suppression on the command, the PRINT$ file for the thread includes the following error message. This message assumes the default application group 3. APP 3 DCS EX An ER MSCON$ request with EXIST$ function performed Analysis during the last UDS D-bank initialization failed to determine the owner of the UDS$$SRC*UDSC$PFGSDEF file. Ownership of this file is required for ACR related security validation features to be supported. DMS threads, using ACRs to control database access, call UDS Control security validation procedures to perform part of the security access enforcement. UDS Control requires that the UDSC$PFGSDEF file for the application have an owner. The UDS Control enforcement mechanism uses UDSC$PFGSDEF file attributes for certain default values

174 Recognizing and Correcting Abnormal Conditions Corrective Action Use TeamQuest SIMAN to change the characteristics of the UDS Control UDSC$PFGSDEF file for the application group so that the file has an owner. For additional information about using TeamQuest SIMAN to change file characteristics, see the TeamQuest SIMAN Administration and End Use Reference Guide. After the UDSC$PFGSDEF file has an owner, you must reinitialize the UDS D-banks. You can reinitialize the banks by following one of these procedures: Idle the application group as described in 5.1. Next, perform an IRU short recovery for the application group as described in the Integrated Recovery Utility Operations Guide. When completed, UDS Control supports the DMS capability to use ACRs for database access security. Perform a UREP PROCESS CONFIGURATION... INSTALL command. For more information about the UREP INSTALL command, see the Repository for ClearPath OS 2200 Programming Reference Manual. When the new configuration has been activated, the DMS capability to use ACRs for database access security is supported Problem: Memory Limit Quota Exceeded An RDMS program utilizing the fast search feature requires a large amount of memory. Symptom The program aborts with the following error message. PROGRAM EXCEEDED MEMORY QUOTA QUOTA ABORT; ABORT ADDR: BDI: L,BDI: NAME SYSTEM-UNIQUE ID: QUOTA ABORT BIT D-BITS = BASE REGISTER CONTENTS FROM ABT (L,BDI FORMAT) Analysis The Exec configuration, for the run-id executing an RDMS program using the fast search feature, has insufficient memory. Corrective Action Configure your run-id with additional memory. For information on memory quotas, see the Exec System Software Administration Reference Manual. Contact your site analyst about site-specific requirements for increasing memory quotas

175 Recognizing and Correcting Abnormal Conditions Problem: System Cannot Acquire a D-Bank A program s request for a D-bank fails. Symptom The program receives a message like one of the following examples: APP n DCS RB An error occurred when creating an id-level level bank. Overall result status: yyy Result auxiliary status: CREATE$BANK packet status: xxx APP n DCS IN A request for space from type banks failed because space was not available in existing d-banks of that memory type, and the attempt to create another bank via CREATE$BANK failed. CREATE$BANK specific status is xxx CREATE$BANK ELMS status is yyy CREATE$BANK ELMS auxiliary status is where: n id-level type yyy xxx is an application group number is application or activity. is TCSD, LOCK, FPTE, or SCHM (schema). is an octal Exec message-id for the overall result status. is an octal Exec message-id for the specific bank request. Analysis It is expected that the system can always allocate another application-level bank; however, all application-level banks were allocated at the time of the program s failed bank request. The Exec returned ELMS statuses that identify the reason for the bank allocation failure. For descriptions of returned statuses, see the information in the System Services Programming Manual about return status codes for bank calls. DCS messages might contain an id-level of activity. In some situations, UDS might have attempted to allocate activity-level banks only after attempts to allocate application-level banks failed. Therefore, a DCS message with an id-level of activity can be a symptom that the system is unable to allocate any more applicationlevel banks

176 Recognizing and Correcting Abnormal Conditions Possible causes include the following: The Exec might have been built with inappropriate values for the NEWCON parameters APLDYNBDS and MAXBDI. Refer to information about the NEWCON statement and parameters in the Universal Data System Planning and Installation Overview for more information about the parameters. The pool of application-level banks was exhausted, even though no program or subsystem owns an unreasonable number of application-level banks. Another application-level bank was not available at the time of the request. One or more programs or subsystems own an unusually large number of application-level banks, resulting in an inability to allocate another application-level bank at the time of the request. An RDMS thread has an unusually large number of application-level RDMS scratch banks allocated for the thread s use. The large number of scratch banks allocated to the thread might indicate a memory leak. Corrective Action If APLDYNBDS and MAXBDI are not set to appropriate values, as suggested by the Universal Data System Planning and Installation Overview, rebuild and reinstall the Exec. If APLDYNBDS and MAXBDI are set to appropriate values, use command to identify the number of application-level banks held by all subsystems on the system. The SSINFO command is documented in the Linking Systems Subsystems Programming Guide. Consider the following actions: If the subsystem of the application group of the failing program does not own an unusually large number of banks, it is possible that one or more other subsystems own an unexpectedly large number of banks. Focus attention on any subsystem with a relatively large number of application-level banks. Deactivating a subsystem is one possible method of releasing its banks back to the system for use by other programs; however, take great care to understand the consequences of deactivating the offending subsystem before you use this method. If a UDSC or RDMS subsystem owns a relatively large number of application-level banks, then the UDSMON A screen can identify threads that have a large number of RDMS scratch banks. Offending threads can be terminated with an E keyin, which results in releasing RDMS scratch banks to the system or to the application group s free chain. Application-level banks released to the system are available for future bank requests by any program on the system. Application-level scratch banks released to the free chain are available to other RDMS threads executing within the application group. Alternatively, you can use the SUDS IL or II commands to deactivate a UDS Control protected fixed-gate subsystem; however, take great care to understand the consequences of deactivating the subsystem before you use this method

177 Recognizing and Correcting Abnormal Conditions If the subsystem of the application group of the failing program owns an unusually large number of banks, do the following: 1. Use the SUDS AE command to set an error for the DCS message number, to get a UDS dump if the problem happens again. The problem information, including dump, must be submitted to Unisys with a User Communication Form (UCF). 2. Use the UDSMON A screen to determine if any thread has an unusually large number of RDMS scratch banks allocated to the thread. Any thread with a large number of scratch banks could be a candidate for termination through an E keyin. The result of terminating the thread is that UDS Control releases the thread s scratch banks, either to the scratch bank pool or to the system most likely to the system, if the thread has an unusually large number of scratch banks. Note that a thread with an unusually large number of scratch banks could be doing a lot of legitimate work; on the other hand, the thread could be the victim of a UDS memory leak. In any event, it is important that you produce a UDS dump prior to terminating the thread, so that Unisys can determine if a memory leak is involved Problem: Inability to Acquire Space in a UDS D-Bank One or more program space requests from a UDS d-bank fails. Symptom A program receives a message like the following example: APP n DCS IN A request for space from type banks failed because space was not available in existing d-banks of that memory type, and another bank cannot be allocated because the UDS maximum number ( nnn ) of type banks have already been allocated. Notify your site administrator about the shortage of type banks. where: n type nnn is an application group number. is TCSD, LOCK, FPTE, or SCHM (schema). is a numeric value identifying the maximum possible number of banks for the type

178 Recognizing and Correcting Abnormal Conditions Analysis It is expected that a thread will be able to allocate space. However, space does not exist in an already allocated type bank at the time of the request. Another type bank could not be allocated because the maximum number of type banks is already allocated to the application group. The thread that asked for space rolls back because of subsequent UDS Control or DMS messages. However, DCS messages suggest problems with UDS memory management, or unexpected scaling restraints with respect to the particular application group. For example, a memory leak might be involved in UDS Control, RDMS, or DMS; or the maximum number of FPTE banks might not be adequate for the general cache specified in the configuration and the number of pages written to retention files. Corrective Action If the type of bank involved is not an FPTE bank, perform the Refresh and Recovery Procedure that follows. If the type of bank involved is an FPTE bank, and the UREP configuration attribute CACHE-WORDS can be increased to a higher value, consider increasing the value of CACHE-WORDS before you use the UREP PROCESS CONFIGURATION configuration-name INSTALL command. Even if you do not increase the CACHE-WORDS value, perform the Refresh and Recovery Procedure that follows. Refresh and Recovery Procedure Use the SUDS II command to abort the application group and refresh the control D-bank. Call IRU and run the short recovery procedure, as in the following appsrc ii ap application-group-number up short recover; act appl udssrc; end; Submit the problem information, including a dump, to Unisys through a User Communication Form (UCF)

179 Recognizing and Correcting Abnormal Conditions 6.3. UDS Is Accessible: Programs Seem Stalled This subsection discusses the second category of possible abnormal operating conditions. Assume that UDS programs appear to be stalled while either attempting to establish a UDS session or to execute an RDMS, DMS, or SFS data request. In all cases, assume that the program is not producing an error but that it cannot get control and that you must therefore intervene Problem: Programs Queued If requests from concurrently executing programs cannot be met, the system queues residual requests. The requests remain queued until the programs holding the required resources release them Programs Queued Trying to Start UDS Session This section discusses the need to configure additional thread banks if queuing occurs. Additional threads are configured by using UREP to increase the MAX-THREADS value, reprocessing the configuration, and then activating the new configuration. UDS Control dynamically acquires the new thread banks when activating a new UDS configuration. In the UDS configuration, you define the maximum number of concurrent programs allowed to execute in an application group. You run into a problem when the number of UDS programs attempting to establish a UDS session exceeds the maximum allowed. Symptom A UDS program appears to be stalled after attempting to execute its first data requests. Analysis Execute the UDS supervisor program (SUDS) to monitor the progress of active programs. Use the SUDS RC command to get a list of all active programs. If this number equals the maximum number of active programs allowed and you still have programs waiting to establish a UDS session, the system queues the establishment requests on an available active thread slot. Run-ids of not-yet-established programs do not appear in the list of active programs. For more information about SUDS, see Section 8. Corrective Action No corrective action is required. As programs terminate, the system allocates a slot and activates the queued threads. If this problem occurs frequently, you can modify your UDS configuration to increase the maximum number of concurrent threads allowed. To increase the number of threads, call the UREP processor (@DD), change the UREP configuration attribute MAX-THREADS to the desired limit for the installed configuration, and then use the UREP PROCESS CONFIGURATION configuration-name INSTALL command

180 Recognizing and Correcting Abnormal Conditions Programs Queued Within UDS Session An active UDS program might request a resource that cannot be granted because it is allocated to another program. Until the resource is freed, the request is queued. A program is most commonly queued because it cannot access a page to a file. Symptom A program appears stalled after establishing a UDS session. Analysis Execute SUDS using the RC command to list the status of all active programs. If any programs (threads) are queued, the resource type is listed along with the program status of QED (queued). Corrective Action This problem usually resolves itself. However, if the problem persists, look for patterns to see whether certain programs cause other programs to queue on a particular resource for long periods of time. Long queue periods usually happen to file-level resources when programs require exclusive use of the entire file. If this is the case, try to change the type of resource required, the type of resource lock required, or the program logic to reduce the time the resource is held. For example, change from file-level locks to page-access locks, or change from exclusive locks to shared locks. If you find that threads are queued indefinitely and the only way to move them is to terminate one of them at the console with an E keyin, you might have a more complex problem. A number of possible situations can cause of this problem: A UDS Control error might have left a test-and-set cell "set" by a thread, and a thread possibly the same one is hung in its attempt to set the cell. The remaining UDS threads remain queued against this thread. In this case, using E keyins from the system console to terminate the thread does not resolve the problem. Instead, you must use the SUDS II command to idle the application group (see 5.1). Before aborting, however, use the E keyin to terminate all UDS runs to ensure that the resulting UDS dump contains information about each thread to help analyze the problem. A run might have terminated abnormally, perhaps through an X keyin from the system console. An X keyin removes the thread from execution, without telling UDS that it is terminating, and might leave test-and-set cells "set" in UDS. You are left with the situation just described. Follow the same corrective action, using the SUDS II command. In this case, a UDS Control error did not occur but the situation can cause database corruption. Note: Do not use X keyins from the system console in a UDS environment

181 Recognizing and Correcting Abnormal Conditions A combination of the first two situations might have occurred, where the test-and-set cell left "set" is in the ADT bank (TSETs used by UDS products in all applications), not in data banks unique to a particular application. In this case, you might find queued threads in more than one UDS application group. Follow the same corrective action given for the first situation for all UDS application groups. The purpose of this action is to record the address where the various threads are hung and to idle all UDS applications in the system. When all UDS applications have been idled, perform the ADT bank reload process. In this instance, find the PRINT$ files for all UDS threads involved; information in those files might be useful in solving the problem. ADT prints warnings if a potential thread suspension is detected, both in the active PRINT$ file of the program and on the operator's console. The PRINT$ file for any threads that elicit this warning might also be useful in solving the error. Since the warning might have been issued by a thread that was not suspended, you might have to check the console log for a warning prior to the hang. The console warning message to look for is WARNING UDS APPLICATION HANGS MAY OCCUR. IF SO, IDLE ALL UDS APPLICATION GROUPS,.. (up to three additional lines may appear). CONTACT DEFAULT AG DATABASE ADMINISTRATOR WITH QUESTIONS. The thread might be queued in the encryption user routine (EUR). There is no easy way to determine conclusively whether the program is queued in the EUR, but if you suspect that it is and if you think that aborting the application group using the SUDS II command is too drastic a measure to take, then If the EUR is a basic mode routine, reload the EUR using the option to terminate all activities active within the bank. If the EUR is an extended mode routine, deactivate the subsystem to which the EUR belongs. An undetectable deadlock might have occurred between your UDS application and another system utility, such as the file control superstructure (FCSS). In this case, two UDS threads, while simultaneously holding or attempting to hold UDS and FCSS resources, become deadlocked. Each thread is queued for resources held by the other. The thread might be queued behind a thread participating in a global transaction that is in the prepared (ready) state. This problem resolves itself when the Transaction Manager notifies UDS Control of the final resolution (commit or rollback) for the thread

182 Recognizing and Correcting Abnormal Conditions Problem: Unable to Initialize Because of Encryption D-Bank Error In systems that use the RDMS database user encryption routine, UDS Control references the encryption D-bank when you initialize it. To activate the feature, you need to create an encryption routine, install the routine, and modify the UREP configuration. Symptom UDS Control could not access an application after initialization in a system that has RDMS encryption installed. Analysis The encryption routine BDI or encryption routine installation is incorrect. Corrective Action Specify the correct BDI in the UREP configuration. Perform another UREP configuration installation Problem: Unanswered System Console Messages (Unopened Audit Trail) When messages are outstanding on the system console, UDS processing is delayed until the operator responds. A common delay is caused by the user failing to manually open the audit trail file for the application group. Although you can initialize the Exec, perform the recovery bootstrap process, and run short recovery without opening the audit trail, you must open it for the application group. Symptom When attempting to establishing a UDS program, the system is unable to process the requests and the program stalls. Analysis If you are not at the system console, you can query the audit trail status of application group 3 by at 3 fs If the audit trail status indicates CLOSED (CL), ask the operator to check for outstanding system console messages pertaining to the audit trail file for the application group. The operator might find an outstanding message that requires opening of the audit trail file. Corrective Action If the system requires an audit trail, the operator must specify OPEN (OP)

183 Recognizing and Correcting Abnormal Conditions Problem: Unable to Reconfigure XTC Environment UDS Control software does not permit a new UDS configuration to be activated and displays the following messages: *Hosts defined in AG x that are not communicating with MHFS are (Exec MQF$ ER, RAS function with interhost, supplies no info for them): Host x (host-id index x), the xxx host defined in the DSR configuration. Host y (host-id index y), the xxx host defined in the DSR configuration. *See the chapter on abnormal conditions in the UDS Administration and Support Reference Manual for information on resolving the problem. *This AG/host will use the former configuration, leaving the switch to the new configuration pending until the condition is rectified. To prevent repeated warnings of this condition, use the UREP command PROCESS CONFIGURATION... DELETE to eliminate the pending configuration. Thread control prevents any application reconfiguration if you have not initialized one or more hosts defined in a UDS/DSR configuration with MHFS since the last initialization or recovery. The condition is detected by thread control. You must initialize all hosts with MHFS to activate a new UDS configuration. No information is available in at least two cases: A host in an XTC environment aborts. The operator performs an MH,IN or MH,RC keyin during a boot of another host in the configuration, and the host that aborted is not sufficiently rebooted to sign on with MHFS. An XTC environment might have an active DSR-defined UDS configuration that defines more hosts than exist in the hardware configuration. If you want to take responsibility for the condition of the database after a reconfiguration (for example, the aborted host has no steps that require database recovery), you can use the SUDS OS command to force a reconfiguration. You can perform the following app-name OS OD EX. allows you to reconfigure. displays the set value

184 Recognizing and Correcting Abnormal Conditions Problem: Programs Waiting for File Assignment Most files UDS assigns must be available immediately. If the file is not available (for example, it is assigned to another run or rolled out), UDS rolls back the requesting program with the exception of files ADT-FILE, SYS-FILE, and ROLLBACKnnnn. Whenever any of these files are assigned to UDS, the triggering request has not tied up any UDS resources; therefore, the program can wait until the file becomes available. Symptom A program attempting its first UDS request appears to be stalled. Analysis If you are not at the system console, query the status of application group 3 by ap 3 fs This gives you the application group state. The state is UP with no active program steps if the system is waiting for a file assignment by the system or if the audit trail file for the application group is CLOSED (CL). Check the audit trail at 3 fs If the audit trail status is OPEN (OP), determine whether a system file (such as the ADT backup file, the UDS system file, or a UDS retention file) is unavailable. file-name for each file. The status indicates whether the file is rolled out and also whether the file is assigned. The ADT backup and UDS system files might be assigned by another runstream, but not exclusively. If the ADT backup or UDS system file is assigned, assign the files with your demand runstream. If you cannot assign the files because they are exclusively assigned to another run, you have an assignment conflict and must determine where the files are assigned. UDS does not assign these files exclusively, so check whether your save-procedure runstream assigned the files. As noted earlier, you must use your own routines to determine which active jobs have the file assigned

185 Recognizing and Correcting Abnormal Conditions Caution Some UREP commands cause UDS to assign the ADT backup file exclusively to the ADT alternate file common bank (AFCB). If your run gets held while executing a UREP command for exclusive file release, free the ADT file from all runs so that the ADT AFCB can assign the file and allow your run to continue executing. Do not TIO against the run while it is waiting for the exclusive file assignment because that leaves a software lock (test-and-set cell) set in the ADT AFCB. Any subsequent runs attempting to access the application group hangs and has to wait until the lock is cleared. If you accidentally TIO, you must reload the ADT AFCB. If the ADT backup and UDS system files are not assigned exclusively, they are probably assigned to UDS. You can check the status of the retention files: file-name for each retention file. The status indicates whether the file is rolled out. No other runstream must have these files assigned. Your save procedures must not be backing these up. If the files are not marked as rolled out, look for other causes of the hang. Corrective Action If files ADT-FILE, SYS-FILE, or ROLLBACKn are rolled out, no corrective action is required. If your save procedures have the ADT backup file or UDS system file exclusively assigned, no action is required. When the save procedures free the files, the waiting programs can proceed Problem: Programs Externally Terminated An X keyin from the system console terminates a run without alerting the user. Do not use the X keyin from the system console to terminate an established UDS program because it improperly terminates flag-clearing activity, preventing other programs from proceeding. Symptom Most, if not all, active programs are halted after issuing data requests, and the programs cannot regain control

186 Recognizing and Correcting Abnormal Conditions Analysis Follow the directions in sections and above to determine if any programs are making progress or if all are waiting. Next, execute SUDS using the RC command to list the status of all active programs. Repeat this step several times, taking note of the sequence number (SEQ) and number of updates (UPDATE) displayed in the command output listing. If these numbers do not change and the threads affected are not queued (QED xx not present in STATUS field), the affected threads are probably held up because a UDS user program was terminated with an X keyin from the system console. Finally, check the system console log to see whether a UDS program was terminated with an X keyin. If so, UDS cannot activate the affected programs. The application group continues to deteriorate as more programs encounter the same control flags. Corrective Action Use the SUDS II command to abort the application group and refresh the control D-bank. Call IRU and run the short recovery procedure, as in the following udssrc ii ap application-group-number up short recover; act appl udssrc; end;

187 Recognizing and Correcting Abnormal Conditions 6.4. UDS Is Accessible: Database Seems Inconsistent This subsection discusses the third category of possible abnormal operating conditions. Assume that you already debugged your UDS programs and that you executed them against your production database files. Assume also that recovery procedures ran correctly and that they produced the desired results. Your programs update and retrieve data, but some of the programs might report unusual or inconsistent data. Inconsistencies and irregularities might result when database files are not synchronized, especially if you have related files (that is, if data in one file depends on data in other files). If you do not update these files from within the same step or if you restore one of these files but do not synchronize it with the corresponding updates from the others, the result is an inconsistent database Problem: Programs Reporting Questionable Data UDS provides control components to ensure consistent data. You must also verify that data is valid and consistent in your programs before storing them. If you lose data, or it appears inconsistent, consider the causes described in the following subsections Program Error: Invalid Program Input The program does not perform adequate consistency checking to prevent invalid input data from getting to the database. Symptom Abnormal program reporting results or query results. Analysis If the results were reported correctly at a previous point in time, find the first occurrence when the results appeared abnormal. Check whether any program changes were installed during the interval between normal and abnormal results. If there were none, check whether any data recovery procedures were used during the interval. Problems might have been encountered with the files or recovery procedures might have been used in response to a system failure. If you have not used recovery procedures on the data, check the program logic for errors resulting from inconsistent input. Corrective Action Correct program errors and put programs back into operation. Use the IRU selective recovery procedure to recover the affected files. For more information, see the Integrated Recovery Utility Operations Guide

188 Recognizing and Correcting Abnormal Conditions Recovery Procedural Errors Again, this assumes that you used all recovery procedures correctly. Nevertheless, if you recovered related files inconsistently, the database contains inconsistencies. For example, your database might be inconsistent if you stored related updates to multiple files at different times. For example, if one of the files experiences I/O errors caused by a bad spot on a disk, and you recover that file, but not the related files, your database is inconsistent. The problem might also be caused by using the wrong combination of backup dump files. Symptom Abnormal program reporting results or query results. Analysis Check previous program results to see when the abnormal conditions started to appear. Determine whether the program depends on data from multiple files. If the program depends on multiple files for reporting, determine whether recovery procedures were used during the interval when the results went from normal to abnormal. If the program uses multiple files and you used recovery procedures that included one or more of the files, determine whether the recovery procedures were used correctly. Corrective Action Compare your recovery procedure steps to those documented in the Integrated Recovery Utility Operations Guide. If necessary, change your selective recovery procedure and run it against the affected files

189 Recognizing and Correcting Abnormal Conditions Resolving RDMS Database File Inconsistencies One symptom of inconsistent relational database files is a response to the SQL DROP TABLE command indicating that the table is not defined; however, when you use the UREP CREATE TABLE command, the response indicates that the table is already defined. This means that the repository areas and the RDT$FILE do not match. To correct this situation, take down the areas and files you want to recover, reload the files from your most recent dump tape, and apply the updates from the audit trail. The following example uses information from the IRU dump history file to reload reload file uds$$src*urep$me$name, urep$a$types, urep$e$types, urep$r$types, urep$me, urep$me$id, urep$qen, urep$entname, urep$name$id, urep$ent, urep$ent$ord, urep$rela, urep$rel$ord, urep$ea, urep$ea$qen, urep$ea$desc, urep$ra, urep$ra$qen, urep$ra$desc, urep$acl, rdt$file, auth$file, stats$file, viewdep$file, dep$file, ecm$file, eeam$file, frdt$file, lob$sa$file, null$file, params$file, part$file, rdm$dropfile, routine$file, sch$file, trig$file, trigcol$file; act appl udssrc; recover file uds$$src*urep$me$name, urep$a$types, urep$e$types, urep$r$types, urep$me, urep$me$id, urep$qen, urep$entname, urep$name$id, urep$ent, urep$ent$ord, urep$rela, urep$rel$ord, urep$ea, urep$ea$qen, urep$ea$desc, urep$ra, urep$ra$qen, urep$ra$desc, urep$acl, rdt$file, auth$file, stats$file, viewdep$file, dep$file, ecm$file, eeam$file, frdt$file, lob$sa$file, null$file, params$file, part$file, rdm$dropfile, routine$file, sch$file, trig$file, trigcol$file; act; end; Bring down the areas and files you are recovering before reloading. If you have defined a GROUP for UDS system files, and that group does not include DMS system files, you can replace the commands in the previous example with the following command DOWN GROUP uds-system; RELOAD GROUP uds-system; RECOVER GROUP uds-system; UP GROUP uds-system; ACT APPL UDSSRC; END;

190 Recognizing and Correcting Abnormal Conditions 6.5. Programs Cannot Establish UDS Session The last category of abnormal operating conditions occurs when a program is attempting to establish a UDS session and gets an error message stating that the application group is aborting or that the system is attempting to recover the application group Problem: Incomplete Abort of Application Group When the system aborts an application group, the system produces a dump of UDS memory for diagnostic purposes. The system can make no further progress in servicing program data requests until you reinitialize it. Each program with an active step is terminated in error just as though the operator had performed an E keyin from the system console, with two exceptions: The operator must respond to any outstanding messages. If a demand program has an outstanding READ$ request, the program is not terminated until it receives the requested input. Meanwhile, all other activity waits. The application group cannot completely abort until the user transmits the next input or the program activity times out. Symptom When an application group aborts, most UDS programs terminate in error as if an E keyin, from the system console, had terminated each run. Inactive programs cannot establish a UDS session. If a program attempts to establish a session, the resulting message depends on whether you set up a REFRESH runstream in the SYM$ file for the application group. If your site does not have a REFRESH runstream and the program attempts to establish a session, a message indicates that the application group is down and that the REFRESH runstream contains an error. The system suspends execution if you attempt to run short recovery before the abort process is complete. When the abort process is complete, subsequent executions of short recovery terminate with messages indicating that short recovery is in progress. If you have a REFRESH runstream set up in the SYM$ file, a message indicates that the application group is down and short recovery is in progress. The first request, however, is placed in a suspended condition. The request is waiting for the abort process to complete before proceeding

191 Recognizing and Correcting Abnormal Conditions Analysis The system cannot accept requests until the application group aborts. The following symptoms might also help you determine the source of the problem: Use of the AP keyin to check the application group status indicates that the application group is in an UP condition but that no programs are active. An outstanding system console message notifies the operator that step control is attempting to abort the application group. The operator can respond with AGAIN (wait) or DOWN (disable the application group). Corrective Action Call the user (the run-id on the system console message indicates the user). Instruct the user to transmit to the program, which allows abort processing to complete. If you had previously responded with AGAIN, the application is put in an IRU PENDING state waiting for short recovery to complete database recovery. If you had previously responded with DOWN, you can now bring up the application group with the AP keyin. If jump key 7 is set, the system solicits you for recovery or initialization. Answer SUTIL to recover the queue items. Use the IRU short recovery procedure to complete database recovery and bring up the application group Problem: Application Group Recovery Failing You must set up your system so that it runs default recovery procedures if the system fails or the application group aborts. Your response to the default recovery procedures depend on the type of failure. For example, you can set jump key 7 for step control queue item recovery and use the REFRESH element for running short recovery; otherwise, you must manually perform the recovery procedures whenever the system fails or the application group aborts. To manually perform the recovery procedures, the system prompts the operator to specify the type of queue item recovery. Manually call IRU to run short recovery Savefile Lost or Destroyed Following a system failure, the system cannot recover the step control queue items if the periodic savefile for the application group is not available. Symptom During the autorecovery boot process, the system console receives a step control message indicating that the savefile is unavailable and that the application group is down

192 Recognizing and Correcting Abnormal Conditions Analysis A lost savefile because of disk failure usually causes the error condition. The Exec file recovery process cannot recover the savefile, and the file is marked as disabled by the hardware. Catalog the savefile as a word-addressable file; otherwise, you might get an I/O 022 error and not be able to access the file. If you specified cache disk in the device type configuration, use the S option (for Store) when you catalog the savefile. If you do not specify the S option, you might not be able to access the savefile. To check on the possible conditions, follow these steps: 1. From the Exec generation STEPCONTROL stream generation statements (SGS), find the name of the affected savefile. If the savefile is a duplex TIP file, find both file names. 2. Check the accompanying messages displayed on the system console to see whether an I/0 022 error occurred. 3. If no I/O 022 error occurred, check the status of the file by file-name, where file-name is the savefile defined for the application group. If the status reports the file is disabled, the savefile is lost. Corrective Action If you received an I/O 022 error or the file is lost, catalog a new savefile. If the savefile is a TIP file, write a runstream that catalogs the files and reserves and registers them with TIP (use the FREIPS utility), as in the following rel 300,ap3$svfile dreg TIP$*ap3$svfilel treg TIP$*ap3$svfilel1.,fix treg TIP$*ap3$svfilel2.,fix res

193 Recognizing and Correcting Abnormal Conditions Enable application group 3 using the following system console ap 3 up init Next, use the IRU medium recovery or long recovery procedure, whichever is appropriate. If message recovery is not required, use IRU medium recovery to recover the database to a consistent state and then use short recovery to bring up the application. Otherwise, use IRU long queue item recovery to recover the periodic savefile contents and then use short recovery to recover the messages and the database. For more information about IRU recovery procedures, see the Integrated Recovery Utility Operations Guide Audit Trail File Lost or Destroyed This is one of the most serious problems you can encounter while attempting to recover the database files for an application group following a system failure. If short recovery fails, use long recovery. To perform the IRU long recovery procedure, you need database file dumps and the audit trail file to recover the updates for the application group made to the point of failure. If the most current audit trail file is lost (for example, a disk failure created a hole in the log of database updates), you can recover only the updates that were made up to the end of the last valid audit trail. Using reliable tapes and duplex TIP files for mass storage audit makes losing the audit trail file unlikely. In any case, be careful not to inadvertently overwrite the current audit trail tape or delete the current audit trail mass storage file. If you make one of these errors, however, the only way to recover the database is to perform long recovery using the last available audit trail, in which case updates logged on the lost audit trail are not reflected in the database. Symptom The system cannot assign the audit trail file, or a fatal I/O error was encountered during IRU short recovery. Corrective Action Follow this procedure: 1. When short recovery fails, the system prompts the operator to specify the state of the application group (INIT, SUTIL, or DOWN). The operator must specify DOWN. 2. Call IRU and report on the ACI file to get the last couple of record report aci last 5; act appl udssrc; 3. Determine which database files you might have updated since the start time of the last audit trail. 4. Report the dump history of the files you are reloading to verify that they were dumped before the lost audit trail:

194 Recognizing and Correcting Abnormal Conditions report dump files x*y,b,e ; act appl udssrc; 5. Use the IRU long recovery procedure. Reload the files you know were updated since the start time of the previous audit trail. You must specify the audit trail file tape number or F-cycle of the previous audit trail on the IRU RECOVER command because the current audit trail is lost. If you are using IRU dynamic dumps, ensure that the steps that were active during the dump finished before the end of the audit trail specified on your RECOVER command. For more information, see the Integrated Recovery Utility Operations Guide. 6. Use the AP UP keyin from the system console and specify the application group name to enable the application group, as in the following example for application group ap 3 up init 7. Use the IRU short recovery procedure as in the following short recover; act appl udssrc; end; Note: This procedure recovers the database to a point in time prior to the failure. No messages are recovered and all updates made after this point in time to the failure point are lost. You must redo transactions/programs updated after this time Short Recovery Fails: Retention File Problem During short recovery, the system rolls back active steps if you specified quick-before-looks or rolls forward commit-in-progress steps if you specified deferred updates. The steps affected are the ones that had not terminated at the time of system failure. The rollback process reads quick-before-looks from the UDS retention files. If you get a fatal I/O error during the rollback process, you cannot successfully complete the short recovery process and the system disables the application group. Symptom When executing short recovery, you get UDS error messages indicating that a fatal I/O error occurred to a retention file. The message specifies the file name and I/O status and indicates that the database was not recovered. The system prompts the operator to enter the desired application group state: INIT, SUTIL, or DOWN. Corrective Action Follow this procedure: 1. The operator must specify DOWN. 2. Use IRU to bring down the retention files that gave the I/O DOWN FILE Q*F; ACT;

195 Recognizing and Correcting Abnormal Conditions 3. Enable the application group using the system console AP 3 UP keyin. When the system console solicits the type of step control recovery you want to perform, enter INIT. 4. If all active steps at the time of system failure were using the deferred update strategy, use the IRU medium recovery procedure. Alternatively, use selective recovery if you can localize the files that were active at the time of failure. If you cannot use medium or selective recovery, use long recovery. For more information, see the Integrated Recovery Utility Operations Guide. 5. Call IRU and run short recovery, even if you already ran a recovery procedure in the preceding step. 6. Correct the files that gave the I/O errors and bring them up with IRU Short Recovery Successful but Database File Problem Exists While using short recovery, if you get a fatal I/O database file error, the system disables the file and continues short recovery processing for all other files. Symptom You get a fatal I/O database file error during short recovery, and the system issues a warning. Analysis The UDS warning messages indicate the disabled file and accompanying I/O error. Corrective Action Use command to delete the database file, and then recatalog the file. Follow the selective recovery procedure discussed in the Integrated Recovery Utility Operations Guide

196 Recognizing and Correcting Abnormal Conditions

197 Section 7 Monitoring Performance and Diagnosing Problems The UDS Control trace facility (TRCCTL) lets you monitor performance and diagnose suspected problems as threads are executing in UDS. This facility has two parts: an interactive program called TRCCTL and a UDS Control component that reacts to TRCCTL commands. This section explains how to use the TRCCTL facility. UDS Control also provides performance monitoring through the TeamQuest Transaction Performance Auditing System (TeamQuest TPAS) with UDSC-TPAS Trace Control Functions Of the two trace control functions, monitoring performance and diagnosing problems, you probably have more need for the first, which you can use to gather statistics on performance. To monitor performance, you can use TRCCTL options to turn on the statisticsgathering component, and you can collect two types of information: Counters that give details on the execution path of one thread (local statistics) Counters that represent a current snapshot of global system information (global statistics) To diagnose problems, you can trace suspected errors in the execution path of a specific user program. TRCCTL options allow you to turn a trace on or off, to specify which components to trace, and to choose a trace level. TRCCTL writes the results to a trace file. You can process all or part of the trace file, and print or display the output for analysis

198 Monitoring Performance and Diagnosing Problems 7.2. Calling the Trace Control Program (TRCCTL) The trace control program, TRCCTL, is in an absolute file on the UDS Control release tape. To execute TRCCTL and display the options menu, enter uds$$src*abs$.trcctl If your system is configured with Security Option 3 Controlled Access Protection, you must have privileges to use the UTILITY UDS command before you can execute TRCCTL commands. Your user-id must also have the proper security attributes to access the UDS Control ABS$ file. If Security Option 3 is configured on your system, the security attributes of your user-id must match the security attributes of the UDS secure subsystem to enable TRCCTL to function. This is necessary because TRCCTL accesses the UDS Control subsystem to turn trace on and off. For more information about Security Option 3, see Section 9. For more information about setting up the necessary security attributes for your system, see the Repository for ClearPath OS 2200 Programming Reference Manual TRCCTL Options When the TRCCTL program starts, it displays four options: OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: TRCCTL can perform only one function at a time. If you select more than one option, press the XMIT key after choosing each option. While trace is active, you can update the components being traced as well as the level of trace. Setting a level of trace to 0 for any component turns off that component. The size of the trace file is important. If a trace produces too much data for the specified file size, the trace wraps around to the beginning of the trace file, overwriting the early part of the trace. The trace continues in this circular manner until you turn it off

199 Monitoring Performance and Diagnosing Problems Option 1 Option 1 turns on the trace, taking one of four paths: If TRCCTL does not know the name of the application group you want to trace, it solicits the name. If the application group you want to trace is not active, the TRCCTL program ends immediately and you must restart it. If the application group is active but TRCCTL does not know the name of the file in which trace is active, it solicits the name of the trace file and its size. TRCCTL then catalogs the trace file and assigns it. If the application group is active and TRCCTL knows the name of the file in which trace is active, it displays the name of the trace file and a list of the components that are turned on and their levels. TRCCTL now solicits the names of the components you want to trace. Component names are shown in Table 7 1. If you specify a UDS component (or ALL), you must also specify a trace level. Trace levels are described in Table 7 2. TRCCTL stops asking for component names when you transmit a blank line. The trace is then active and stays active until you enter option 2. If you need to increase the size of the trace file, specify option 2 first (if this is your first TRCCTL execution). If you do not specify option 2 first, TRCCTL does not solicit you for the new file name and size. Option 2 Option 2 ends the trace. To prevent you from accidentally turning off the trace of another user, TRCCTL displays the name of the active trace file. At this point, you can either turn off the active trace or return to the options menu, leaving the trace on. Option 3 Option 3 lets you process all or part of the trace file to an output file that you can print or display. First, TRCCTL solicits the name of the trace file. You can specify any trace file, as long as it is still cataloged on the system. Next, TRCCTL solicits the name of your output file. If this file is not already cataloged, TRCCTL catalogs and assigns it. Last, TRCCTL solicits any search constraints, which are described in Table 7 3. They determine how much of the trace file TRCCTL writes to the output file. For example, if you asked TRCCTL to trace four UDS components for option 1 but want only the trace information for the locking subsystem, you can specify this as a search constraint. In this case, the output file would contain only the trace information for the locking subsystem. Trace information for all components traced remains in the trace file. If TRCCTL is terminated abnormally (for example, T) while printing the UDS trace file, the run printing the trace must terminate (@FIN) or it must direct the output to the file you designated (@BRKPT output-file). Option 4 Option 4 terminates the program and exits TRCCTL

200 Monitoring Performance and Diagnosing Problems 7.4. Trace Components Table 7 1 lists the components you can trace through TRCCTL. Table 7 1. TRCCTL Trace Components Component ALL CAM DMR IMM IRU LINK LSS PCI QAD RDM RSA RSM SQL STAT TCL TCS TEST Definition All UDS components, statistics, and immediate I/O Cache manager Data Management Routine This is the DMS online management routine that accesses and updates the DMS database. See 7.9 DMR Trace for more information. Immediate (not an actual component). Specifies that every trace action during the trace causes an immediate I/O. This option is recommended when using the trace facility to locate a problem. When collecting statistics, however, using this component is not recommended because of the high processing overhead. Integrated Recovery Utility TCS table linking Locking subsystem SFS Queuing and deadlock detection Relational data manager Relational Syntax Analyzer (requires a trace level of 3 or greater) Data entries contain selected RSA debug information important for coordinating UDS trace information. Information in the trace file is primarily represented as octal and does not include any formatted output. See the Relational Database Server for Clear Path OS2200 SQL Programming Reference Manual ( ) for the DEBUG DUMP statements required to enable the inclusion of debug information in the UDS trace file. Relational storage manager Database modification SQL statements Statistics (requires a trace level of 1 or greater) STAT is not useful for tracing SFS threads because SFS does not currently accumulate statistics. Thread control Table control system Unisys test use only

201 Monitoring Performance and Diagnosing Problems If you select any of the UDS components (or ALL), TRCCTL solicits a trace level. The trace level and type of trace are closely related. Table 7 2 defines the trace-level values and indicates the relationship of each level to the trace type or types. To trace everything, select all components and specify the highest trace level. Table 7 2. UDS Trace Levels Level Type Result 0 None No trace 1 proc_e, proc_r Procedure entry and return statements 2 proc_e, plus stack contents 3 data, items passed by reference Level 1 trace plus a list of trace parameters passed on procedure entry and return Level 2 trace plus a list of data structures passed between procedures 4 stack1, print1 Level 3 trace plus a list of any programmer-defined level 4 information 5 stack2, print2 Level 4 trace plus a list of any programmer-defined level 5 information 6 stack3, print3 Level 5 trace plus a list of any programmer-defined level 6 information 7.5. Search Constraints Search constraints have four dimensions: time, thread, component, and type. You can specify search constraints for any or all of these dimensions. The output file contains the intersection of trace values that satisfy all search constraints you specify. For example, if you specify a certain time interval (TIME dimension) and the LSS component, the output file contains only LSS trace values generated during the specified time interval. Table 7 3 describes the search dimensions for TRCCTL option 3, print trace file. Table 7 3. TRCCTL Option 4 Search Dimensions Dimension TIME THREAD COMPONENT Description A real-time interval during the period the trace was active. Enter TIME as a range, with the earliest and latest values specified as yr/mo/da,hr:mn:sc. Use two digits for each field. The hr field is in military time (for example, specify 5:00 p.m. as 17:00). Original or generated run-id and number of threads. One or more UDS components, statistics, or ALL, in any combination

202 Monitoring Performance and Diagnosing Problems Table 7 3. TRCCTL Option 4 Search Dimensions Dimension LEVEL NONE Description Level of detail of trace packets to print (see Table 7 2). The types of trace packets placed in the trace file depend on the level of trace taken. Processes the entire file into the output file. TRCCTL displays your search dimensions on the screen after you enter them. If you want to change them, respond to the TRCCTL prompt. TRCCTL copies the trace file to the output file, subject to the restrictions of your search constraints. You can display or print the contents of the output file. Regardless of which trace values are written to the output file, the trace file contains all information that resulted from the trace. You can copy all or part of the trace file to any output file using TRCCTL option 3 as long as the trace file remains cataloged Trace Output Whenever trace is turned on, UDS Control calls the trace facility at appropriate times in the execution path. These calls depend on the settings for trace level and type of trace (for example, STATS). TRCCTL builds and buffers a packet of trace information for each call to the trace facility, and then writes the trace information to your trace file. You can use TRCCTL option 4 to process all or part of the trace file to an output file. You can print or display the contents of the output file. The trace file remains assigned to UDS, even after the application group is disabled. The system frees the file after it is printed. The first time you execute a trace, the system uses the default file UDSSRC*TRACEFILE instead of querying you for the trace file name. The contents of the trace file follow the general format shown in this example. A blank line separates each packet of data on the listing. Example TRCCTL generated the output in this example for a thread with the original run-id 5ABC and generated run-id 5ABCA on April 1, 2009 at seconds past 6:24 p.m. It was written on entry to the LSS component. The automatically generated title (unlck_file), the internal procedure name, identifies this as a file unlock. The output also displays six words of data in octal format. The starting address for these words was ABC /5ABCA 2009/04/01,18:24: proc_e LSS PROCEDURE : unlck_file

203 Monitoring Performance and Diagnosing Problems In the example Line 1 contains the following: original run-id/generated run-id yyyy/mm/dd,hh:mm:ss.mmm type component System Activity Identifier Line 2 is the title, a descriptive heading generated by the code that was traced. Lines 3 and 4 contain octal addresses and octal data words at those addresses TRCCTL Examples The examples in this subsection illustrate how to execute the TRCCTL program Example 1 This example shows how to turn on a trace of level 1 STAT, level 6 TCL, level 6 CAM, and level 1 IMM. In this example, lines that you enter begin uds$$src*abs$.trcctl BEGIN UDS Trace Control OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 1 The application name has not yet been set. Please enter APPLICATION GROUP NAME. udssrc Trace is active into file: UDSSRC*TRACEFILE No components are set to be traced. To set trace levels for various components, you will be prompted for their names: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL You will also be prompted for their level of tracing detail. Press XMIT to terminate the polling. Component name? stat Level of tracing detail? (0=Low to 6) 1 Component name? tcl

204 Monitoring Performance and Diagnosing Problems Level of tracing detail? (0=Low to 6) 6 Component name? cam Level of tracing detail? (0=Low to 6) 6 Component name? imm Level of tracing detail? (0=Low to 6) 6 Component name? UDS Trace has been turned on. OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 1 Trace is active into file: UDSSRC*TRACEFILE Component Level ========= ===== TCL 6 CAM 6 STAT 1 IMM 6 To set trace levels for various components, you will be prompted for their names: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL You will also be prompted for their level of tracing detail. Press XMIT to terminate the polling. Component name? UDS Trace has been turned on. OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop

205 Monitoring Performance and Diagnosing Problems Please choose a number: 4 END UDS Trace Control Producing raw trace. This is only one example of how to produce raw trace. You can produce raw trace with any program that accesses UDS UREP 12R2 (10/13/09 12:34:56) 10/13/09 12:34:56 exit 1 exit END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 0 )REMARKS. Turning off uds$$src*abs$.trcctl BEGIN UDS Trace Control OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 2 The application name has not yet been set. Please enter APPLICATION GROUP NAME. udssrc Trace is active into file: UDSSRC*TRACEFILE Terminate trace? (y/n) y UDS Trace has been turned off. OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 4 END UDS Trace Control Selectively processing and printing raw trace from preceding input, setting time, component, and level uds$$src*abs$.trcctl BEGIN UDS Trace Control OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop

206 Monitoring Performance and Diagnosing Problems Please choose a number: 3 Enter name of raw trace file: udssrc*tracefile Enter file name for printing trace into: traceprint Are there any SEARCH constraints? (y/xmit) y Are there any TIME constraints? (y/xmit) y Please enter search time bounds. EARLIEST search time, yr/mo/da,hr:mn:sc 09/10/08,10:33:00 Error in format, please try again. EARLIEST search time, yr/mo/da,hr:mn:sc 09/10/08,10:30:00 LATEST search time, yr/mo/da,hr:mn:sc 09/10/08,10:50:59 Do you want to print a limited set of THREADS? (y/xmit) Do you want only a limited set of COMPONENTS? (y/xmit) y Please enter component names from the following list: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL Press XMIT to terminate the polling. component name? stat component name? Do you want to limit the LEVEL of trace detail? (y/xmit) y Please enter the LEVEL number from the following list. 1 proc-e 2 proc-r 3 data 4 log 5 stack1 6 print1 7 stack2 8 print2 9 stack

207 Monitoring Performance and Diagnosing Problems 10 print3 Enter a ZERO to quit. Level number? 1 Level number? 4 Level number? 6 Level number? 0 Search constraints are: TIME: 09/10/08,10:30:00 TO 09/10/08,10:50:59 THREADS: None. COMPONENTS: STAT TYPES: proc-e log print1 Are these search constraints OK? (XMIT/n) Completed processing the file. OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 4 END UDS Trace Control The output from this trace, which you can now display or print from file TRACEPRINT, is as follows. Note that some triplicate fields are present (namely, In/Out/Latest Elapsed Time, In/Out/Latest Total SUPS, and In/Out/Latest Word Countn). The In fields contain the aggregate of the corresponding values taken by all commands in the thread while they were executing inside of UDS Control. The difference between the aggregate of the corresponding values over the entire duration of the thread and the value in the In field is stored in the Out field. The Out field, therefore, represents the aggregate for the corresponding field while the thread was executing outside of UDS Control. The latest, or "last," field contains the corresponding value for each field for the last command of the thread

208 Monitoring Performance and Diagnosing Problems Some threads pick up their values from the PCT. In some cases for MAPPER runs, the original run-id displays the generated run-id from the PCT and the generated run-id displays the input-id from traceprint. READ-ONLY MODE CASE UPPER ASSUMED ED 16R1E THU-10/08/09-11:42:13-(0,) EDIT p! Are there any SEARCH constraints? (y/xmit) *y Are there any TIME constraints? (y/xmit) *y Please enter search time bounds. EARLIEST search time, yr/mo/da,hr:mn:sc *09/10/08,10:33:00 Error in format, please try again. EARLIEST search time, yr/mo/da,hr:mn:sc *09/10/08,10:30:00 LATEST search time, yr/mo/da,hr:mn:sc *09/10/08,10:50:59 Do you want to print a limited set of THREADS? (y/xmit) * Do you want only a limited set of COMPONENTS? (y/<xmit>) *y Please enter component names from the following list: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL Press XMIT to terminate the polling. component name? *stat component name? * Do you want to limit the LEVEL of trace detail? (y/<xmit>) *y Please enter the LEVEL number from the following list. 1 proc-e 2 proc-r 3 data 4 log 5 stack1 6 print1 7 stack

209 Monitoring Performance and Diagnosing Problems 8 print2 9 stack3 10 print3 Enter a ZERO to quit. Level number? *1 Level number? *4 Level number? *6 Level number? *0 Search constraints are: TIME: 09/10/08,10:33:00 TO 09/10/08,10:50:59 THREADS: None. COMPONENTS: STAT TYPES: proc-e log print1 Are these search constraints OK? (<XMIT>/n) * reading from sector 5208 reading from sector 5216 reading from sector 5224 reading from sector 5232 reading from sector 5240 reading from sector 5248 reading from sector 0 reading from sector 8 reading from sector 16 reading from sector 24 reading from sector 32 reading from sector 40 reading from sector 5152 reading from sector 5160 reading from sector 5168 reading from sector UDS /5UDS 2009/10/08,10:42: log STAT global statistics active threads : 1 threads on queue : 0 files opened :

210 Monitoring Performance and Diagnosing Problems threads processed : 2 steps processed : 2 threads rolled back : 0 local deadlocks : 0 timeout deadlocks : 0 rlp deadlocks : 0 rlp presumed deadlocks : 0 threads queued : 0 data file ios requested : 201 data file ios performed : 58 retention file ios : 0 audit ios : 0 cdc audit ios : 0 lob audit ios : 0 temp tables ios requested : 0 temp tables ios performed : 0 rdms replication audit ios : 0 reading from sector 5184 reading from sector 5192 reading from sector UDS /5UDS 2009/10/08,10:42: log STAT thread local statistics UDSC Version :UD08 Generated Runid :5UDS Original Runid :5UDS Begin Date/Time : 10/ 8/ 9 10:41:15 End Date/Time : 10/ 8/ 9 10:42:10 Total SUPS : UDSC Commands Processed : 71 Thread Status : 8 # Of Thread Updates : 0 Number Of Commits : 0 Rollback Reason : 0 In Elapsed Time : Out Elapsed Time : 58 Latest Cmd Elapsed Time : 408 In I/O Requests : 6179 Out I/O Requests : 0 Latest Cmd I/O Requests : 42 In Total SUPS : Out Total SUPS : 167 Latest Cmd Total SUPS : 3091 In CB SUPS : 0 Out CB SUPS : 0 Latest Cmd CB SUPS : 0 In CPU Time : 1166 Out CPU Time : 134 Latest Cmd CPU Time : 9 In I/O Word Count1 : 0 Out I/O Word Count1 : 0 Latest Cmd I/O Word Count1 :

211 Monitoring Performance and Diagnosing Problems In I/O Word Count2 : 0 Out I/O Word Count2 : 0 Latest Cmd I/O Word Count2 : 0 In I/O Word Count3 : Out I/O Word Count3 : 0 Latest Cmd I/O Word Count3 : In I/O Word Count4 : 0 Out I/O Word Count4 : 0 Latest Cmd I/O Word Count4 : 0 In I/O Word Count5 : 0 Out I/O Word Count5 : 0 Latest Cmd I/O Word Count5 : 0 In I/O Word Count6 : 0 Out I/O Word Count6 : 0 Latest Cmd I/O Word Count6 : 0 In I/O Word Count7 : 0 Out I/O Word Count7 : 0 Latest Cmd I/O Word Count7 : 0 In I/O Word Count8 : 0 Out I/O Word Count8 : 0 Latest Cmd I/O Word Count8 : 0 In I/O Word Count9 : 0 Out I/O Word Count9 : 0 Latest Cmd I/O Word Count9 : 0 In I/O Word Count10 : 0 Out I/O Word Count10 : 0 Latest Cmd I/O Word Count10 : 0 In ERCC SUPS : Out ERCC SUPS : 33 Latest Cmd ERCC SUPS : 1 Program Type : 4 Latest LDM Id :TCLR Latest Command Code : 3074 Data File Read Requests : 201 Data File Write Requests : 0 Actual Data File Reads : 57 Actual Data File Writes : 0 Retention File Reads : 0 Retention File Writes : 0 Quick Looks : 0 Deferred Updates : 0 Audit After Looks : 0 Audit Before Looks : 0 Audit LOB Looks : 0 Temporary Table Read Requests : 0 Temporary Table Write Requests : 0 Actual Temporary Table Reads : 0 Actual Temporary Table Writes : 0 Precond Num Updates : 0 Precond After Page Requests : 0 Precond Load Page Requests : 0 User ID :5UDS

212 Monitoring Performance and Diagnosing Problems Step-ID (word 1) : (word 2) : Value buffer pointer : Value buf size/buf words used : 0 0 Other log info/(h1,s4,s5,s6) : Host ID index/ag number : 0 7 Terminal PID nbr : Program Name :DD Number of active PFRs : 0 Total number of PFRs : 0 Buffers in use for PFRs : 0 Number of active LFRs : 0 Total number of LFRs : 0 Buffers in use for LFRs : 0 RLP lock/broadcast requests : 0 Time On Queue : 0 Time On File Queue : 0 Time On Block Queue : 0 Time On Record Queue : 0 Time On Internal Table Queue : 0 Time On Udsc-D Memory Queue : 0 Time On Page Memory Queue : 0 Time On Dedicated Page Queue : 0 # of Times Queued for File : 0 # of Times Queued for Block : 0 # of Times Queued for Record : 0 # of Times Queued for Int Tbl : 0 # of Times Qued for Udsc-D Mem : 0 # of Times Qued for Page Mem : 0 # of Times Qued for Ded Pg Mem : 0 Last Cmd Time On File Que : 0 Last Cmd Time On Block Que : 0 Last Cmd Time On Rec Que : 0 Last Cmd Time On Int Tbl Que : 0 Last Cmd Time On Udsc-D Mem Q : 0 Last Cmd Time On Pg Mem Que : 0 Last Cmd Time On Ded Pg Que : 0 Last Cmd # File Que : 0 Last Cmd # Block Que : 0 Last Cmd # Record Que : 0 Last Cmd # Int Table Que : 0 Last Cmd # Udsc-D Mem Que : 0 Last Cmd # Pg Mem Que : 0 Last Cmd # Ded Page Que : 0 Locking Statistics : Note: UDSC-STATISTICS = ON must be set in the UDS configuration for UDSC to gather these locking statistics. MODE-VS-TYPE 6 BY 3 ARRAY: LOCK-MODE VS LOCK-TYPE FILE BLOCK RECORD RETRIEVAL UPDATE

213 Monitoring Performance and Diagnosing Problems PROTECTED RETRIEVAL PROTECTED UPDATE EXCLUSIVE RETRIEVAL EXCLUSIVE UPDATE MODE-VS-DUR 6 BY 5 ARRAY: LOCK-MODE VS LOCK-DURATION REQUEST COMMAND CUR-LDM STEP THREAD RETRIEVAL UPDATE PROTECTED RETRIEVAL PROTECTED UPDATE EXCLUSIVE RETRIEVAL EXCLUSIVE UPDATE DMR Command Code : 0 DMR Schema Name : DMR Subschema Name : DMR Area Name : DMR Record Name : DMR Imparts : 0 DMR Departs : 0 DMR Area Opens : 0 DMR Area Closes : 0 DMR Finds : 0 DMR Gets : 0 DMR Inserts : 0 DMR Removes : 0 DMR Deletes : 0 DMR Frees : 0 DMR Keeps : 0 DMR Modifies : 0 DMR Stores : 0 DMR Acquires : 0 DMR Logs : 0 DMR Ifs : 0 DMR Moves : 0 DMR Utilities : 0 DMR Qlps : 0 DMR E$ Error : 0 DMR R$ Error : 0 RDM CDC logs per thread : RDM CDC logs per thread : 0 RDM Table Tag/Vers/Lgth : RDM Cmd-Code/Unused : 19 0 RDM Ready count : 11 RDM Fetch-First count : 15 RDM Fetch-Next count : 6 RDM Fetch-Last count : 0 RDM Fetch-Prior count : 0 RDM Fetch-Curr count : 0 RDM Release count : 1 RDM Locate count :

214 Monitoring Performance and Diagnosing Problems RDM Define-Cursor count : 10 RDM Update count : 0 RDM Insert count : 0 RDM Delete count : 0 RDM Lock count : 0 RDM Unlock count : 0 RDM Use count : 0 RDM Define-Table count : 0 RDM Put Blob count : 0 RDM Drop-Table count : 0 RDM Drop-Cursor count : 10 RDM Redefine-Table count : 0 RDM Create-View count : 0 RDM Drop-View count : 0 RDM Define-Index count : 0 RDM Drop-Index count : 0 RDM Grant count : 0 RDM Revoke count : 0 RDM Select count : 15 RDM Load count : 0 RDM Unload count : 0 RDM Aggreg-Fetch count : 0 RDM Explain count : 0 RDM Gather-Stat count : 0 RDM Set Environment Variables : 1000 RDM Prepare count : 0 RDM Execute count : 0 RDM Exec-Immediate count : 0 RDM Level count : 0 RDM Fetch-Next-N count : 0 RDM Report count : 0 RDM Register-Index count : 0 RDM Define-Schema count : 0 RDM Drop-Schema count : 0 RDM Report-Table count : 0 RDM Reset-Table count : 0 RDM Erase-Table count : 0 RDM Drop-Routine count : 0 RDM Create-Trigger count : 0 RDM Signal count : 0 RDM Set-Statement count : 0 RDM Return-Statement count : 0 RDM Invoke-Routine count : 0 RDM Condition-Statement count : 0 RDM Else-Statement count : 0 RDM Create-Routine count : 0 RDM End-Routine count : 0 RDM Get-Parameters count : 0 RDM UREP-Process count : 0 RDM Syntax-Message count : 0 RDM Begin-Statement count : 0 RDM End-Statement count :

215 Monitoring Performance and Diagnosing Problems RDM Change-Partition-State cnt : 0 RDM Get Blob count : 0 RDM Get Description count : 0 RDM Audit Statement count : 0 RDM Fetch Absolute count : 0 RDM Fetch Relative count : 0 RDM Create Role count : 0 RDM Drop Role count : 0 RDM JDBC Execute Prepared cnt : 0 RDM First Precond Failure : 0 RDM Current Precond Failure : 0 RDM Num Preconditioning : 0 RDM Num Precondition Failures : 0 RDM Num Result Sets : 0 RDM Num Update Count : 0 RDM Num Replication Records : 0 RDM Flash index searches : 0 RDM Local index searches : 0 RDM Flash search failures : 0 RDM ABINIT bypasses : 0 RDM RSA fetch next shortcuts : 0 RDM Commands migrated : 0 RDM Sections migrated : 0 RDM Activity banks created : 0 RDM Temp Files Written : 0 RDM Internal Sorts : 1 RDM External Sorts : 0 RDM I18n Lib Calls : 0 RDM Groups For Group By : 0 RDM Pk Updates : 0 RDM Secondary Index Updates : 0 RDM Snapshots Taken : 1 RDM Single Fetches : 29 RDM Multi Fetches : 2 RDM Nested Loop Joins : 19 RDM Hash Joins : 0 RDM Merge Joins : 0 RDM Outer Joins : 0 RDM Trapeze Fetches : 0 RDM Brute Force Searches : 17 RDM Secondary Index Searches : 3 RDM Shadow Searches : 9 RDM Pk Equal Searches : 17 RDM Pk Range Searches : 21 RDM Subqueries : 0 RDM Number Triggers Executed : 0 RDM Number ESQL Cmds Reused : 0 RDM Number ESQL Cmds Recompile : 0 RDM Number Records Fetched : 24 RDM Number Records Updated : 0 RDM Number Records Inserted : 0 RDM Number Records Deleted :

216 Monitoring Performance and Diagnosing Problems RDM Number Records Loaded : 0 RDM Number Records Unloaded : 0 RDM Number Foreign Key Checks : 0 RDM Current Action : Completed processing the file. EOF:322 0: exit END ED. NO CORRECTIONS APPLIED Example 2 This example shows how to turn trace back on and print all or part of the trace file: 1. Specifying a trace for level 3 LSS, level 4 TCS, and level 1 uds$$src*abs$.trcctl BEGIN UDS Trace Control OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 1 Please enter APPLICATION GROUP NAME UDSSRC Fully qualified name of trace file? myqual*testtrace Number of tracks in the file? 500 To set trace levels for various components, you will be prompted for their names: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL You will also be prompted for their level of tracing detail. Press XMIT to terminate the polling. Component name? lss Level of tracing detail? (0=Low to 6) 3 Component name? tcs Level of tracing detail? (0=Low to 6)

217 Monitoring Performance and Diagnosing Problems Component name? imm Level of tracing detail? (0=Low to 6) 1 Component name? UDS Trace has been turned on. 2. Changing level of trace for TCS from 4 to 0 (no TCS tracing) OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 1 Please enter APPLICATION GROUP NAME UDSSRC Trace is active into file: UDSSRC*TESTFILE Component Level ========= ===== LSS 3 TCS 4 IMM 1 To set trace levels for various components, you will be prompted for their names: TCL, LSS, CAM, PCI, QAD, RSM, RDM, TCS, STAT, LINK, SQL, TEST, IRU, DMR, RSA, IMM, or ALL You will also be prompted for their level of tracing detail. Press XMIT to terminate the polling. Component name? tcs Level of tracing detail? (0=Low to 6) 0 Component name? UDS Trace has been turned on. 3. Exiting TRCCTL OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop

218 Monitoring Performance and Diagnosing Problems Please choose a number: 4 END UDS Trace Control 4. Producing raw trace This is only one example of how to produce raw trace. You can produce raw trace with any program that accesses UDS UREP 12R2 (09/10/08 12:34:56) 09/10/08 12:34:56 exit 1 exit END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 0 )REMARKS. This part writes the contents of the trace file to an output file. You can display or print the contents of the output file just as with any other file. The output file in this example is OUTTEST. If this file does not already exist, TRCCTL catalogs and assigns it under your project-id. 5. Turning off uds$$src*abs$.trcctl BEGIN UDS Trace Control OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 2 The application name has not yet been set. Please enter APPLICATION GROUP NAME. UDSSRC Trace is active into file: MYQUAL*TESTTRACE Terminate trace? (y/n) y UDS Trace has been turned off. 6. Processing raw trace from numbers 1 and 2 OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 3 Enter name of raw trace file: myqual*testtrace Enter file name for printing trace into: outtest

219 Monitoring Performance and Diagnosing Problems Are there any SEARCH constraints? (y/xmit) Found last valid raw trace block. Assuming end of file. Completed processing the file. 7. Exiting TRCCTL OPTIONS: 1 Turn on trace to create raw trace file. 2 Turn off trace. 3 Process and print raw trace file. 4 Stop. Please choose a number: 4 END UDS trace control 8. First part of trace output from number outtest. READ-ONLY MODE CASE UPPER ASSUMED ED 16R1E THU-09/10/08-12:34:56-(0,) EDIT 0: p! Are there any SEARCH constraints? (y/xmit) * Found last valid raw trace block. Assuming end of file. last sector read is 32 # parcels = 062 length = sequence = 040 p size = reading from sector UDS /5UDSC 2009/10/08,12:13: proc-e LSS PROCEDURE : lck Completed processing the file. EOF:170 0: exit END ED. NO CORRECTIONS APPLIED

220 Monitoring Performance and Diagnosing Problems 7.8. Meaning of RDMS Statistics This subsection describes the statistics displayed by RDMS, those starting with RDM. There are two types of RDMS statistics, statement counts and occurrence counts. Every time the given kind of statement is executed, the corresponding statement count is incremented by one. For example, when the SQL LOCK statement is executed, the RDM Lock count is incremented by one. There is a separate count for every SQL and RDMUTL statement. Occurrence counts collect information helpful for tuning performance. They can increment by more than one per statement. For example, a SQL UPDATE statement might cause zero or more records to be updated; therefore, the occurrence count RDM Number Records Updated is incremented by zero or more to reflect the actual number of records updated. The RDMS counts are only updated for statements that return the OK or no-find status. If the statement returns an error, the corresponding statement count is not updated, nor are any of the occurrence counts updated. Note: The STAT trace is only written at END THREAD. It therefore does not appear for TIP multiple INITAL transactions until the transaction is terminated. Cmd_code is the internal number of the last RDMS statement executed before the STAT trace was written. It is therefore meaningful only to RDMS development and support personnel. Table 7 4 lists the RDMS statement count statistics. Note: In the table, RDM is omitted from the names. Table 7 4. RDMS Statement Count Statistics Statement Count Abbreviation Number of... Aggreg-Fetch count Agg Fet Aggregate fetch calls from RSA to RDMS. Aggregate fetch is used internally by the IPFSQL interface when the first call to SELECT did not return all records that need to be displayed. Audit statement count Repl Aud Explicit user audits performed using the AUDIT statement. Begin-Statement count BeginStm BEGIN code block statements. Change-Partition-State count Condition-Statement count Chg Part CondStmt ATTACH, DETACH, or HIDE PARTITION RDMUTL statements. IF statements executed by a stored procedure, function, or trigger

221 Monitoring Performance and Diagnosing Problems Table 7 4. RDMS Statement Count Statistics Statement Count Abbreviation Number of... Create-Role count Cre Role CREATE ROLE statements. Create-Routine count Cre Rout CREATE PROCEDURE or FUNCTION statements. Create-Trigger count Cre Trig CREATE TRIGGER statements. Create-View count Cre View CREATE VIEW statements. Define-Cursor count Decl Cur DECLARE or DEFINE CURSOR statements. Define-Index count CreIndex CREATE INDEX statements. Define-Schema count Cre Sch CREATE SCHEMA statements. Define-Table count Cre Tbl CREATE or DEFINE TABLE statements Delete count Delete DELETE statements. Drop-Cursor count Drop Cur DROP CURSOR statements. Note: DROP CURSOR is not allowed from ESQL, so from ESQL, CLOSE is effectively a DROP. Drop-Index count DropIndx DROP INDEX statements. Drop-Role count DropRole DROP ROLE statements. Drop-Routine count DropRout DROP PROCEDURE or FUNCTION statements. Drop-Schema count Drop Sch DROP SCHEMA statements. Drop-Table count Drop Tbl DROP TABLE statements Drop-View count DropView DROP VIEW statements. Else-Statement count Else ELSE statements executed by a stored procedure, function, or trigger. End-Routine count End Rout END statements executed by a stored procedure, function, or trigger. End-Statement count End Stmt END code block statements. Erase-Table count Statement not implemented. Exec-Immediate count Exec Imm Dynamic ESQL EXECUTE IMMEDIATE statements. Execute count Execute Dynamic ESQL EXECUTE statements. Each prepared statement is generally executed multiple times. Explain count Explains EXPLAIN statements. Fetch-Absolute count Fet Abs FETCH ABSOLUTE n statements. Fetch-Curr count Fet Cur FETCH CURRENT statements

222 Monitoring Performance and Diagnosing Problems Table 7 4. RDMS Statement Count Statistics Statement Count Abbreviation Number of... Fetch-First count Fet 1st FETCH FIRST statements. Fetch-Last count Fet Last FETCH LAST statements. Fetch-Next count Fet Next FETCH NEXT statements. Fetch-Next-N count Fet NxtN STATIC ESQL FETCH NEXT N statements. FETCH NEXT n improves performance when multiple records are returned. Fetch-Prior count Fet Pri FETCH PRIOR statements. Fetch-Relative count Fet Rel FETCH RELATIVE n statements. Gather-Stat count RunStats RDMUTL RUN STATISTICS statements. Get Blob count Get LOB GET BLOB calls to RDMS. GET BLOB is used by ODBC to stream a BLOB back to the client. Get description count Get Desc Times the information needed by a GET DESCRIPTION was not available as a byproduct of a previous statement, so that the GET DESCRIPTION statement was sent to the RDMS component. Get-Parameters count GetParam GET PARAMETERS statements. Grant count Grant GRANT statements. Insert count Insert INSERT statements. Invoke-Routine count CallProc CALLs to a stored procedure or function. Level count Level LEVEL RDMS statements. Load count Load RDMUTL LOAD statements. Locate count Locate LOCATE cursor statements. Lock count Lock LOCK table statements. Prepare count Prepare Dynamic ESQL PREPARE statements. Put blob count Put LOB Streaming PUT BLOB statements. Each PUT BLOB is a piece of the BLOB. Ready count Open Number of OPEN CURSOR or READY CURSOR statements. Redefine-Table count AlterTbl ALTER TABLE statements. Register-Index count RegIndex LINC FASTPATH REGISTER INDEX statements

223 Monitoring Performance and Diagnosing Problems Table 7 4. RDMS Statement Count Statistics Statement Count Abbreviation Number of... Release count Close CLOSE or RELEASE CURSOR statements. Report count Report RDMUTL REPORT PAGE USAGE statements. Report-Table count Rep Load RDMUTL REPORT LOAD STATUS statements. Reset-Table count Reset RDMUTL RESET LOAD STATUS statements. Return-Statement count Return RETURN statements issued by a stored procedure, function, or trigger. Revoke count Revoke REVOKE statements. Select count Select SELECT statements. Set-Stat count Set Flag Statements that set flags within RDMS. SET STATISTICS, and SET AUXINFO are examples. Set-Statement count Set Var SET variable statements issued by a stored procedure, function, or trigger. Signal count Signal SIGNAL statements. Usage of SIGNAL forces stored procedures, functions, and triggers to terminate in error. Syntax-Message count SyntaxE Syntax errors passed by RSA to RDMS for printing during the creation of a stored procedure, function, or trigger. Unload count Unload UNLOAD statements. Unlock count Unlock UNLOCK table statements. Update count Update UPDATE statements. UREP-Process count Process Times UREP to perform processing related to owned schemas. Use count Use USE DEFAULT QUALIFIER or VERSION statements. Table 7 5 lists the RDMS occurrence count statistics. Note: In the table, RDM is omitted from the names

224 Monitoring Performance and Diagnosing Problems Table 7 5. RDMS Occurrence Count Statistics Occurrence count Abbreviation Number of... ABINIT bypasses AbByPass Statements that bypassed ABINIT. If this count is zero for STATIC ESQL programs, check whether there were LOCK statements. If not, the program would probably benefit from adding LOCK table IN UPDATE MODE. Activity banks created Brute Force Searches Commands migrated Current preconditioning failure ActBanks Brute Cmd Mig Pre Cur Activity level banks RDMS created. Allocation of activity or program level banks causes TIP sticking to be lost. RDMS allocates activity level banks for HASH join. Times RSM is called to perform a brute-force search. A brute-force search might indicate a poorly written query or the need to create another index. Commands RDMS has converted to a new format. This count identifies dynamic ESQL programs that would benefit from a recompile. The value of the reason for the current preconditioning failure. See the Relational Database Server for ClearPath OS 2200 Administration Guide for more information. Execute Prepared Exec Prep Incremented during the execution of a JDBC execute prepared and execute declared call for INSERT, UPDATE, DELETE, and DECLARE CURSOR. External Sorts EsortCal Calls RDMS has made to ESORT. Indicates that a sort of a large number of records is being performed. ESORT might do I/O in order the process the sort. First preconditioning failure Flash index searches PreFirst Flashed The value of the reason for the first preconditioning failure. See the Relational Database Server for ClearPath OS 2200 Administration Guide for more information on dynamic preconditioning. Times RSM is called to locate a record using a flash index. This is a preferred secondary index access method. Flash search failures BadFlash Times the primary key page indicated by the flash index was not valid. If this occurs often, consider dropping the FLASH index

225 Monitoring Performance and Diagnosing Problems Table 7 5. RDMS Occurrence Count Statistics Occurrence count Abbreviation Number of... Groups For Group By Groups Groups built for GROUP BY. A large number of groups causes I/O. Hash Joins Hash Jn Hash joins. Hash joins are used only where there are two brute-force searches. This indicates a long-running query. A query can do at most one hash join. This count is therefore the number of queries doing a hash join. I18n Lib Calls I18NCall Calls to the I18N library. Many I18N library calls are quite expensive. A nonzero number indicates Java is passing Unicode or that I18NLIB built-in functions are being used. Internal Sorts Int Sort Calls to the RDMS internal sort procedure. If all the records to be sorted are in the buffer, RDMS performs an internal sort. If they do not all fit in the buffer, RDMS calls ESORT to perform the sorting. Local index searches LocalIdx Times RSM is called to locate a record using a local index. Merge Joins Merge Jn Joins that are merge joins. Multi Fetches MultiFet Records internally fetched by the RDMS multi-fetch algorithm. A large difference between this value and the actual number of records returned to the user indicates a misuse of multi-fetch, unless the returned records are some sort of aggregation (for example, GROUP BY, DISTINCT). Nested Loop Joins NestedJn Nested loop joins. For example, the following always has a value of 1, no matter how many records are returned: SELECT * from t1, t2 WHERE t1.pk=1 and t2.si = t1.nk Num Preconditioning Num Precondition Failures Num Replication Records Precond Pre Fail Repl Rec Times this thread attempted to use preconditioning. Times this thread attempted to use preconditioning but failed. Replication records written to the audit trail. Num Result Sets SP RSet Result sets returned from RDMS stored procedures. This is nonzero only after the user submits the command SET RESULT SET ON; (typically generated by JDBC)

226 Monitoring Performance and Diagnosing Problems Table 7 5. RDMS Occurrence Count Statistics Occurrence count Abbreviation Number of... Num Update Counts SP UpCnt Generated result set tuples for each of the INSERT, UPDATE, and DELETE commands in a stored procedure. This is nonzero only after the user submits the commands SET RESULT SET ON; and SET RESULT SET UPDATE COUNT ON; (typically generated by JDBC). Number ESQL Cmds Recompile Number ESQL Cmds Reused Number Foreign Key Checks Number Records Deleted Number Records Fetched Number Records Inserted Number Records Loaded Number Records Unloaded Number Records Updated Number Triggers Executed Recomp Reused FkeyChk Deleted Fetched Inserted Loaded Unloaded Updated Trigger Static ESQL statements that were auto-recompiled. Use of auto-recompile indicates that the table definition changed between the compile of the UCS COBOL or or UCS C program and this execution. Static ESQL statements RDMS executed using previously saved recompiled sections. Times RDMS made a foreign key owner or member check. Each check represents a search of the owner or member table. Records deleted. Records returned by RDMS to the application program. Records inserted. Records loaded using the RDMUTL LOAD statement. Records unloaded using the UNLOAD statement. Records updated. Times a trigger fired. Outer Joins Outer Jn Outer joins. Pk Equal Searches Pk Equal Times RSM is called to locate a record using the entire primary key, specified with equality. The LIST SEARCH KEY feature increments this field for every call to RSM. Pk Range Searches Pk Range Times RSM is called to locate a record using a range of the primary key

227 Monitoring Performance and Diagnosing Problems Table 7 5. RDMS Occurrence Count Statistics Occurrence count Abbreviation Number of... Pk Updates PKUpdate Records for which the primary key was updated. When a primary key value is updated, RDMS internally does a DELETE followed by an INSERT. A large number in a single statement causes I/O (reflected in no_temp_file_writes). RSA fetch next shortcuts Secondary Index Searches Secondary Index Updates FetShort Indexed SIUpdate FETCH NEXT statements RSA did not parse because the FETCH NEXT shortcut was used. Times RSM is called to locate a record using the secondary index, where the record must be returned from the primary key B-tree. This access method is more expensive than a primary key search or shadow table search. Secondary index records updated. When a secondary index record is updated, RSM internally does a DELETE followed by an INSERT. Sections migrated Sec Mig Sections RDMS has converted to a new format. This count identifies STATIC ESQL programs that would benefit from a recompile. Shadow Searches Shadow Times RSM is called to locate a record using the secondary index, where the record can be returned directly from the secondary index B-tree. This is the best access method. Single Fetches SngleFet Records internally fetched by the RDMS fetch algorithm (not multi-fetch). This is the number of records fetched one at a time. This is used when entire the primary key is specified with equality, for scrollable cursors, and so on. Snapshots Taken SnapShot Statements that caused RDMS to take a snapshot. Large snapshots cause I/O (reflected in no_temp_file_writes). Subqueries Subquery Times the RDMS subquery code was invoked. Subqueries are quite expensive. They can often be rewritten more efficiently as a join

228 Monitoring Performance and Diagnosing Problems Table 7 5. RDMS Occurrence Count Statistics Occurrence count Abbreviation Number of... Temp Files Written TmpFilWr Writes RDMS did to temporary files. This count identifies RDMS as the origin of I/O. RDMS writes to temporary files when taking a snapshot. Trapeze Fetches Trapeze Tables searched using the trapeze fetch DMR Trace Table 7 6 lists the items printed in the trace file when TRACE is turned on for the DMR component. Table 7 6. Trace File Items for DMR Trace Command Trace level Trace type Item Printed in Trace File IMPART 1 proc_e Command name 2 proc_e Level 1 trace with Request Packet 4 stack1 Level 2 trace with internal table information All other DML commands 1 proc_e Command name 2 proc_e Level 1 trace with Request Packet Exit from DMR 1 proc_r Exit label 2 proc_r Level 1 trace with DMCA 4 print1 Level 2 trace with internal run unit information Thread Control commands COMMIT, OMIT, and END THREAD 1 proc_e Command name Note: DEPART cannot always be traced from the DMR. Sometimes only UDSC code can be executed on DEPART

229 Section 8 Monitoring and Analyzing UDS Control SUDS is a supervisory program that allows you to interactively monitor and analyze UDS Control. SUDS permits you to examine schemas, check parts of the UDS Control D-bank, and view the status of active threads. TeamQuest TPAS allows you to monitor transaction performance. TeamQuest OSAM is an online system activity monitoring system. These three programs are described in this section Executing SUDS The SUDS program executes in either demand or batch mode. In demand mode, SUDS takes input from the READ$ file and directs output to the PRINT$ file. In batch mode, SUDS communicates through the system console using COM$. SUDS can also be called as a processor. You can specify the application group name on the processor call line. If your system has Security Option 3 configured, you must have privileges to use the UTILITY UDS command before you can execute SUDS commands. To do this, your user-id must be listed as part of the UTILITY-USERID attribute in the UREP configuration for UDS Control. This list specifies which user-ids can access the UDS Control utility interface. If your user-id does not appear in this list, any attempt to use SUDS commands causes a security violation, and a log entry appears in the system log file. The security attributes of the UDS interface security file must allow your user-id to have UDS Control command privileges. This file is cataloged as private and owned by the user-id of the administrator who installed UDS Control. This administrator must change the security on this file to give other users UDS command privileges. For additional information on setting security on any file, see the Security Administration for ClearPath OS 2200 Help. Your user-id must also have the proper security attributes to access the UDS Control ABS$ file. If Security Option 3 is configured on your system, the security attributes of your user-id must match the security attributes of the UDS secure subsystem to allow this feature to function. This is necessary because SUDS accesses the UDS common banks for most of the commands. See the Repository for ClearPath OS 2200 Programming Reference Manual for more information about setting up the necessary security attributes for your system

230 Monitoring and Analyzing UDS Control When SUDS is executed with Security Option 3 configured, it solicits the 6-character application group name, which cannot be an alias. If you specify the application name you must have: UTILITY UDS command privilege in UDS Control. Exec security attributes to enter the UDS subsystem for the application. Your clearance level and compartment set must match those of the application in the UDS subsystem. You must not have trusted privileges. When you call SUDS as a processor, you can supply the 6-character application group name on the call line. If you do not supply this name, SUDS waits for the next transmit. The subsequent transmit might contain the application group name or be blank. If it is blank, SUDS solicits the application group name. If you enter an invalid application group name, SUDS returns an error message and requests the application group name again. If the UDS Control D-bank for the application group is empty, SUDS responds with a message that the application group is not active. You can use the following SUDS commands with an uninitialized application group: DA DB EX FF HE RS UM Delete application group Display UDS Control D-bank buffer space Exit Free file Help Change Record Lock Processor [RLP] scan times for ADT/IRU Display count of discarded UDS broadcast messages You must have write access to the file UDS$$SRC*SECURE-FILE to use the DA command. All other SUDS commands produce an APPLICATION NOT ACTIVE message until the UDS Control D-bank for the application group is initialized. If the application group is active, you are ready to enter SUDS commands. In demand mode, the INPUT FUNCTION message solicits a 2-character SUDS command. In batch mode, SUDS waits after an ER II$ for the operator to enter a SUDS command in II SUDS xx format, where xx is a 2-character SUDS command used for demand mode

231 Monitoring and Analyzing UDS Control 8.2. SUDS Options Three options are available on the SUDS call: D E Use the D option to cause a batch execution of SUDS to perform like a demand execution in terms of input and output. Instead of communicating through the system console, SUDS takes input from the READ$ file (the batch runstream) and directs output to the PRINT$ file. Use the E option whenever you want a batch or demand execution of SUDS to print (that is, echo) the input. R Use the R option to raise the priority level for the run to real time (level 35). The run stays at this level until it exits SUDS. The R option is ideal for situations where a high volume of real-time runs could either prevent SUDS from processing commands or cause SUDS to process commands too slowly Demand and Batch Examples You have the option of calling SUDS as a processor. The following subsections offer examples of different scenarios for calling or executing SUDS in demand and batch modes Demand Mode Examples The following scenarios describe what occurs for each type of call in demand: An invalid application name simply displays the message INVALID APPLICATION NAME and prompts the user for the application name again. Example uds$$src*abs$.suds (transmit blank line) INPUT APPLICATION NAME (6 CHARS) udssrc INPUT FUNCTION ex EXITING SUDS Example uds$$src*abs$.suds udssrc INPUT FUNCTION ex EXITING SUDS

232 Monitoring and Analyzing UDS Control Example INPUT APPLICATION NAME (6 CHARS) udssrc INPUT FUNCTION ex EXITING SUDS Example udssrc INPUT FUNCTION ex EXITING SUDS Example 5: Demand uds$$src*abs$.suds udssrc rc print$ Batch Mode Examples For batch mode, prompts for input are displayed on the system console rather than on the user's terminal. The application group name can be supplied on the call line in batch mode, when SUDS is called as a processor. An invalid application name displays the message INVALID APPLICATION NAME and prompts the system console operator to enter another valid application name. Once the application name is entered, the user communicates with SUDS through II keyins. The following examples illustrate scenarios for batch runs. Example 1 Batch program INPUT APPLICATION NAME (6 CHARS) 0 udssrc run-id*udssrc APPLICATION READY FOR II KEYINS ii run-id ex (Keyed in from the operator console) run-id*exiting SUDS

233 Monitoring and Analyzing UDS Control Example 2 In this example, the application name is passed on the processor call line. Batch program udssrc System console input/output: run-id*udssrc APPLICATION READY FOR II KEYINS ii run-id ex (Enter any SUDS command here) run-id*exiting SUDS Example 3 Batch program uds$$src*abs$.suds System console input/output: 0-run-id*INPUT APPLICATION NAME (6 CHARS) 0 udssrc run-id*udssrc APPLICATION READY FOR II KEYINS ii run-id ex (Enter any SUDS command here) run-id*exiting SUDS Example 4: Batch Runstream In this example, all input comes from the batch runstream rather than the system console. Batch program uds$$src*abs$.suds udssrc rc

234 Monitoring and Analyzing UDS Control 8.4. SUDS Commands Table 8 1 lists and briefly describes SUDS commands. The subsections that follow cover SUDS commands in more detail and include examples. Table 8 1. SUDS Commands Command AE AM AR CF CS DA DB DC DE DL DM DP EX FF HE HM I I IL LD LS LU LV MB MT Result Places an error code in the error dump table Adds a message to the TIP-suppressed message table Displays or clears all entries in the RDMS Automatic Recompile Table Temporarily changes a UDS SERVICE run configuration parameter Sets the check schema flag for use by the DMR Deletes application group entry in application definition table (ADT) Dumps specific portions of the UDS D-bank Changes or displays the Data Capture state for a schema Displays the contents of the error dump table Displays maximum lock values Displays all messages in the TIP-suppressed message table Dumps all UDS D-banks to one or more dump files Exits SUDS program. Frees a file from the UDS domain. Lists all other SUDS commands for easy reference. Changes or displays the hardware/performance monitoring mode Disables the application group (sets the application group status to RCV, IRU:PND, or DN, depending on the TIP session control parameter in the Exec configuration) and dumps UDS Control D-banks Refreshes an idle UDS without an abort or UDS dump. Lists dedicated files Lists schemas in use by the DMR Lists subschemas in use by the DMR Displays UDS Control level Modifies the maximum number of block or record locks that can be held by a batch or demand program before the thread is rolled back Modifies the maximum number of block or record locks that can be held by a transaction program before the thread is rolled back

235 Monitoring and Analyzing UDS Control Table 8 1. SUDS Commands Command OC OD OS RC RE RL RM RS RU SA SC UM Result Clears the Reconfigure Anyway flag in the UDS Control D-bank Displays the setting of the Reconfigure Anyway flag Sets the Reconfigure Anyway flag in the UDS Control D-bank Lists the status of all threads in active use Removes an error code from the error dump table Lists active, prepared, and committed steps for the application group Removes a message from the TIP-suppressed message table. Changes RLP-DEADLOCK-NUMBER-SCANS and RLP-DEADLOCK-SCAN- TIME for the application definition table (ADT) and IRU Record Lock Processor (RLP) locks Same as RC: Lists the status of all threads in active use Sets the schema abort flag for the specified schema Clears the schema abort flag for the specified schema (and sets the schema clear flag) Displays the count of UDS broadcast messages that were discarded To execute a SUDS command from demand mode, enter the two letters as in the following example: INPUT FUNCTION ae From batch mode, enter II SUDS and the command: ii suds ae Add Error Code (AE) The AE command adds an error code to the error dump table. When an error occurs, the error dump table is checked to see whether that error is in the table. If it is, all UDS Control D-banks are dumped to a dump file. Use the AE command for messages issued by the UDS Control error message handler or by DMS. To determine whether you can use the AE command for a particular message, check the format of the message. You can use the AE command if the message has this format: APP application-group-number component-id message-type message-number message

236 Monitoring and Analyzing UDS Control You can also use the AE command for DMS external (DEX) and rollback (DRB) errors, except for errors that result from the IMPART command. The following example illustrates a message issued by UDS Control for the relational data manager (RDM) component: APP 3 RDM EX 5020 No find or end of cursor SUDS solicits the error-id (CCC) and the error number (NNNNN). The error-id must be three characters long and must be in the list of possible error-ids displayed by the DE command. The decimal number can be up to five digits. Use a slash between the error-id and error number. The following error-ids are associated with the products indicated: Error-id Product DCS DEX DRB PCS RDM RSM TCS UDS Control DMS DMS SFS RDMS RDMS UDS Control Example 1 Add DCS error number (decimal) to the error dump table: ae POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-ID/ERROR-NUMBER AS CCC/NNNNN dcs/59000 Example 2 Add DMS external error 133 and rollback error 30 to the error dump table: ae POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-ID/ERROR-NUMBER AS CCCNNNNN dex/133 INPUT FUNCTION ae POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-ID/ERROR-NUMBER AS CCC/NNNNN drb/

237 Monitoring and Analyzing UDS Control Add Message (AM) The AM command puts the component and error number into the TIP-suppressed message table so these error messages are not printed during TIP program execution. This prevents unnecessary print from being generated for common acceptable errors. The following error-ids are associated with the products indicated: Error-id Product DCS DEX DRB PCS RDM RSM TCS UDS Control DMS DMS SFS RDMS RDMS UDS Control Example This example illustrates how to add a message for error DCS 59520: am POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-ID/ERROR NUMBER AS CCC/NNNNN dcs/

238 Monitoring and Analyzing UDS Control Display or Clear All Entries in RDMS Automatic Recompile Table (AR) The AR command displays or clears all entries in the RDMS automatic recompile table (ART). The DIS (DISPLAY) option displays a list of programs that contain commands that were automatically recompiled in this application group. If the ART is empty, RDMS returns the following message: THE RDMS AUTOMATIC RECOMPILE TABLE IS EMPTY SUDS prints the following information for each program: FILENAME RCMP RUSE DATE-TIME The qualifier, file name, element name, and version name of the program that contains automatically recompiled ESQL statements. Note that if the source file is not named during the compile of the program (for example, where the I option indicates that the source program comes from the runstream), the filename is reported by the SUDS AR command as symbols for the filename) When Open Programming Environment (OPE) is used to compile the program, the SUDS AR keyin displays the rightmost 63 characters of the path name, including the extension, if there is one. If the path is longer than 63 characters, it is truncated on the left with no indication that it was truncated. Duplicate names (with different timestamps, however) can appear if more than one compilation unit contains the same source input name. The recompile count: The number of statements in the program with this name that were automatically recompiled. This includes all executions of the program since the program name was first inserted into the ART. The reuse count: The number of times a recompiled statement was reused in this program. This includes all executions of the program since the program name was first inserted into the ART. The REUSE count increases by one for each INSERT, UPDATE, and DELETE statement. The thread start time. This display can be truncated on a console screen. The ART does not contain information on shared files or file cycles. The ART maintains 100 program names, in no particular order. When the ART is full, a new entry replaces the oldest entry

239 Monitoring and Analyzing UDS Control Use the CLR (CLEAR) option to clear all entries from the ART. RDMS returns the following message: ALL ENTRIES IN AUTOMATIC RECOMPILE TABLE CLEARED If a program is running on more than one host on a multihost system, you must execute the AR command on each host to display or clear the table on each host. Example Two entries exist in the ART, both with a recompile count of 1. One has a reuse count of 1, the other 0: ar ENTER DIS (DISPLAY), OR CLR (CLEAR) dis FILENAME RCMP RUSE DATE TIME UDS$$ONE*PROGRAMS.PROGRAM mm/dd/yy hh:mm:ss UDS$$ONE*PROGRAMS.PROGRAM mm/dd/yy hh:mm:ss INPUT FUNCTION ar ENTER DIS (DISPLAY), OR CLR (CLEAR) clr ALL ENTRIES IN AUTOMATIC RECOMPILE TABLE CLEARED INPUT FUNCTION ar ENTER DIS (DISPLAY), OR CLR (CLEAR) dis The RDMS AUTOMATIC RECOMPILE TABLE IS EMPTY For further information about RDMS automatic recompilation, see the Relational Database Server for ClearPath OS 2200 Administration Guide

240 Monitoring and Analyzing UDS Control Temporarily Change SERVICE Run Configuration Parameter (CF) The CF command lets you temporarily change the configuration parameters for the SERVICE run (UDS-SERVICE-SAMPLING-PERIOD, UDS-SERVICE-TIMEOUT-PERIOD) without reconfiguring the application group. You can also display the current values of these parameters without changing them. Note: These attributes can be updated through the UREP PROCESS CONFIGURATION IMMEDIATE... UPDATE command, and the updates persist over an abort, refresh, or reconfiguration. Example Change the sampling period to 400 seconds and the timeout period to 3,000 seconds: cf INPUT CONFIGURATION PARAMETER TO CHANGE OR "DISP" time INPUT NEW VALUE IN DECIMAL SECONDS 3000 TIMEOUT PERIOD WAS 20 IS 3000 INPUT FUNCTION cf INPUT CONFIGURATION PARAMETER TO CHANGE OR "DISP" samp INPUT NEW VALUE IN DECIMAL SECONDS 400 SAMPLING PERIOD WAS 10 IS 400 INPUT FUNCTION cf INPUT CONFIGURATION PARAMETER TO CHANGE OR "DISP" disp CURRENT TIMEOUT PERIOD IS 3000 CURRENT SAMPLING PERIOD IS 400 INPUT FUNCTION ex

241 Monitoring and Analyzing UDS Control Set Check Schema Flag (CS) The CS command sets the check schema flag in the DMR tables. If a particular schema or subschema table is requested and the table is not in use by another thread, the DMR searches the file to find the table. It then reads the table into a schema bank and reestablishes the file (sector) address in the TRL entry. Tables in use by other threads at the time of the CS keyin remain intact until other threads are no longer using them. The searching and rereading of the file and the reestablishment of the sector address occur once for each table present at the time of the CS keyin. All schema and subschema tables, as well as information about the location of the file containing the tables, are refreshed at the earliest opportunity. You must execute the CS command whenever a schema or subschema is changed or whenever anything is done to change the mass storage address of elements in the schema file; for example, after a file is packed or whenever a new absolute with the same element name as the existing absolute is copied into the file. All schema and subschema tables are reloaded from the file with the sector address determined by a search of the table of contents of the file. For more information about changing and replacing schemas and subschemas, see the Network Database Server for ClearPath OS 2200 Administration and Support Guide Delete Application Group Entry (DA) The DA command deletes an application group from the ADT and elicits an illegal alias error from the intercept and connect routine (ICR) for all active UDS threads in the application group. In the following example, SUDS does not check the current state of the application group before performing this command. Do not enter the name of the application group the first time SUDS solicits it. Instead, just transmit. uds$$src*abs$.suds INPUT APPLICATION NAME (6 CHARS) (transmit: do not enter an application group name) INPUT FUNCTION da INPUT NAME OF APPLICATION TO BE DELETED (6 CHARS) apptwo ARE YOU SURE YOU WANT TO DELETE THIS APPLICATION? Y,N? y APPLICATION DELETED EXITING SUDS To use the SUDS DA command on a system with Security Option 3 configured, you must have write access to the file UDS$$SRC*SECURE-FILE

242 Monitoring and Analyzing UDS Control Display UDS Control D-Bank (DB) The DB command dumps specific portions of the UDS Control D-bank buffer space to your input/output device (your demand terminal for interactive mode, or a default dump file if batch mode). SUDS solicits the start address (xxxxxx) and number of words to be dumped (nnn). The start address must be a 6-digit octal number. Use a slash between the address and number of words. Example Print the contents of address (octal) and the next 012 octal words from the UDS Control D-bank: db INPUT START/NUMBER WORDS IN OCTAL AS XXXXXX/NNN /012 UDS DUMP : START ADDR Change or Display the Data Capture State for a Schema (DC) The DC command is only useful for sites running DMS applications when the Data Capture feature is configured. The SUDS DC command manages the Data Capture logging state for a schema. The DC command prompts the user for a schema name, displays the current Data Capture state for the schema, and requests the user to enter a state of ON or OFF. For more information, refer to the Enterprise Network Database Server for ClearPath OS 2200 Administration and Support Guide Display Errors (DE) The DE command displays the contents of the error dump control table. Example de ERROR ID ERROR NUMBER DCS TCS

243 Monitoring and Analyzing UDS Control Display Locks (DL) The DL command displays the maximum number of block or record locks a thread can hold, for both transaction and batch or demand runs. If a thread attempts to exceed this maximum, the thread is either given an informational message, or rolled back depending on the value of the configuration attribute MAX-LOCKS-MSG-TYPE. The default of zero means that the thread type has no lock threshold. Example dl MAX TXN BLOCK/RECORD LOCKS (0=OFF) 4 MAX DMND/BATCH BLOCK/RECORD LOCKS (0=OFF) Display Message (DM) The DM command displays the TIP-suppressed message table contents. The DM command executes exactly like the DE command. Example dm ERROR ID ERROR NUMBER DCS TCS Dump UDS D-Banks (DP) The DP command dumps all UDS D-banks to a dump file. SUDS calls the UDS dump processor to dump all UDS D-banks to the dump file. The UDS dump processor prints a message containing the name and cycle of the dump file and sends it to the system console. SUDS prints another message when it regains control from the UDS dump processor. Example In this example, the UDS dump routine dumped the contents of all D-banks for the application group into file UDSSRC*DUMP0(22). If more than one file is required to take the dump, the message includes the names of the first and last dump files (see 4.1). dp UDS DUMP TAKEN yy/mm/dd hh:mm:ss UDSSRC*DUMP0( 22) APP 3 UDS DUMP COMPLETE where: yy/mm/dd hh:mm:ss is the date and time that the dump occurred

244 Monitoring and Analyzing UDS Control Exit SUDS (EX) The EX (exit) command terminates SUDS. When you enter the EX command, SUDS executes an ER EXIT$ and terminates itself. The EX command produces no output and has no effect on how other programs use UDS Control. Example ex EXITING SUDS Free File from UDS Domain (FF) The FF command frees a file from the UDS domain. Use this command only as a last resort, when you cannot use the IRU DOWN command to free the file from the UDS domain. This command does not change the internal UDS Control tables concerning file assignments, nor does it release UDS cache pages associated with files. Thus, if you use the FF command, you must ensure that UDS Control is down (with the SUDS II command if necessary). A blank is an acceptable response when SUDS solicits an application group name, providing you are trying to free file ADT-FILE. The UDS Control bank, defined in the release configuration, is used to switch into the UDS domain to attempt to free file ADT-FILE. If you entered a blank for the application group name after entering SUDS and the file you want to free is not ADT-FILE, SUDS solicits the application group name and the function again. SUDS solicits the file name and inserts it into CSF statement, and then performs statement in the proper domain. INPUT APPLICATION NAME (6 CHARS) (transmit: Do not enter an application group name) INPUT FUNCTION ff INPUT FILE NAME (QUALIFIER MUST BE SPECIFIED) USE SHARED# PREFIX FOR SHARED FILES jwb*file NAME OF DOMAIN FROM WHICH TO FREE FILE IF BLANK, FREE FILE WILL NOT BE ATTEMPTED udssrc FILE IS NOT ASSIGNED INPUT FUNCTION ex EXITING SUDS

245 Monitoring and Analyzing UDS Control Help (HE) The HE command produces a list of all SUDS commands Change or Display the Hardware/Performance Monitoring Mode (HM) The HM command lets you temporarily modify the configuration attribute PERFORMANCE-MONITORING or display the hardware/performance monitoring mode. It collects statistics on Exec and user states. SUDS solicits the hardware/performance monitor mode (OFF or ON) and sets the desired mode in UDS tables for UDS Control; or it displays (DIS) the current hardware/performance monitor mode. If you select monitoring ON, UDS sets the performance monitor software state to the UDS state (user state 4) for each thread when it enters UDS on any command. The UDS state is cleared when the thread leaves UDS on the same command. Note: This attribute can be updated through the UREP PROCESS CONFIGURATION IMMEDIATE... UPDATE command, and the updates persist over an abort, refresh, or reconfiguration. Example This example illustrates how to change the hardware/performance monitor mode from OFF to ON. The performance monitor state changes to the UDS state at the beginning of each command and is cleared at the end of each command. hm ENTER ON, OFF, OR DIS on MONITOR SET TO ON FROM OFF hhmmss mmddyy INPUT FUNCTION ex EXITING SUDS where: hhmmss mmddyy is the time and date that the change occurred Disable Application Group (II) The II command disables the application group by performing an ER DMABT$. Assuming that TIP_SESSION_CONTROL is not configured (that is, NOT TRUE), it places the application group in an IRU pending state (IRU:PND). If, however, TIP_SESSION_CONTROL = TRUE, the II command disables the UDS session and places the application group in a "down-like" state. Since TIP sessions cannot be recovered from this state, you must use the AP n UP keyin, where n is the application group number, to bring up the application group

246 Monitoring and Analyzing UDS Control All threads registered with UDS in the application group at the time of the II keyin are terminated in one of three ways: An E keyin abort A type 21 abort An ER ERR$ abort The UDS protected fixed-gate subsystem is also deactivated. Run short recovery to allow threads to again enter UDS for the application group. If you are using a REFRESH runstream, recovery occurs automatically upon the next attempt to access the application group. For information about how to set up a REFRESH runstream, see the Universal Data System Configuration Guide. Example II II WILL PUT APPLICATION DOWN (SHORT RECOVER TO UP IT) ARE YOU SURE YOU WANT TO DO AN II KEYIN - Y,N? y UDS DUMP TAKEN yy/mm/dd hh:mm:ss UDSSRC*DUMP0( 13) The application group will be aborted. The UDS Protected Fixed-gate Shared Subsystem will be deactivated. SHORT RECOVERY is needed for cleanup. EXITING SUDS Refresh Application Group (IL) The IL command refreshes the application group if it is idle. If no threads are active, the command deactivates the UDS Control protected fixed-gate subsystem. You can use this command, for example, to coordinate an XTC application group on different hosts after performing a UREP PROCESS CONFIGURATION INSTALL command. By using the IL command, you avoid stopping the whole application group, including FCSS transactions, as the II command does. If threads are active, the command returns a message and takes no action. In this case, you can refresh the application group by doing an II command, followed by an IRU SHORT RECOVER command. Example If the application group is idle: IL IL will Refresh an idle UDS without an abort or dump. Are you sure you want to Refresh UDS - Y/N? Y APPSVN - UDSC PFGS subsystem deactivation requested via a SUDS IL. EXITING SUDS

247 Monitoring and Analyzing UDS Control List Dedicated Entries (LD) The LD command produces a list of dedicated entries. SUDS determines the number of dedicated file table entries. For each dedicated file table entry, SUDS prints the following information: Qualifier File name Start-end BDI Status Qualifier of the file for which the dedicated file table entry applies File name for which the dedicated file table entry applies Mass storage start and end address for the file dedication Bank descriptor index for the bank to contain the file dedication Blank if large I/O is not specified for the dedication; if large I/O is specified, the status field is one of the following: NOIO INPR DONE Large I/O is not initiated Large I/O is in progress Large I/O is done Example One dedicated file table entry if present has no large I/O specified: ld QUALIFIER FILE NAME START-END BDI STAT UDS$$SRC*ROLLBACK List Active Schemas (LS) The LS command produces a list of active schemas in use by DMR in this application group. For sites running with the Data Capture feature configured, the LS command also displays the Data Capture state for a schema. SUDS searches the DMR TRL table, which controls schema and subschema reference tables, for any nonzero schema names. For each schema found, SUDS determines the status of the schema and produces the following output: ACTIVE RELCTD ABRTED In use by one or more threads Not in use Abort flag set in the DMR TRL table SUDS also appends the following: INCOR DYN The entire schema is INCORE (resides in main memory). The schema is DYNAMIC (not all of the schema resides in main memory)

248 Monitoring and Analyzing UDS Control Monitoring and Analyzing UDS Control SUDS appends text to an LS entry when the Data Capture feature is configured. NO DCT DC UNKNOWN DC OFF DC RELCTD DC ACTIVE Data Capture logging cannot occur because DCT does not exist for this schema. A DCT might or might not exist. Data Capture logging state is not ON or OFF. Data Capture logging for this schema is off. Data Capture is not in use, but occurs if a DCT is present. Data Capture logging is active. Example when Data Capture Is Not Configured The DMR TRL table lists two schemas. Schema S02 has a use count of zero and is therefore a candidate to have its space reallocated if space is required. Schema S21 is active (its use count is greater than zero). Schema S02 is INCORE, but schema S21 is DYNAMIC. ls ** SCHEMA S02 RELCTD-INCOR ** SCHEMA S21 ACTIVE-DYN Example when Data Capture Is Configured The DMR TRL table lists six schemas: CDC-SCH1 is not used by any thread, and its associated DCT is not in use. CDC-SCH2 is used by one or more threads and Data Capture logging is active. CDC-SCH3 is used by one or more threads, but Data Capture logging is off for the schema. CDC-SCH4 is not used by any thread and Data Capture is off. CDC-SCH5 is used by one or more threads and a DCT is not in the schema file of CDC-SCH5. CDC-SCH6 is not used by any thread, a DCT might or might not be in the schema file of CDC-SCH6, and Data Capture logging state CDC-SCH6 is not ON or OFF. ls ** SCHEMA CDC-SCH1 RELCTD-INCOR DC RELCTD ** SCHEMA CDC-SCH2 ACTIVE-INCOR DC ACTIVE ** SCHEMA CDC-SCH3 ACTIVE-DYN DC OFF ** SCHEMA CDC-SCH4 RELCTD-INCOR DC OFF ** SCHEMA CDC-SCH5 ACTIVE-INCOR NO DCT ** SCHEMA CDC-SCH6 RELCTD-INCOR DC UNKNOWN

249 Monitoring and Analyzing UDS Control List Active Subschemas (LU) The LU command produces a list of active subschemas in use by DMR in this application group. The LU command solicits the name of the schema and displays information about all subschemas for that schema that reside in UDS. You can display all subschemas for all schemas by leaving the schema name blank. For each subschema found, SUDS determines the status of the subschema and produces the following output: ACTIVE RELCTD In use by one or more threads Not in use SUDS also appends the following: INCOR DYN The entire subschema is INCORE (resides in main memory). The subschema is DYNAMIC (not all of the subschema resides in main memory). Example The DMR TRL table lists two subschemas. Subschema SS0201 for schema S02 has a use count of zero and is therefore a candidate to have its space reallocated if space is required. The subschema is also DYNAMIC. Subschema SS0202 for schema S02 is active (its use count is greater than zero) and is INCORE. lu ** INPUT SCHEMA NAME OR TRANSMIT FOR ALL SCHEMAS ** S02 ** SCHEMA S02 SUBSCHEMA SS0201 RELCTD-DYN ** SCHEMA S02 SUBSCHEMA SS0202 ACTIVE-INCOR Display UDS Control Level (LV) The LV command displays the level of UDS Control from the UDS Control D-bank. It also displays the time that the application group was initialized. Examples When the application group is loaded but not initialized: lv UDSC LEVEL: UDSCxxRy When the application group is loaded and initialized: lv UDSC LEVEL: UDSCxxRy : APP GROUP INITIALIZED yyyy/mm/dd hh:mm:ss

250 Monitoring and Analyzing UDS Control Modify Batch/Demand Lock Threshold (MB) The MB command lets you temporarily modify the configuration attribute MAX-LOCKS-BATCH that limits the maximum number of block or record locks that a batch/demand program can hold before the thread is rolled back. If a thread attempts to exceed the maximum number of the lock threshold for the thread type, the thread is either given an informational message or rolled back depending on the value of the configuration attribute MAX-LOCKS-MSG-TYPE. The default of zero means that the thread type has no lock threshold. The lock threshold does not apply to UDS processors such as IRU, DDL/SDDL, DDLINIT, DMU, SRT, DD, DDFINIT, and RDMUTL. Note: This attribute can be updated through the UREP PROCESS CONFIGURATION IMMEDIATE... UPDATE command, and the updates persist over an abort, refresh, or reconfiguration. Example mb ENTER THE NEW BATCH/DEMAND LOCK THRESHOLD 10 MAX TXN BLOCK/RECORD LOCKS (0=OFF) 0 MAX DMND/BATCH BLOCK/RECORD LOCKS (0=OFF) 10 The largest threshold value assignable using MB is Modify Transaction Lock Threshold (MT) The MT command lets you temporarily modify the configuration attribute MAX-LOCKS-TRANSACTION that limits the maximum number of block or record locks that a transaction program can hold before the thread is rolled back. If a thread attempts to exceed the maximum number of the lock threshold for the thread type, the thread is either given an informational message or rolled back depending on the value of the configuration attribute MAX-LOCKS-MSG-TYPE. The default of zero means that the thread type has no lock threshold. The lock threshold does not apply to UDS processors such as IRU, DDL/SDDL, DDLINIT, DMU, SRT, DD, DDFINIT, and RDMUTL. Note: This attribute can be updated through the UREP PROCESS CONFIGURATION IMMEDIATE... UPDATE command, and the updates persist over an abort, refresh, or reconfiguration

251 Monitoring and Analyzing UDS Control Example mt ENTER THE NEW BATCH/DEMAND LOCK THRESHOLD 4 MAX TXN BLOCK/RECORD LOCKS (0=OFF) 4 MAX DMND/BATCH BLOCK/RECORD LOCKS (0=OFF) 10 The largest threshold value assignable using MT is Override Clear (OC) This function clears the Reconfigure Anyway flag in the UDS Control D-bank, allowing thread control to enforce the prohibitions on activating new UDS configurations. Refer to for more information. oc Reconfigure Anyway flag was SET, is now CLEARED. INPUT FUNCTION ex Override Display (OD) This function displays the Reconfigure Anyway flag in the UDS Control D-bank. od Reconfigure Anyway flag is SET. INPUT FUNCTION ex Override Set (OS) This function sets the Reconfigure Anyway flag in the UDS Control D-bank, allowing thread control to activate new configurations even though all conditions are not perfect with the configurations. os Reconfigure Anyway flag was CLEARED, is now SET. INPUT FUNCTION ex

252 Monitoring and Analyzing UDS Control List Status of Registered Threads (RC/RU) The RC and RU commands print the status of threads registered with UDS Control and displays the number of block and record locks a thread is using. The RC and RU commands have the same function. SUDS searches the thread summary table (TST) in the UDS Control D-bank and prints the status of each thread that has an active TST entry. The thread status consists of eight values for each thread: Original run-id This field usually picks up its values from the PCT. In some cases for MAPPER and certain other runs, the original run-id displays the generated run-id from the PCT and the generated run-id displays the input-id from the product. Generated run-id This field usually picks up its values from the PCT. In some cases for MAPPER and certain other runs, the original run-id displays the generated run-id from the PCT and the generated run-id displays the input-id from the product. If the generated run is followed by an asterisk, the run is a deferred update thread. Time The value in this field is taken from the last start of step for the thread. It is displayed in local time in the format hhmmss. Sequence number This field displays the number of times the thread has entered UDS Control. Number of updates Locks This field displays the number of block and record locks the thread has acquired. UDS Message This field indicates rollback or external error status. Step control status The following values are possible: COMMIT EOS INITIAL MCB UDS commit (UDS$STEP, uds_commit function) complete but end of step not complete. UDS end of step (UDS$STEP, uds_eos function) complete. Registered with UDS Control, but start of step (UDS$STEP, uds_sos function) incomplete. Message Control Bank (MCB) called after end of step or rollback (UDS$STEP, uds_eos or uds_rollback function)

253 Monitoring and Analyzing UDS Control MSGnnnn PR PROG PREPARE Q ON nn RB RB ONLY RB PROG SOS STAGING TERMED WRTnnnn Notification of broadcast-related requests being made to the Record Lock Processor (RLP) through ERs/calls since the beginning of the thread, where nnnn is the number of requests already made. If nnnn is not changing between keyins, the thread is waiting for an answer from the RLP. A global transaction thread with prepare in progress. A global transaction thread with UDS Prepare (UDS$STEP, uds_prepare function) complete. Thread queued for reason nn, where nn is one of the following values: 01 File access: file not available; usage conflict among threads 02 Page access: page not available; usage conflict among threads 03 Record access: record not available; usage conflict among threads 04 Table access: RDT, FDT, or FPTE table not available; usage conflict among threads 05 UDSC-D storage: insufficient UDS-D space available to satisfy request 06 Page-D storage: insufficient page space to satisfy request 07 Dedicated page-d storage: insufficient dedicated page space to satisfy request All these reasons for queuing can cause deadlock conditions. Rollback complete. This step was part of a global transaction and the rollback is deferred. The thread is waiting for the transaction manager to issue the OMIT. Rollback in progress. UDS start of step (UDS$STEP, uds_sos function) complete. SOS indicates a new step or recoverable unit has been started Deferred update staging in progress. Thread terminated and deregistered from UDS Control. Notification of requests related to locking or cache validity being made to the Record Lock Processor (RLP) through ERs since the beginning of the thread, where nnnn is the number of requests already made. If nnnn is not changing between keyins, the thread is waiting for an answer from the RLP

254 Monitoring and Analyzing UDS Control Example 1 Three threads are active in UDS. The first one, generated ID 5UDS, started its last step at 12:00:00, was through UDS 1,020 times, has updated 88 pages since the start of the step, has acquired 97 locks, and is queued trying to lock a page. rc ORG-ID/GEN-I D TIME SEQUENCE UPDATES LOCKS UDSMSG STATUS 5UDS/5UDS Q on 2 5UDB/5UDB XYZ/5XYZ If the number of locks exceeds 6 digits, the number is rounded by 1000 and appended with a K. For example, is displayed as 98338K. If the number of locks exceeds , >= 100M is displayed. Example 2 No threads are active in UDS. The last step started in UDS was at hh:mm:ss. rc NO THREADS ACTIVE IN UDS SINCE yyyy/mm/dd hh:mm:ss

255 Monitoring and Analyzing UDS Control Remove Error Code (RE) The RE command removes an error code from the error dump table. SUDS solicits the error-id (CCC) and the error number (NNNNN). The error-id must be three characters long and must be in the list of possible error-ids displayed by the DE command. The number is a 5-digit or less decimal number. Use a slash between the error-id and error number. The following error-ids are associated with the products indicated. Error-id DCS DEX DRB PCS RDM RSM TCS Product UDS Control DMS DMS SFS RDMS RDMS UDS Control Example Remove DCS error number (decimal) from the error dump table: re POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-ID/ERROR-NUMBER AS CCC/NNNNN dcs/

256 Monitoring and Analyzing UDS Control List Active Steps (RL) The RL command produces a list of active, committed and prepared steps for the application group. SUDS uses ER MQF$ to retrieve a list of active, committed and prepared steps and prints the following information for each step: Thread-id Step-id Message number Status Generated run-id from the thread summary table entry Returned for the step from the MQF$ Returned for the step from the MQF$ Either ACTIVE, COMMIT, or PREPRD Example This example has two active steps (a UDS$STEP, uds_sos function was performed but the step was not ended). Both steps are still registered in UDS (thread -ids were found in UDS tables). The generated IDs for the steps are 5UDS and 5UDSA. The Step-id is generated by the Exec, and the internal format of the Step-id is dependent on the Exec level. The application group has no COMMIT or PREPARED steps. rl THREAD STEP-ID MSG.NO STATUS 5UDS ACTIVE 5UDSA ACTIVE NO COMMIT STEP NO PREPRD STEP

257 Monitoring and Analyzing UDS Control Remove Message (RM) The RM command removes any component-id/error number that you have specified in the TIP-suppressed message table, using the AM command. This command is exactly the same in execution as the RE command. The following error-ids are associated with the products indicated. Error-id DCS DEX DRB PCS RDM RSM TCS Product UDS Control DMS DMS SFS RDMS RDMS UDS Control Example This example illustrates how to remove a message for error TCS 50340: rm POSSIBLE ERROR-IDS ARE: DCS DEX DRB PCS RDM RSM TCS INPUT ERROR-IDS/ERROR NUMBER AS CCC/NNNNN tcs/

258 Monitoring and Analyzing UDS Control Change RLP Scan Times for ADT/IRU (RS) The RS command sets the RLP-DEADLOCK-NUMBER-SCANS and RLP-DEADLOCK-SCAN-TIME for the application definition table (ADT) and IRU Record Lock Processor (RLP) locks. SUDS solicits the RLP-DEADLOCK-NUMBER-SCANS and RLP-DEADLOCK-SCAN-TIME and submits them to the RLP. These values are then used for the deadlock detection timeout for locks requested by the ADT and IRU. You must have RLP$ER privileges to use this command. Example rs INPUT RLP-DEADLOCK-NUMBER-SCANS FOR ADT/IRU VALUE MUST BE IN THE RANGE OF (1-255) 32 INPUT RLP-DEADLOCK-SCAN-TIME FOR ADT/IRU VALUE IS NUMBER OF TENTHS (1-255) E.G. 32 IS 3.2 SECONDS Set Schema Abort Flag (SA) The SA command sets the schema abort flag in the DMR TRL table for a specific schema. SUDS solicits a schema name and then searches for it in the DMR TRL table. If SUDS does not find the schema or if the schema is already aborted, SUDS reports the condition. Otherwise, SUDS sets the abort flag in the DMR TRL table. The SA command causes all threads using the aborted schema to be rolled back on the next command through the DMR. Example This example illustrates how to set the schema abort flag for schema S02: sa ** INPUT SCHEMA NAME ** s02 SCHEMA ABORT SET

259 Monitoring and Analyzing UDS Control Clear Schema Abort Flag (SC) The SC command clears the schema abort flag and sets the schema clear flag for the specified schema. SUDS solicits the schema name and searches for it in the DMR TRL table. SUDS clears the schema abort flag and sets the schema clear flag in the DMR TRL table. If SUDS does not find the schema or if the schema is still in use, it reports the condition and does not set the schema clear flag. Depending on whether the schema tables are in core or not, addresses are cleared in the TRL entry and vacancies are created in the schema bank for the schema tables. Since the sector addresses are cleared in the TRL, the DMR is forced to search the table of contents of the schema or subschema file and read in the schema and subschema absolutes. Example This example illustrates how to clear the schema abort flag from schema S02: sc ** INPUT SCHEMA NAME ** s02 SCHEMA CLEAR SET Display Count of Discarded UDS Broadcast Messages (UM) The UM command displays the Exec count of UDS broadcast messages that were discarded and not sent to a RUB receiver activity on this host. You must have RLP$ER privileges to use this command. Example 0 UDS BROADCAST MESSAGES HAVE BEEN DISCARDED

260 Monitoring and Analyzing UDS Control 8.5. TeamQuest Transaction Performance Auditing System (TeamQuest TPAS) You can send local statistics to TeamQuest TPAS through the UDSC facility. UDS Control responds to a call made by TeamQuest TPAS, which sends a packet to the UDS thread control intercept and connect routine (ICR) to turn this facility on or off. Upon recognizing this packet, the thread control ICR sets a flag in the application characteristics table. The site administrator alone is responsible for and capable of turning on TeamQuest TPAS and, as long as it is turned on, UDS Control continues to send statistics to TeamQuest TPAS. You do not need to turn on TRCCTL to use TeamQuest TPAS. Depending on what the site administrator selects, statistics are sent at the end of each command or at the end of each thread. UDSC-TeamQuest TPAS has the same attributes for all threads in an application group. Users do not have direct control over the mode of the sampling period. For further information about this facility, see the TeamQuest TIP Log Analyzer (TIP-LA) Administration and End Use Reference Manual. You cannot install TeamQuest TPAS on a system configured with Security Option 3. For more information, see the Security Administration for ClearPath OS 2200 Help TeamQuest Online System Activity Monitor (TeamQuest OSAM) UDS Control and TeamQuest OSAM fully support the performance monitoring and analysis of the UDS run-time system. The UDS/TeamQuest OSAM monitor supports UTS and PC graphic capabilities for collecting, reporting, and analyzing UDS performance statistics. For further information about this facility, see the TeamQuest OSAM End Use Reference Manual

261 Monitoring and Analyzing UDS Control 8.7. Database Event Reporting The Database Event Reporting (DBEVNT) program collects detailed information about the processing of database commands within UDS Control, RDMS, DMS, and SFS. This information is logged to either tape or mass storage. DBEVNT processor is used to turn logging on or off in UDS at the application level. You can specify various options to obtain information, such as user-id, host-id, program-id, terminal-id, application number, date and time, command code, schema name, area and table name, and logging. You can control logging for program type (batch/demand/transaction), LDM type (RDMS/DMS/SFS), and level (thread/command). Logging becomes active for new threads entering UDS. You can also use the DBEVENT processor to produce reports The DBEVENT program is part of the TeamQuest Site Administration Utilities (SAUtilities) product suite. The logged information can also be processed by other products for use in Data Warehouse or Redbrick database applications. DBEVENT logging and TeamQuest TPAS logging are mutually exclusive. For further information about this feature, refer to the TeamQuest SAUtilities End Use Reference Manual

262 Monitoring and Analyzing UDS Control

263 Section 9 Using UDS in a Security Option 3 Environment This section describes Security Option 3, which uses subsystems to partition the system according to the security attributes of the common banks within the system. Security Option 3 is a package of the OS 2200 security feature set that provides the highest level of protection 9.1. Finding Information About Security Option 3 The Security Administration for ClearPath OS 2200 Help contains general information about installing and configuring Security Option 3 for the entire OS 2200 system, including a summary of ADT common bank user security attributes and UDS common bank security attributes. Specific information for setting up Security Option 3 for UREP, RDMS, DMS, and IRU is included with the administration guides for these products: Repository for ClearPath OS 2200 Administration Guide Relational Database Server for ClearPath OS 2200 Administration Guide Network Database Server for ClearPath OS 2200 Administration and Support Guide Integrated Recovery Utility Administration Guide This section describes the following for a UDS environment: Security Option 3 common bank concepts Untrusted and trusted subsystems UDS Control command privileges UDS security events logging

264 Using UDS in a Security Option 3 Environment 9.2. Security Option 3 Concepts Security Option 3 includes the concept of common bank encapsulation into a subsystem along with mandatory validations and restrictions for accessing the common banks. Each application group can have its own security level. For example, application group 3 could have a clearance level of 10 and a compartment set of PAYROLL while application group 7 has a clearance level of 20 and compartment set of SECRET. Security Option 3 also ensures that database files are accessed only by the UDS common banks of one application group; that is, database files can be made private to the UDS common bank. This environment also ensures that users cannot access the UDS common bank data banks directly. If your site is a Security Option 3 environment, you cannot use unowned files, security records, or access control records. For information about installing UDS products with Security Option 3 configured, see the Universal Data System Configuration Guide Subsystems To effectively access data in a Security Option 3 environment, it is important to understand how subsystems affect files in a UDS Control system. The following section discusses how subsystems relate to security in a UDS environment. The Exec uses subsystems to partition the system according to the security attributes of the subsystems within the system. UDS is concerned with three types of subsystems: UDS untrusted subsystems, the library subsystem, and trusted subsystems UDS Untrusted Subsystems A UDS untrusted subsystem is a set of extended mode object module subsystems and encapsulated common banks in which all members of the set require the same security level for access. The subsystem that contains the UDS Control D-banks and any other banks the site wants protected is a UDS untrusted subsystem. It also contains a UDS Control protected fixed-gate subsystem, which functions as the entrance to the UDS subsystem. The security attributes of the owner of this UDS subsystem must be the level of the database; no privileges are required. The AUDIT$TRAIL call and several other privileged ERs/calls are required

265 Using UDS in a Security Option 3 Environment Library Subsystem The library subsystem is a "gateless" subsystem of read-only common banks and subsystem object modules. The library subsystem allows banks to behave much like banks do without Security Option 3. Banks that are part of the library subsystem must be read-only and they must reside in a file that has a security classification of system-low (compartment set=null, clearance level=0). Banks in the library subsystem require no guaranteed entry points or any other special access methods. In a typical configuration, UDS Control code banks and all intercept and connect routines (ICR) reside in the library subsystem Trusted Subsystems A trusted subsystem is a subsystem that has trusted privileges. For the trusted subsystem, which contains the application definition table (ADT) AFCB, the following privileges are required: Absolute device assignment Bypass ACR evaluation Bypass volume label check Bypass clearance level check Bypass compartment set validation Bypass object reuse Bypass ownership check Modify run clearance level (within the range of 0 to 63) Change file backup information ER SMOQUE$ privileged functions In all UDS Control configurations, the ADT resides in a trusted subsystem (with shell privileges) at ring level 1. For more information about subsystems, see the Security Planning and Administration Reference Manual Accessing Subsystems Access to the UDS untrusted subsystem and the ADT subsystem is controlled by two separate gate banks. A thread must always enter the UDS subsystem by jumping to the start address of the common bank to which the UDS gate bank is attached. The UDS subsystem has only one gate bank and therefore only one entry point. Each ICR jumps to that entry point, a process that is transparent to users. Moreover, ADT bank entrances and exits are also transparent to users because they are internal to UDS. Gate banks work like a lock and key. You must obtain a key from the gate of a subsystem. Once you have a key, you can access any bank within the subsystem. From within the subsystem, you can access banks from the library subsystem or you can enter other subsystems. When you return to the calling bank, you return the subsystem key and retrieve your original key, which exits you from the subsystem

266 Using UDS in a Security Option 3 Environment The key is directly related to the security attributes of the owner of the AFCB file from which the absolutes are taken for the subsystem AFCBs. The locking and unlocking mechanism for the subsystem is a comparison (performed by the Exec whenever a bank is based) between the security attributes of the owner of the AFCB file and the security attributes of the executing user UDS Control Command Privileges If your system has Security Option 3 configured, you must have the privileges to use UDS commands that allow you to administer UDS. Each UDS command privilege provides a way for specified users to override security violations. There are three UDS Control command privileges: UTILITY UDS IRU LDM TPAS UDS This privilege allows the use of the UDS Control Utility Interface (you can use the processors TRCCTL, DRU, REORG, SUDS, and other functions). This privilege allows the use of IRU commands with UDS Control in an application group. This privilege allows the use of the thread control TeamQuest TPAS commands and the UDS Database Event Reporting interface. Users can have a UDS command privilege for any of the following reasons: Their user-ids are specified in the UDS configuration attribute, which specify the user-ids that can perform the specific UDS commands. The user-id list in the UDS configuration that specifies the user-ids that can perform the specific UDS commands is "blanks." All users have the UDS command privilege, and any user can perform the command. The user has write access to the interface security file (STD#UDS$$SRC*INTERFACESEC). A user with write access to this file has all UDS Control command privileges; it does not matter which user-ids are specified in the UDS configuration. Since the list of user-ids is not available if the application is not initialized, access to this file is used to protect usage of those utilities which can be used in an uninitialized application. It is also a good idea to ensure that there is always a user who can use these utilities (like a security officer in the Exec and UREP). This file is cataloged during the UDS Control installation. The installer must set the security attributes of this file. For more information about setting up the necessary security attributes for your system, see the Repository for ClearPath OS 2200 Programming Reference Manual. The UDS subsystem itself always has all UDS command privileges. This is necessary in order for the UDS background SERVICE run and the UDS REFRESH run to have the privileges they need to operate

267 Using UDS in a Security Option 3 Environment Since an ACR can be used to define who has write access to the UDS Interface Security file, if the user-id list is made private (that is, empty), then in effect the ACR defines who has the UDS command privileges. However, this is not a recommended way of managing security because it slows performance and gives users more privileges than they might need (each user given write access by the ACR then has all UDS command privileges). If a user tries to use a utility and does not have the proper UDS command privilege, a log entry appears in the system log file Creating UDS Subsystems Some UDS AFCBs must be located in each of the three types of subsystems: UDS untrusted, library, and trusted. All UDS product D-banks must be in the UDS untrusted subsystem, ICRs must be in the library subsystem, and the ADT must be in a trusted subsystem. The security attributes of the owner of the AFCB file that contains the AFCBs determine in which subsystem the banks must be. To change any UDS subsystem security attributes, you must first use TeamQuest SIMAN to change the security attributes of the subsystem user-id and then reboot your system (the new security attributes of a common bank subsystem are not made effective until a system reboot occurs). Alternatively, you must reboot your system and use TeamQuest SIMAN to set the new security attributes of the subsystem user-id before the first user enters UDS Summary: UDS Subsystem Requirements The following points summarize subsystem requirements. These points assume you install UDS Control and other UDS products with the proper user-ids: All ICRs must be in the library subsystem. The ADT AFCB must be in its own trusted subsystem. If you are using Mandatory Access Controls (clearance levels and compartment set), the ADT user-id must have a clearance level of 63 and compartment set ALL. If your system is only using Discretionary Access Control (clearance level is 0 and compartment set is NULL for all of your files), the ADT user-id must have a clearance level 0 and compartment set NULL. All D-banks must be in the UDS untrusted subsystem. All shared I-banks must be in the library subsystem. All nonshared I-banks must be either in the library subsystem or in their respective UDS untrusted subsystem, as determined by the installation parameter. I-banks cannot be shared unless they are in the library subsystem. The UREP common D-bank and gate target banks must be in the UREP common bank subsystem. The UREP ICR bank is in the library subsystem. All other UREP banks are in either the library subsystem or the UREP common bank subsystem as determined by the UDS installation

268 Using UDS in a Security Option 3 Environment The UREP$BDI file has the same security attributes as the library subsystem. The SECURE-UREP file has by default the same security attributes as the file UDS$$SRC*SECURE-FILE. You can also change the security attributes of this file to restrict access to the UREP DDFCONFIG processor functions. All user programs that use UDS in an application must execute at the clearance level and compartment set of the application group (the only exception is users with SSSSCALLANY privileges). All user programs that use UDS in an application must be executing without any of the trusted privileges (the only exception is users with SSSSCALLANY privileges). User data must be in a ring 3 or lower bank in order for UDS to have access to it. All system files (except for ADT files, UREP$BDI, ICR files, and code bank files for shared I-banks) and database files created by the installation are in the UDS subsystem. All database files (for example, the UREP storage areas) are cataloged as private and owned by the UDS subsystem. You are responsible for putting the proper security attributes on your database files. Database files that are private and owned by the UDS untrusted system ensures that only the UDS untrusted subsystem and privileged users have access to the files File Names and Subsystem Divisions UDS products use these file names and are divided by subsystem as follows: ABS$, RDMS, DMRMT$, UREP, and SFS Contain UDS products I-bank absolutes and utility processors to be installed into either the library subsystem or the UDS untrusted subsystem, depending on whether the UDS products I-banks are to be included in common bank protection. ABSADT$ Contains the ADT bank absolute to be installed into a trusted subsystem. ABSLIB$ Contains the thread control ICR absolute to be installed into the library subsystem. RDMSLIB, DMSLIB$, SFSLIB Contain RDMS, DMS, and SFS ICR absolutes to be installed into the library subsystem. DMSLIB$ also holds the absolutes for UDS$DMRSHELL and UDS$DMRLINKR. UREP$ABSD Contains the UREP D-bank absolute and the UREP gate target bank to be installed into the UREP common bank subsystem. UREP$ABSLIB Contains the UREP ICR bank absolute to be installed into the library subsystem. RSA Contains RDMS I-banks and utilities to be installed in the library subsystem

269 Using UDS in a Security Option 3 Environment RDMS$CFGSDEF Contains the subsystem definition and gate definitions for the RDMS and RSA chameleon fixed-gate subsystems to be installed into the library or UDS subsystem. RDMS$CFGSCOD Contains the object modules for the RDMS and RSA chameleon fixed-gate subsystems to be installed into the library or UDS subsystem. UDSC$PFGSDEF Contains the subsystem definition and gate definitions for the UDS Control protected fixed-gate subsystem to be installed into the UDS subsystem. UDSC$PFGSCOD Contains the object modules for the UDS Control protected fixed-gate subsystem to be installed into the UDS subsystem. UDSC$CFGSDEF Contains the subsystem definition and gate definitions for the UDS Control chameleon fixed-gate subsystem to be installed into the library or UDS subsystem. UDSC$CFGSCOD Contains the object modules for the UDS Control chameleon fixed-gate subsystem to be installed into the library or UDS subsystem. All UDS system files (for example, FDT$ and RDT$FILE), except the ADT files, UREP$BDI, ICR files, and code bank files for shared I-banks, and all user database files must be owned by the UDS subsystem. Catalog system and user database files, therefore, from a user-id that can access the UDS untrusted subsystem or use TeamQuest SIMAN to change the security attributes of these files

270 Using UDS in a Security Option 3 Environment 9.7. UDS Control Security Events Log UDS Control, UREP, RDMS, and DMS events related to security are logged to the Exec system log as they occur, provided logging is turned on by a UDS Control configuration parameter through UREP. For information on configuring logging, see the Repository for ClearPath OS 2200 Administration Guide. Table 9 1 summarizes the log entry types for the UDS products. Table 9 1. UDS Product Event Logging Entry Types Entry Type Product Description UDS Control Created whenever UDS Control detects an illegal attempt to write to a write-inhibited file. When this violation occurs, either RDMS or DMS is attempting to alter a file to which UDS Control has read access UDS Control Created whenever UDS Control detects a securityrelevant event such as violation of a master user-id, or violation of UDS command privileges (for example, when a thread has insufficient UDS command privilege to use a UDS interface) UDS Control Lists the files accessed by a thread UREP Occurs whenever UREP modifies an access right UREP When security objects are created or deleted by UREP UREP When attempted security violations occur in UREP RDMS Happens because of a security violation due to a lack of a statement privilege or option RDMS Displays the successful issuance of a GRANT or REVOKE statement DMS Occurs whenever validation of access control fails. Validation fails when a DMS run unit or utility attempts to access the database and is not allowed due to access control clauses specified in the schema definition DMS Occurs whenever the schema is activated in an application group and becomes available for use by a DMS program. You can generate printed reports using the TeamQuest Log Analyzer (LA). For instructions on using LA, see the TeamQuest LA Administration and End Use Reference Manual. For more information about the Exec system log, see the System Log Operations and Support Reference Manual

271 Section 10 Handling Deadlocks (SERVICE Run) This section explains how to use the background SERVICE run to sample UDS threads and force the rollback of threads incurring deadlock errors that remain queued longer than a preconfigured timeout period How the SERVICE Run Works An undetectable deadlock might occur between a UDS application and a resource outside UDS; for example, the file control superstructure (FCSS) facility. In such a case, two UDS threads, while simultaneously attempting to hold UDS and FCSS resources, become deadlocked because the first thread queues in UDS for resources held by the second thread. At the same time, the second thread is queuing in FCSS for resources held by the first thread. The background SERVICE run samples UDS threads and forces rollback when deadlock errors occur in threads that remain queued longer than a preconfigured timeout period. The run attempts to eliminate false deadlocks by checking the second thread to determine whether it is working inside or outside of UDS. Further, it checks whether the command count is increasing over time; if it is, the run does not roll back the first thread. You can use the UREP dynamic system reconfiguration (DSR) facility to configure the timeout and sampling periods. The following configuration entity types affect the SERVICE run: UDS-SERVICE-RUN-ACCOUNT-ID UDS-SERVICE-RUN-FILE-NAME UDS-SERVICE-RUN-OPTIONS UDS-SERVICE-RUN-PRIORITY UDS-SERVICE-RUN-PROJECT-ID UDS-SERVICE-RUNID UDS-SERVICE-SAMPLING-PERIOD (default 0, run never starts) UDS-SERVICE-TIMEOUT-PERIOD UDS-SERVICE-USERID

272 Handling Deadlocks (SERVICE Run) If you want to use the SERVICE run, you must alter your system configuration by updating the appropriate fields, installing the new configuration, and making the run active. You might have to take special steps to allow the run to execute continuously. For example, the operating system might cause the run to halt when it reaches its time limit or its limit of standard unit of processing (SUP) usage. Your system must also be configured with Security Option 3 to use the SERVICE run user-id. The SERVICE run user-id must have the UTILITY UDS command privilege. If the run does not have the UTILITY UDS command privilege, the SERVICE run terminates and creates the following error messages on the system console and in the run's print file: SERVICERUN is terminated because it has insufficient security privileges. SERVICERUN userid must have the UTILITY UDS command privilege For more information about setting up the necessary security attributes for your system, see the Repository for ClearPath OS 2200 Programming Reference Manual. Once the run is configured to run continuously, you do not have to maintain it any further. You can, however, change the timeout and sampling periods. You must also intervene if the run terminates Changing Timeout and Sampling Periods You can change the timeout period and the sampling period to meet requirements at your site. Before determining the values for these periods, you should monitor your system. You can analyze the information from several sources: Output from system console keyins UDS trace output with DCS rollback error statistic Listings of runs that terminated in error UDS Control SUDS AE dumps Based on this information, you can determine whether False deadlocks are occurring because the timeout period is too short. Runs are remaining deadlocked too long because the timeout or sampling period, or both, are too long. The run is consuming excessive system resources because its sampling period is too short

273 Handling Deadlocks (SERVICE Run) Determine the timeout period; a reasonable length of time for the longest command executed by runs that cause deadlocks. You might want to increase the timeout period even double it to prevent false deadlocks. Determine the sampling period; the length of time you are willing to wait before deadlocks are detected. Note that the timeout period configured by DSR is actually the timeout period for transaction threads. The timeout run algorithm doubles this configured timeout period for batch and demand threads, and it does not allow a timeout or sampling period longer than 39,600 seconds (11 hours). You can use the PROCESS CONFIGURATION... IMMEDIATE command to change the timeout period and sampling period without reconfiguring or refreshing the application group. The new values remain in effect until they are changed by another PROCESS CONFIGURATION command or the SUDS CF command. Note: Changes made with the SUDS CF command are only effective until the application group is reconfigured or refreshed Restarting the SERVICE Run If the run terminates, use the PROCESS CONFIGURATION... IMMEDIATE command to set sampling period to nonzero and UDSC starts the run. For PROCESS CONFIGURATION RELEASE IMMEDIATE UDS-SERVICE-SAMPLING-PERIOD 10. You can also start the run automatically by using the PROCESS CONFIGURATION... IMMEDIATE UDS-SERVICE-RUN command. For more information about SERVICE run attribute types and the PROCESS CONFIGURATION... IMMEDIATE command, see the Repository for ClearPath OS 2200 Programming Reference Manual

274 Handling Deadlocks (SERVICE Run)

275 Section 11 Using the UDS FILER Utility You can use the UDS FILER utility to move the UDS Exec system files to tape from local or shared mass storage. This section defines the FILER functions and explains the related tasks. The following topics are covered: Accessing FILER Using FILER functions Avoiding rollback errors Customizing FILER Handling errors For related information about installing UDS products, see the Universal Data System Configuration Guide. You cannot use the FILER utility to move UDS/TIP system files from local to shared mass storage. See the Partitioned Applications Planning, Installation, and Operations Guide for information about moving these files Accessing FILER The FILER utility is Symbolic Stream Generator (SSG) based. It is located in the UDS Control UTIL$ file (the first file on the UDS Control release tape). To access this utility, enter the following UDSCUTIL$.,UDS UDSCUTIL$.FILER The default UDS application-qualifier is UDS$$SRC Using FILER Functions Once you have accessed the utility, the system prompts you for the following information: Application group name Application group qualifier Function to perform

276 Using the UDS FILER Utility The utility consists of the following functions: Copy UDS files from LOCAL mass storage TO tape Copy UDS files from SHARED mass storage TO tape Copy UDS files from tape TO LOCAL mass storage Copy UDS files from tape TO SHARED mass storage DELETE all UDS files from LOCAL mass storage DELETE all UDS files from SHARED mass storage The following is some additional information about these functions: Before copying files, functions 1 and 2, first free all the UDS files from the application group by using either the FF function of the SUDS utility or the IRU DOWN command. This means the application must be up and recovered to be successful. Before using functions 3 to 6, free all the UDS files from the application by using the FF function of the SUDS utility. Function 3 catalogs the UDS files on local mass storage before copying them from the tape. Function 4 catalogs the UDS files on shared mass storage before copying them from the tape. You must run functions 3 or 4 to ensure a successful recovery. Functions 1 to 4 request the following: Two tape numbers Tape assign options Tape equipment type Functions 5 and 6 request the number of UDS retention files configured for the application as well as the retention file name. Note: You cannot run IRU short recovery after successful execution of functions 5 or Avoiding Rollback Errors After executing any FILER function, you need to refresh the application group by using the II function of the SUDS utility. This aborts the application group, which then requires an IRU short recovery. If the application group is not aborted and then recovered, threads might receive rollback errors indicating that files were freed without the knowledge of UDS. Note: You must not allow threads to execute in the application group while you are using FILER, and you must not allow them to execute while you are in between FILER functions

277 Using the UDS FILER Utility Customizing FILER The FILER utility assumes that all the UDS system files are non-tip. If this is not true, you must customize the utility to meet site requirements. If you do not want to process TIP/UDS system files with FILER, use the procedures outlined in the Partitioned Applications Planning, Installation, and Operations Guide. To customize FILER, follow these steps: 1. Edit the UDS-FILES element in the UDS Control UTIL$ file. 2. Remove any lines containing files that you do not want affected by FILER, such as UDS/TIP system files. 3. If you are using nonstandard file names for any UDS system files, change the file names in this element to match the nonstandard names. 4. If you want the UDS Exec system files cataloged as private, edit the UDSC- FILEMGR element in the UDS Control UTIL$FILE. Remove the P option from statements. 5. FILER uses SSG to create an addstream to do the processing. If you want to inspect the addstream before SSG adds it, edit the FILER element in the UTIL$ file using the B option on the SSG execution. The output skeleton appears in a temporary file called UDSCTEMP$.SKEL. You must then add the output skeleton or rerun the utility without the B option Handling Errors The FILER utility is designed to perform incremental tasks to ensure recovery if something goes wrong. For this reason, you need to complete each task successfully before moving on to the next step. Even if the task completes successfully, you might see errors recorded in the breakpoint file (depending on the context of the errors). After running each step, check the breakpoint file UDS$*FILEMANAGER for errors Acceptable Errors Following are some examples of acceptable errors that might occur when running the FILER utility. Acceptable errors are those that have no effect on later processing, so no action is necessary when you see the message: The utility is deleting files, and some files are not cataloged. The utility is freeing files, and some files are not assigned. The utility is cataloging files, and some files are already cataloged at an acceptable size

278 Using the UDS FILER Utility Unacceptable Errors Following are some examples of unacceptable errors that might occur when running the FILER utility. Unacceptable errors are those that might cause problems in later processing, so you must correct them when you see the message: A copy of a file to or from tape fails. A file is being cataloged, but one already exists that is an incorrect size

279 Index A abnormal program termination, 5-3 abort incomplete, 6-36 schema, set flag (SA command), 8-30 ABS$ file, 2-26 ABSADT$ file, 2-23 addressing, 1-21 ADT-FILE, 2-22 AE (add error code) command, SUDS, 8-7 alternate print file, FSAH, 2-13 alternate print file, IRU, 2-12 AM (add message) command, SUDS, 8-9 application definition table (ADT), 1-26, 1-28, 2-22, 8-13 application groups aborting, 6-36 configuring, 1-27 default recovery procedures, 6-37 deleting from the ADT (DA command), 8-13 disabling (II command), 8-17 files shared by all AGs, 2-22 used exclusively by AGs, 2-26 intercept and connect routines, 1-8 IRU files files dependent on AGs, 2-16 files used for all AGs, 2-10 preparing dump plans, 2-62 refreshing an idle application group (IL command), 8-18 verifying new dump file cycle creation, 3-9 open audit trail, 3-6 recovery, 3-2 AR command, SUDS (display or clear all entries in RDMS automatic recompile table), 8-10 assigning UDS files, 1-22 audit control files, 2-4, 2-7 audit control, introduced, 1-4 audit trails files, 2-4, 2-7 lost or destroyed file, 6-39 unopened, 6-28 verifying that an application group audit trail is open, 3-6 AUTH$FILE, RDMS, 2-36 automatic recompile table, RDMS, 8-10 B bank addressing, 1-21 bank attributes, listing, 3-10 bank descriptor indexes (BDI), listing, 3-10 C cache management, 1-7, 1-20 cache manager (CAM), 1-7, 1-20 CF command, SUDS (temporarily change SERVICE run configuration parameter), 8-12 CFGSCOD file, 2-28 CFGSDEF file, 2-27 check schema flag, set (CS command), 8-13 commands, SUDS AE (add error code), 8-7 AM (add message), 8-9 AR (display or clear all entries in RDMS automatic recompile table), 8-10 CF (temporarily change SERVICE run configuration parameter, 8-12 CS (set check schema flag), 8-13 DA (delete application group entry), 8-13 DB (display UDS Control D-bank), 8-14 DC (change or display Data Capture state for a schema), 8-14 DE (display errors), 8-14 DL (display locks), 8-15 DM (display message), 8-15 DP (dump UDS banks), 8-15 EX (exit SUDS), 8-16 FF (free file from UDS domain), Index 1

280 Index HE (help), 8-17 HM (change or display hardware/performance monitoring mode), 8-17 II (disable application group), 8-17 IL (refresh application group), 8-18 LD (list dedicated entries), 8-19 LS (list active schemas), 8-19 LU (list active subschemas), 8-21 LV (display UDS Control level), 8-21 MB (modify batch/demand lock threshold), 8-22 MT (modify transaction lock threshold), 8-22 OC (override clear), 8-23 OD (override display), 8-23 OS (override set), 8-23 RC (list status of registered threads), 8-24 RE (remove error code), 8-27 RL (list active steps), 8-28 RM (remove message), 8-29 RS (change RLP scan times for ADT/IRU, 8-30 RU (list status of registered threads), 8-24 SA (set schema abort flag), 8-30 SC (clear schema abort flag), 8-31 summary (table), 8-6 UM (display count of discarded UDS broadcast messages), 8-31 coordinating message recovery, 2-12 CS (set check schema flag) command, SUDS, 8-13 D D$MR file, DMS, 2-39 DA (delete application group entry) command, SUDS, 8-13 Data Capture described, 1-11 displaying or changing Data Capture state (DC command), 8-14 Data Manipulation Language (DML), 1-10 database inconsistencies, 6-33 software products Network Database Server (DMS), 1-11 Relational Database Server (RDMS), 1-11 Repository for ClearPath OS 2200 (UREP), 1-26 Shared File System (SFS), 1-12 UDS Control, 1-5 UDS products, 1-5 DB (display UDS Control D-bank) command, SUDS, 8-14 D-banks problems acquiring a D-bank for a program, 6-21 problems acquiring program space from a UDS D-bank, 6-23 DC (change or display Data Capture state) command, SUDS, 8-14 DC command, SUDS (See also Data Capture) DDL$ file, UREP, 2-46 DDL$QLP file, DMS, 2-40 DDL$SCH file, DMS, 2-40 DDL$SCR file, DMS, 2-40 DDL$SREC file, DMS, 2-40 DDL$SSREC file, DMS, 2-40 DDL$SUB file, DMS, 2-40 DE (display errors) command, SUDS, 8-14 deadlocks, resolving, 10-1 dedicated entries, list (LD command), 8-19 dedicated files, 1-22 DEP$FILE, RDMS, 2-36 DIAG$ file, 2-14 Distributed Transaction Processing (DTP) model, 1-17 DL (display locks) command, SUDS, 8-15 DM (display message) command, SUDS, 8-15 DMP$PF file, 2-13 DMR trace, 7-32 trace file items, 7-32 DMRMT$ file, DMS, 2-38 DMS (See Network Database Server) DMS$UTIL file, DMS, 2-39 DMSLIB$ file, DMS, 2-38 DOWN command, IRU, disabling UDS files and pages, 1-24 DP (dump UDS banks) command, SUDS, 8-15 Dump Analysis Procedure (DAP), 4-12 DUMPER runstream, 4-4 dumps DUMPER runstream, 4-4 dumping the UDS Control D-bank (DB command), 8-14 dumping UDS D-banks (DP command), 8-15 history file information, reporting, 3-12 IRU dump files, 2-13, 2-14 IRU dump history files, 2-16 new file cycle, verifying, 3-9 Index

281 Index E preparing dump plans, 2-62 processing UDS dumps, 4-1, 4-3 selective processing, 4-10 tapes, creating and maintaining, 2-64 UDS Control dump files, 2-28 UDS dump file format, 4-13 UREP dump files, 2-49 ECM$FILE, 2-34 EEAM$FILE, 2-34 errors adding an error code (SUDS AE command), 8-7 contingency errors, 5-4 displaying (DE command), 8-14 handling UDS errors, 5-4 internal errors, 5-5 recovery procedural errors, 6-34 removing an error code (RE command), 8-27 events logging UDS events, 3-5 EX (exit SUDS) command, 8-16 Exec audit control files, 2-4, 2-7 introduced, 1-4 control software, 1-3 files, 1-25 step control files, 2-2 introduced, 1-3 Extended Transaction Capacity (XTC), 6-29 F fast search, 6-16 FDT$ file, UREP, 2-44 FF (free file from UDS domain) command, SUDS, 8-16 file description table (FDT), 1-26 file descriptor tables (FDT$ files) properties and usage, 2-44 reporting status of files with FDTs, 3-12 files application groups default UDS application group files for processors, 2-59 files shared by all AGs, 2-22 files used exclusively by AGs, 2-26 assigning UDS files, 1-22 assignment conflict, 6-3 audit trail file lost or destroyed, 6-39 categories of UDS files, 2-1 dedicated files, 1-22 disabled, 6-7 DMS files D$MR$, 2-39 DDL$QLP, 2-40 DDL$SCH, 2-40 DDL$SCR, 2-40 DDL$SREC, 2-40 DDL$SSREC, 2-40 DDL$SUB, 2-40 default application group files, 2-55 DMRMT$, 2-38 DMS$UTIL, 2-39 DMSLIB$, 2-38 SYS-CHG-FILE, 2-42 dump files IRU, 2-13, 2-14 tapes, creating and maintaining, 2-64 UDS Control, 2-28 UDS dump format, 4-13 UREP, 2-49 Exec and TIP files, 1-25 Exec files audit control files, 2-4, 2-7 rollback page file, 2-8 step control (periodic savefile), 2-2 file assignment limits, 2-50 file descriptor tables (FDT$ files), reporting status of files, 3-12 file management, 1-22 freeing files from the UDS domain (FF command), 8-16 freeing UDS files, 1-24 I/O errors, 6-8, 6-11, 6-16 IRU files default application group files, 2-52 DIAG$ file, 2-14 dump files, 2-13, 2-14 FSAH alternate print file, 2-13 IRU alternate print file, 2-12 IRU$DH, 2-16 IRU$PFrun, 2-15 medium recovery files, 2-20 move history files, 2-17, 2-18 short recovery files, 2-21 SYS$*MCB, 2-11 SYS$LIB$*ALTFSAH, Index 3

282 Index SYS$LIB$*FSAH, 2-11 SYS$LIB$*IRU, 2-10 lost/not cataloged, 6-10 monitoring files in the UDS environment, 3-14 new cycle in dump,verifying, 3-9 product files, backing up, 2-2 qualifiers, recommended, for application groups, 2-1 RDMS files AUTH$FILE, 2-36 default application group files, 2-54 DEP$FILE, 2-36 ECM$FILE, 2-34 EEAM$FILE, 2-34 FRDT$FILE, 2-34 LOB$SA$FILE, 2-36 NULL$FILE, 2-36 PARAMS$FILE, 2-36 PART$FILE, 2-36 RDM$DROPFILE, 2-36 RDT$FILE, 2-34 ROUTINE$FILE, 2-36 SCH$FILE, 2-36 STATS$FILE, 2-36 SYS$LIB$*RDMS, 2-32 SYS$LIB$*RSA, 2-34 TRIG$FILE, 2-36 TRIGCOL$FILE, 2-36 VIEWDEP$FILE, 2-36 recovery types and procedures, 2-63 retention files, 2-29, 6-40 rolled out, 6-2 savefile lost or destroyed, 6-37 security security violations, 6-4 TeamQuest SIMAN, 3-13 SFS files default application group file, 2-57 SYS$LIB$*SFS file, 2-49 trace files, UDS Control, 2-31 UDS Control files ABS$ file, 2-26 ABSLIB$, 2-28 default application group files, 2-52 dump files, 2-28 retention files, 2-29 SYS-FILE, 2-30 TRACEFILE, 2-31 UDS$$SRC*ABSADT$ file, 2-23 UDS$$SRC*ADT-FILE, 2-22 UDS$$SRC*CFGSCOD, 2-28 UDS$$SRC*INTERFACESEC file, 2-25 UDS$$SRC*RUBSECURITY, 2-25 UDS$$SRC*SECURE-FILE, 2-24 UDS$$SRC*UREP$BDI, 2-24 UDSC$CFGSDEF, 2-27 UDSC$PFGSCOD, 2-27 UDSC$PFGSDEF, 2-27 UTIL$, 2-31 UDS product system files, summary, 2-58 UREP files DDL$, 2-46 default application group files, 2-56 FDT$, 2-44 SECURE-UREP, 2-48 SYS$LIB$*UREP, 2-43 UREP$A$TYPES, 2-45 UREP$ABSD, 2-47 UREP$ABSLIB, 2-47 UREP$ACL, 2-45 UREP$DUMP, 2-49 UREP$E$TYPES, 2-45 UREP$EA, 2-45 UREP$EA$DESC, 2-45 UREP$EA$QEN, 2-45 UREP$ELMSABS, 2-48 UREP$ENT, 2-45 UREP$ENT$ORD, 2-45 UREP$ENTNAME, 2-45 UREP$ME, 2-45 UREP$ME$ID, 2-45 UREP$ME$NAME, 2-45 UREP$NAME$ID, 2-45 UREP$QEN, 2-45 UREP$R$TYPES, 2-45 UREP$RA, 2-45 UREP$RA$DESC, 2-45 UREP$RA$QEN, 2-45 UREP$REL$ORD, 2-45 UREP$RELA, 2-45 UREP$UTIL, 2-43 FRDT$FILE, 2-34 freeing UDS files, 1-24 FSAH$VIEW file, 2-13 H hardware performance monitoring (HM command), 8-17 HE (help) command, SUDS, 8-17 history files, backup dumps, reporting, 3-12 Index

283 Index HM (change or display hardware/performance monitoring mode) command, SUDS, 8-17 I II (disable application group) command, SUDS, 8-17 IL (refresh application group) command, SUDS, 8-18 Integrated Recovery Utility (IRU) default application group files, 2-52 files files dependent on application groups, 2-16 files used for all application groups, 2-10 history files, reporting, 3-12 UP and DOWN commands, 1-24 introduced, 1-5 intercept and connect routines (ICR), 1-7, 1-8 INTERFACESEC file, 2-25 IOMAX, 6-16 IRU files IRU$PFrun, 2-15 key files, 2-19 medium recovery files, 2-20 move history files, 2-17, 2-18 short recovery files, 2-21 IRU$*MED$REC$ files, 2-20 IRU$DH file, 2-16 IRU$KF file, 2-19 IRU$MH file, 2-17 K key files, IRU, 2-21 L LD (list dedicated entries) command, SUDS, 8-19 LOB$SA$FILE, RDMS, 2-36 locking subsystem, 1-18 locking subsystem/queuing and deadlock protection (LSS/QAD), 1-7 locks displaying (DL command), 8-15 MAX-LOCKS-BATCH, modifying (MB command), 8-22 MAX-LOCKS-TRANSACTION, modifying (MT command), 8-22 logging UDS events, 3-5 logical data managers (LDM), 1-7, 1-10 LS (list active schemas) command, SUDS, 8-19 LU (list active subschemas) command, SUDS, 8-21 LV (display UDS Control level) command, SUDS, 8-21 M MB (modify batch/demand lock threshold) command, SUDS, 8-22 memory management, 1-21 messages AM (add message) command, SUDS, 8-9 changing or translating UDS messages, 5-9 display count of discarded messages (UM command), 8-31 RM (remove message) command, SUDS, 8-29 UDS Control messages, 5-6 UDS$$SRC*UTIL$MESSAGES, 5-12 unanswered console messages, 6-28 monitoring file security status, 3-13 files in the UDS environment, 3-14 threads, 3-8 move history files, IRU, 2-17, 2-18 MT (modify transaction lock threshold) command, SUDS, 8-22 N Network Database Server (DMS) Data Manipulation Language (DML), 1-10 default application group files, 2-55 described, 1-11 files, 2-38 NULL$FILE, RDMS, Index 5

284 Index O OC (override clear) command, SUDS, 8-23 occurrence count statistics, RDMS, 7-27 OD (override display) command, SUDS, 8-23 Open Distributed Transaction Processing (Open/OLTP), 1-17 OS (override set) command, SUDS, 8-23 P PARAMS$FILE, RDMS, 2-36 PART$FILE, RDMS, 2-36 periodic savefile, 2-2 PFGSCOD file, 2-27 PFGSDEF file, 2-27 PMD$PF file, 2-14 product files, backing up, 2-2 programs abnormal termination, 5-3 failing while executing, 6-2 invalid input, 6-33 queued trying to start session, 6-25 within session, 6-26 session, not establishing, 6-36 stalled, 6-25 termination abnormal, 5-3 external, 6-31 instructions, 5-2 waiting for file assignment, 6-30 with questionable data, 6-33 Q qualifiers, recommended, 2-1 queuing subsystem, 1-18 R RC (list status of registered threads) command, SUDS, 8-24 RDM$DROPFILE, RDMS, 2-36 RDMS (See Relational Database Server) RDMS$CFGSCOD file, 2-32 RDMS$CFGSDEF files, 2-33 RDMSLIB files, 2-33 RDT$FILE, 2-34 RE (remove error code) command, SUDS, 8-27 recovery default recovery procedures, 6-37 Integrated Recovery Utility (IRU), 1-5 procedural errors, 6-34 short failed, 6-40 successful but with database file problem, 6-41 types and procedures, 2-63 verifying application group recovery, 3-2 relation description table (RDT), 1-26 Relational Database Server (RDMS) clearing the automatic recompile table (AR command, SUDS), 8-10 database file inconsistencies, resolving, 6-35 default application group files, 2-54 files, 2-32 introduced, 1-11 occurrence count statistics, 7-27 statement count statistics, 7-24 Structured Query Language (SQL), 1-10 Repository for ClearPath OS 2200 (UREP) default application group files, 2-56 files, 2-43 overview, 1-26 verifying access to UDS, 3-7 retention files, 2-29, 6-40 RL (list active steps) command, SUDS, 8-28 RM (remove message) command, SUDS, 8-29 rollback page file, 2-8 ROUTINE$FILE, RDMS, 2-36 RS (change RLP scan times) command, SUDS, 8-30 RSA files, 2-34 RU (list status of registered threads) command, SUDS, 8-24 RUBSECURITY file, 2-25 S SA (set schema abort flag) command, SUDS, 8-30 savefile, lost or destroyed, 6-37 SC (clear schema abort flag) command, SUDS, 8-31 SCH$FILE, RDMS, 2-36 Index

285 Index schemas abort flag clear (SC command), 8-31 set (SA command), 8-30 check flag, set (CS command), 8-13 list active schemas (LS command), 8-19 SECURE-FILE, 2-24 SECURE-UREP file, 2-48 Security Option 3 divisions and file names, 9-6 library, subsystems, 9-3 subsystems accessing, 9-3 creating, 9-5 introduction to, 9-2 requirements, summary, 9-5 UDS untrusted, 9-2 security, file events log, 9-8 using SIMAN to report security status, 3-13 SERVICE run configuration parameters, changing (SUDS CF command), 8-12 resolving deadlocks with, 10-1 SFSLIB file, 2-49 Shared File System (SFS) default application group file, 2-57 described, 1-12 files, 2-49 short recovery failed, retention file problem, 6-40 successful, but database file problem, 6-41 SIMAN, 3-13 statement count statistics, RDMS, 7-24 statistics RDMS occurrence counts, 7-27 RDMS statement counts, 7-24 STATS$FILE, RDMS, 2-36 step control files, 2-2 introduced, 1-3 steps, list active (RL command), 8-28 storage record manager (SRM), 1-7, 1-10 Structured Query Language (SQL), 1-10 subschemas, displaying (LU command), 8-21 SUDS AE command (add error code), 8-7 AM command (add message), 8-9 AR command (display or clear all entries in RDMS automatic recompile table), 8-10 CF command (temporarily change SERVICE run configuration parameter), 8-12 commands (table), 8-6 CS command (set check schema flag), 8-13 DA command (delete application group entry), 8-13 DB command (display UDS Control D-bank), 8-14 DC command (change or display Data Capture state for a schema), 8-14 DE command (display errors), 8-14 DL command (display locks), 8-15 DM command (display message), 8-15 DP command (dump UDS banks), 8-15 EX command (exit SUDS), 8-16 executing SUDS, 8-1 FF command (free file from UDS domain), 8-16 HE command (help), 8-17 HM command (change or display hardware/performance monitoring mode), 8-17 II command (disable application group), 8-17 IL command (refresh application group), 8-18 LD command (list dedicated entries, 8-19 LS command (list active schemas), 8-19 LU command (list active subschemas), 8-21 LV command (display UDS Control level), 8-21 MB command (modify batch/demand lock threshold), 8-22 MT command (modify transaction lock threshold), 8-22 OC command (override clear), 8-23 OD command (override display), 8-23 OS command (override set), 8-23 RC command (list status of registered threads), 8-24 RE command (remove error code), 8-27 RL command (list active steps), 8-28 RM command (remove message), 8-29 RS command (change RLP scan times for ADT/IRU, 8-30 RU command (list status of registered threads), 8-24 SA command (set schema abort flag), Index 7

286 Index SC command (clear schema abort flag), 8-31 SUDS execution options, 8-3 UM command (display count of discarded UDS broadcast messages), 8-31 SYS$*MCB file, 2-11 SYS$LIB$*ALTFSAH file, 2-11 SYS$LIB$*FSAH file, 2-11 SYS$LIB$*IRU file, 2-10 SYS$LIB$*RDMS file, 2-32 SYS$LIB$*RDMS$CFGSCOD file, 2-32 SYS$LIB$*RSA file, 2-34 SYS$LIB$*SFSLIB file, SFS, 2-49 SYS$LIB$*UREP file, 2-43 SYS-CHG-FILE, DMS, 2-42 SYS-FILE, UDS Control, 2-30 system file (SYS-FILE), 1-26 T table control system (TCS), 1-7, 1-20 TeamQuest Online System Activity Monitor (OSAM), 8-32 SIMAN, 3-13 Transaction Performance Auditing System (TPAS), 8-32 threads DPS/MCB with multiple INITAL commands, 1-15 implicit DMS/MCB and DMS/DPS/MCB programs, 1-16 list status of registered threads (RC/RU commands), 8-24 MCB with multiple INITAL commands, 1-13 monitoring active threads with SUDS, 3-8 TCL, 1-7 thread control, described, 1-12 TPAS, UDSC-TPAS facility statistics, 8-32 TRACEFILE, UDS Control, 2-31 Transaction Processing (TIP) files, 1-25 TRCCTL program calling, 7-2 introduction to, 7-1 options, 7-2 output, 7-6 search constraints, 7-5 statistics, 7-7 TRIG$FILE, RDMS, 2-36 TRIGCOL$FILE, RDMS, 2-36 U UDS (See Universal Data System) UDS Control cache management, 1-20 default application group files, 2-52 dumping the UDS Control D-bank, 8-14 file management, 1-22 internal tables, 1-26 introduced, 1-5 level, displaying (LV command), 8-21 memory management, 1-21 messages, 5-6 protected subsystem, 3-13, 6-4 verifying access to UDS, 3-7 UDS Control files AB$, 2-26 ABSLIB$, 2-28 UDS$$SRC*ABSADT$ file, 2-23 UDS$$SRC*ADT-FILE, 2-22 UDS$$SRC*CFGSCOD, 2-28 UDS$$SRC*INTERFACESEC file, 2-25 UDS$$SRC*RUBSECURITY, 2-25 UDS$$SRC*SECURE-FILE, 2-24 UDS$$SRC*UREP$BDI, 2-24 UDSC$CFGSDEF, 2-27 UDSC$PFGSCOD, 2-27 UDSC$PFGSDEF, 2-27 UDS D-banks, dumping (DP command), 8-15 UDS$$SRC*ABSADT$ file, 2-23 UDS$$SRC*ADT-FILE, 2-22 UDS$$SRC*INTERFACESEC file, 2-25 UDS$$SRC*RUBSECURITY file, 2-25 UDS$$SRC*SECURE-FILE, 2-24 UDS$$SRC*UREP$BDI file, 2-24 UM (display count of discarded UDS broadcast messages) command, SUDS, 8-31 Universal Data System (UDS) cache management, 1-20 components, 1-7 file management, 1-22 locking subsystem, 1-18 memory management, 1-21 Network Database Server (DMS), 1-11 products, 1-5 queuing subsystem, 1-18 Relational Database Server (RDMS), 1-11 Shared File System (SFS), 1-12 table control system (TCS), 1-20 UDS Control, 1-5 Index

287 Index UP command, IRU, enabling UDS files and pages, 1-24 UREP$A$TYPES file, 2-45 UREP$ABSD file, 2-47 UREP$ABSLIB file, 2-47 UREP$ACL file, 2-45 UREP$BDI file, 2-24 UREP$DUMP file, 2-49 UREP$E$TYPES file, 2-45 UREP$EA file, 2-45 UREP$EA$DESC file, 2-45 UREP$EA$QEN file, 2-45 UREP$ELMSABS file, 2-48 UREP$ENT file, 2-45 UREP$ENT$ORD file, 2-45 UREP$ENTNAME file, 2-45 UREP$ME file, 2-45 UREP$ME$ID file, 2-45 UREP$ME$NAME file, 2-45 UREP$NAME$ID file, 2-45 UREP$QEN file, 2-45 UREP$R$TYPES file, 2-45 UREP$RA file, 2-45 UREP$RA$DESC file, 2-45 UREP$RA$QEN file, 2-45 UREP$REL$ORD file, 2-45 UREP$RELA file, 2-45 UREP$UTIL file, 2-43 UTIL$ file, 2-31 V VIEWDEP$FILE, RDMS, 2-36 X XTC (See Extended Transaction Capacity) Index 9

288 Index Index

289 .

290 2013 Unisys Corporation. All rights reserved. * *