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