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

(1)

unisys

ClearPath Enterprise Servers

Universal Data System

Administration and Support Reference Manual

Level 18R1

(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.

(3)

1.1. About This Manual ... 1–1 1.2. Documentation Updates ... 1–3 1.3. Exec Control Software ... 1–3 1.3.1. Exec Step Control ... 1–3 1.3.2. Exec Audit Control ... 1–4 1.4. Integrated Recovery Utility (IRU) ... 1–5 1.5. Universal Data System Products ... 1–5 1.6. The UDS Online Data Manager: UDSControl ... 1–5 1.7. UDS Components ... 1–7 1.8. Intercept and Connect Routines ... 1–8 1.9. Logical Data Managers and Storage Record

Managers ... 1–10 1.9.1. Relational Data Model—RDMS ... 1–11 1.9.2. Network Data Model—DMS ... 1–11 1.9.3. Shared File Model—SFS ... 1–12 1.10. Thread Control ... 1–12 1.10.1. MCB with Optional Multiple INITAL Commands ... 1–13 1.10.2. DPS/MCB with Optional Multiple INITAL

Commands ... 1–15 1.10.3. Implicit DMS/MCB and DMS/DPS/MCB

Programs ... 1–16 1.10.4. Distributed Transaction Processing ... 1–17 1.11. Locking ... 1–18 1.12. Queuing ... 1–18 1.13. Table Control System ... 1–20 1.14. Cache Management ... 1–20 1.15. Memory Management ... 1–21 1.15.1. Addressing ... 1–21 1.15.2. Dedicated Files ... 1–22 1.16. File Management ... 1–22 1.16.1. Assigning UDS Files ... 1–22 1.16.2. Freeing UDS Files ... 1–24 1.16.3. Enabling and Disabling UDS Files and Pages ... 1–24 1.16.4. Exec and TIP Files... 1–25 1.16.5. Using TIP Files ... 1–25 1.17. Role of the Repository (UREP) ... 1–26 1.18. Application Groups ... 1–27 1.18.1. Application Definition Table ... 1–28 1.18.2. ADT Alias List ... 1–29 1.18.3. Active ADT List ... 1–29

(4)

Contents

Section 2. Files Used in the UDS Environment

2.1. Categories of Files ... 2–1 2.2. Files Used by the Exec ... 2–2 2.2.1. Step Control File ... 2–2 2.2.2. Audit Control Files ... 2–4 2.3. Files Used by IRU ... 2–10 2.3.1. IRU Files Used for All Application Groups ... 2–10 2.3.2. IRU Files Dependent on Application Groups... 2–16 2.4. Files Shared by All Application Groups ...2–22 2.5. Files Used Exclusively by Each Application Group ... 2–26 2.5.1. UDS Control Files ... 2–26 2.5.2. RDMS Files ... 2–32 2.5.3. DMS Files ... 2–38 2.5.4. UREP Files ... 2–43 2.5.5. SFS File ... 2–49 2.6. File Assignment Limits ... 2–50 2.7. Summary of Files and Characteristics ... 2–50 2.7.1. Executive Control Files ... 2–50 2.7.2. Default Product Files ... 2–51 2.7.2.1. IRU Files ... 2–52 2.7.2.2. UDS Control Files ... 2–52 2.7.2.3. RDMS Files ... 2–54 2.7.2.4. DMS Files ... 2–55 2.7.2.5. UREP Files ... 2–56 2.7.2.6. SFS Files ... 2–57 2.7.2.7. Storage Areas and User Files... 2–57 2.7.2.8. Summary of Product System Files ... 2–58 2.7.3. Processor Files... 2–59 2.8. Preparing a Dump Plan ... 2–62 2.8.1. Recovery Types and Procedures ... 2–63 2.8.2. Creating and Maintaining Dump Tapes ... 2–64

Section 3. Monitoring UDS During Normal Operations

3.1. Verifying Recovered and Active Application Group ... 3–2 3.2. Logging UDS Events ...3–5 3.3. Verifying Open Audit Trail for Application Group ... 3–6 3.4. Verifying Access to UDS ... 3–7 3.5. Monitoring Status of Active Threads ... 3–8 3.6. Verifying Creation of New Cycle of Application

Group Dump File ... 3–9 3.7. Listing BDIs and Bank Attributes ... 3–10 3.8. Displaying Status of UDS Files with FDTs ... 3–12 3.9. Reporting IRU History File Information ... 3–12 3.10. Determining File Security Status ... 3–13 3.11. Using a Runstream to Check UDS Files Periodically ... 3–14

Section 4. Processing UDS Dumps

(5)

Contents

4.2. Processing Dumps ... 4–3 4.2.1. Using the DUMPER Runstream ... 4–4 4.2.2. Selective Dump Processing ... 4–10 4.3. DAP Functions ... 4–12 4.4. Dump File Format ... 4–13 4.5. Dumping the ADT Bank ... 4–15

Section 5. Terminating Programs and Handling Errors

5.1. Idling UDS Application Groups ... 5–1 5.2. Terminating Programs ... 5–2 5.3. Abnormal Program Termination ...5–3 5.4. Handling UDS Errors ... 5–4 5.4.1. Contingency Errors ... 5–4 5.4.2. Internal Errors ...5–5 5.5. UDS Control Messages ... 5–6 5.5.1. Message Format ... 5–8 5.5.2. Scope and Impact of Errors ... 5–8 5.5.3. Error Message Generation... 5–8 5.6. Message Text ... 5–9 5.6.1. Syntax ... 5–9 5.6.2. Changing and Translating ... 5–9 5.6.3. Locating Messages ... 5–12

Section 6. Recognizing and Correcting Abnormal Conditions

6.1. Abnormal Condition Categories ... 6–1 6.2. UDS Is Accessible: Programs Fail While Executing ... 6–2 6.2.1. Problem: Files ... 6–2 6.2.1.1. File Unavailable (Rolled Out) ... 6–2 6.2.1.2. File Unavailable (Assignment Conflicts) ... 6–3 6.2.1.3. File Unavailable (Security Violation) ... 6–4 6.2.1.4. Retention File Unavailable (Disabled) ... 6–6 6.2.1.5. File Unavailable (Disabled) ... 6–7 6.2.1.6. File Unavailable (I/O Errors) ... 6–8 6.2.1.7. File Unavailable (Lost or No Longer

Cataloged) ... 6–10 6.2.1.8. Files Cannot Be Expanded (Special Case

I/O Error) ... 6–11 6.2.1.9. File Unavailable (I/O Errors in IOMAX

Subsystem) ... 6–16 6.2.2. Problem: Deadlocks ... 6–16 6.2.3. Problem: UDSC Basic Mode to Extended Mode

Transition Failure ... 6–17 6.2.4. Problem: UDSC$PFGSDEF File Causes DMS

Control Failure ... 6–19 6.2.5. Problem: Memory Limit Quota Exceeded ... 6–20 6.2.6. Problem: System Cannot Acquire a D-Bank ... 6–21 6.2.7. Problem: Inability to Acquire Space in a UDS

(6)

Contents

6.3.1. Problem: Programs Queued ... 6–25 6.3.1.1. Programs Queued Trying to Start UDS

Session ... 6–25 6.3.1.2. Programs Queued Within UDS Session ... 6–26 6.3.2. Problem: Unable to Initialize Because of

Encryption D-Bank Error ... 6–28 6.3.3. Problem: Unanswered System Console

Messages (Unopened Audit Trail) ... 6–28 6.3.4. Problem: Unable to Reconfigure XTC

Environment... 6–29 6.3.5. Problem: Programs Waiting for File

Assignment ... 6–30 6.3.6. Problem: Programs Externally Terminated ... 6–31 6.4. UDS Is Accessible: Database Seems Inconsistent ... 6–33 6.4.1. Problem: Programs Reporting Questionable

Data ... 6–33 6.4.1.1. Program Error: Invalid Program Input ... 6–33 6.4.1.2. Recovery Procedural Errors ... 6–34 6.4.2. Resolving RDMS Database File Inconsistencies ... 6–35 6.5. Programs Cannot Establish UDS Session ... 6–36 6.5.1. Problem: Incomplete Abort of Application

Group ... 6–36 6.5.2. Problem: Application Group Recovery Failing ... 6–37 6.5.2.1. Savefile Lost or Destroyed ... 6–37 6.5.2.2. Audit Trail File Lost or Destroyed ... 6–39 6.5.2.3. Short Recovery Fails: Retention File

Problem ... 6–40 6.5.2.4. Short Recovery Successful but Database

File Problem Exists ... 6–41

Section 7. Monitoring Performance and Diagnosing Problems

7.1. Trace Control Functions ... 7–1 7.2. Calling the Trace Control Program (TRCCTL) ... 7–2 7.3. TRCCTL Options ... 7–2 7.4. Trace Components ... 7–4 7.5. Search Constraints ... 7–5 7.6. Trace Output ... 7–6 7.7. TRCCTL Examples ... 7–7 7.7.1. Example 1 ... 7–7 7.7.2. Example 2 ... 7–20 7.8. Meaning of RDMS Statistics ... 7–24 7.9. DMR Trace ... 7–32

Section 8. Monitoring and Analyzing UDS Control

8.1. Executing SUDS ... 8–1 8.2. SUDS Options... 8–3 8.3. Demand and Batch Examples ... 8–3 8.3.1. Demand Mode Examples ... 8–3 8.3.2. Batch Mode Examples ... 8–4

(7)

Contents

8.4. SUDS Commands ... 8–6 8.4.1. Add Error Code (AE) ...8–7 8.4.2. Add Message (AM) ... 8–9 8.4.3. Display or Clear All Entries in RDMS Automatic

Recompile Table (AR) ... 8–10 8.4.4. Temporarily Change SERVICE Run Configuration

Parameter (CF)... 8–12 8.4.5. Set Check Schema Flag (CS) ... 8–13 8.4.6. Delete Application Group Entry (DA) ... 8–13 8.4.7. Display UDS Control D-Bank (DB) ...8–14 8.4.8. Change or Display the Data Capture State for a

Schema (DC) ...8–14 8.4.9. Display Errors (DE) ...8–14 8.4.10. Display Locks (DL) ... 8–15 8.4.11. Display Message (DM) ... 8–15 8.4.12. Dump UDS D-Banks (DP)... 8–15 8.4.13. Exit SUDS (EX) ... 8–16 8.4.14. Free File from UDS Domain (FF) ... 8–16 8.4.15. Help (HE) ... 8–17 8.4.16. Change or Display the Hardware/Performance

Monitoring Mode (HM) ... 8–17 8.4.17. Disable Application Group (II) ... 8–17 8.4.18. Refresh Application Group (IL) ... 8–18 8.4.19. List Dedicated Entries (LD) ... 8–19 8.4.20. List Active Schemas (LS) ... 8–19 8.4.21. List Active Subschemas (LU) ... 8–21 8.4.22. Display UDS Control Level (LV) ... 8–21 8.4.23. Modify Batch/Demand Lock Threshold (MB) ... 8–22 8.4.24. Modify Transaction Lock Threshold (MT) ... 8–22 8.4.25. Override Clear (OC) ... 8–23 8.4.26. Override Display (OD) ... 8–23 8.4.27. Override Set (OS) ... 8–23 8.4.28. List Status of Registered Threads (RC/RU) ... 8–24 8.4.29. Remove Error Code (RE) ... 8–27 8.4.30. List Active Steps (RL) ... 8–28 8.4.31. Remove Message (RM) ... 8–29 8.4.32. Change RLP Scan Times for ADT/IRU (RS) ... 8–30 8.4.33. Set Schema Abort Flag (SA) ... 8–30 8.4.34. Clear Schema Abort Flag (SC) ... 8–31 8.4.35. Display Count of Discarded UDS Broadcast

Messages (UM) ... 8–31 8.5. TeamQuest Transaction Performance Auditing

System (TeamQuest TPAS) ... 8–32 8.6. TeamQuest Online System Activity Monitor

(TeamQuest OSAM) ... 8–32 8.7. Database Event Reporting ... 8–33

(8)

Contents

9.3. Subsystems ... 9–2 9.3.1. UDS Untrusted Subsystems ... 9–2 9.3.2. Library Subsystem ... 9–3 9.3.3. Trusted Subsystems ... 9–3 9.3.4. Accessing Subsystems ... 9–3 9.3.5. UDS Control Command Privileges ... 9–4 9.4. Creating UDS Subsystems... 9–5 9.5. Summary: UDS Subsystem Requirements ... 9–5 9.6. File Names and Subsystem Divisions ... 9–6 9.7. UDS Control Security Events Log ... 9–8

Section 10. Handling Deadlocks (SERVICE Run)

10.1. How the SERVICE Run Works ... 10–1 10.2. Changing Timeout and Sampling Periods ... 10–2 10.3. Restarting the SERVICE Run ... 10–3

Section 11. Using the UDS FILER Utility

11.1. Accessing FILER ... 11–1 11.2. Using FILER Functions ... 11–1 11.3. Avoiding Rollback Errors ... 11–2 11.4. Customizing FILER ... 11–3 11.5. Handling Errors ... 11–3 11.5.1. Acceptable Errors ... 11–3 11.5.2. Unacceptable Errors ... 11–4

(9)

Figures

1–1. UDSControl Configuration ... 1–7 1–2. Role of Intercept and Connect Routine ... 1–8 1–3. Multiple Application Groups in UDS ... 1–9 1–4. Using MCB with UDS ... 1–14 1–5. DMS and DPS/MCB with Multiple MCB INITAL Commands ... 1–15 1–6. DMS Implicit Thread Control Flow with MCB ... 1–16 1–7. DMS Implicit Thread Control with DPS/MCB ... 1–17 1–8. Distributed Transaction Processing ... 1–17 1–9. Cache Manager ... 1–20 1–10. UDS Domains ... 1–23 1–11. UREP-UDS Relationship ... 1–27 1–12. ADT Lists Relationships ... 1–28

(10)

(11)

Tables

2–1. Executive Control Files ... 2–50 2–2. Default IRU Application Group Files ... 2–52 2–3. Default UDS Control Application Group Files ... 2–52 2–4. Default RDMS Application Group Files ... 2–54 2–5. Default DMS Application Group Files ... 2–55 2–6. Default UREP Application Group Files ... 2–56 2–7. Default SFS Application Group Files ... 2–57 2–8. Default Application Group Files ... 2–57 2–9. Summary of Product System Files ... 2–58 2–10. Default Application Group Files for Processors ... 2–60 4–1. DAP Functions Supplied by UDS ... 4–12 5–1. Contingency Error Result ... 5–4 5–2. Types of UDS Control Messages... 5–6 5–3. Description of UDS Control Messages by Type ... 5–7 7–1. TRCCTL Trace Components ... 7–4 7–2. UDS Trace Levels ... 7–5 7–3. TRCCTL Option 4 Search Dimensions ... 7–5 7–4. RDMS Statement Count Statistics ... 7–24 7–5. RDMS Occurrence Count Statistics ... 7–28 7–6. Trace File Items for DMR Trace ... 7–32 8–1. SUDS Commands ... 8–6 9–1. UDS Product Event Logging Entry Types ... 9–8

(12)

(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.

1.1. 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 example: @uds$$src*abs$.suds

• 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

(15)

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.

1.2. 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) 18884968. To obtain a copy of the PLE, contact your Unisys service representative or access the current PLE from the Unisys Product Support Web site:

http://www.support.unisys.com/all/ple/18884968

Note: If you are not logged into the Product Support site, you will be asked to do so.

1.3. 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.

1.3.1. 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)

(16)

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.

1.3.2. 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)

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.

1.5. 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.

1.6. 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

(18)

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.

(19)

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 Intercept and connect routine

LDM Logical data manager (RDMS, DMS, or SFS)

SRM Storage record manager, the component of an LDM that understands file formats

CAM Cache manager

LSS/QAD Locking subsystem/queuing and deadlock detection

TCL Thread control

TCS Table control system

(20)

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)

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).

(22)

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)

1.9.1. 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.

1.9.2. 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)

1.9.3. 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.

1.10. 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)

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 1.18.2).

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.

1.10.1. 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

(26)

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 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. TERMN8 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)

1.10.2. 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 Makes the program known to DPS. DPS also calls MCB, which

performs the operations described for MCB INITAL (see 1.10.1). 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.

D$CLOSE Writes a terminal close record. Next, DPS calls MCB to perform the MCB TERMN8 command processing described in 1.10.1. 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)

1.10.3. 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 1.10.2, 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.

(29)

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

1.10.4. 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.

(30)

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.

1.11. 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.

1.12. 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)

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 The thread that consumes the least number of standard units of processing (SUP) is selected for rollback processing.

UPDATES The thread that makes the least number of updates is selected for rollback processing. PRIORITY 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 • Section10

(32)

1.13. 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.

1.14. 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.

(33)

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

1.15. 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.

1.15.1. 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.

(34)

1.15.2. 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.

1.16. 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.

1.16.1. 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)

Figure 1–10 illustrates UDS domains.

Figure 1–10. 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 an @ASG,AZ 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)

1.16.2. 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 this:

►@iru

► down file qualifier*file-name;

► act appl application-group-name;

► up file qualifier*file-name;

► act appl application-group-name;

► end;

1.16.3. 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)

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.

1.16.4. 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.

1.16.5. 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)

1.17. 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.

(39)

Figure 1–11 illustrates the relationship between UREP processes and UDS Control internal tables.

Figure 1–11. UREP-UDS Relationship

1.18. Application Groups

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)

See the Integrated Recovery Conceptual Overview for more information about application groups.

1.18.1. 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.

(41)

1.18.2. 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.

1.18.3. 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

1.18.4. 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)

(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.

2.1. 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$$010 11 UDS$$011 12 UDS$$012 13 UDS$$013