• No results found

Enterprise Database Server for ClearPath MCP

N/A
N/A
Protected

Academic year: 2021

Share "Enterprise Database Server for ClearPath MCP"

Copied!
350
0
0

Loading.... (view fulltext now)

Full text

(1)

Enterprise Database Server for ClearPath

MCP

Getting Started and Installation Guide

ClearPath MCP 12.0

(2)
(3)

unisys

imagine it. done.

Enterprise Database Server for ClearPath

MCP

Getting Started and Installation Guide

ClearPath MCP 12.0

(4)

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.

(5)

Enterprise Database

Server for ClearPath MCP

Getting Started and Installation Guide ClearPath MCP 12.0 Enterprise Database Server for ClearPath MCP Getting Started and Installation Guide ClearPath MCP 12.0 3850 8198–001 3850 8198–001

(6)
(7)

Contents

Section 1. Introducing Enterprise Database Server

Documentation Updates ... 1–1 Enterprise Database Server ... 1–2 Enterprise Database Server Extended Edition... 1–5 Database Operations Center... 1–8 Getting Acquainted with Enterprise Database Server Files... 1–9 Tailored Files... 1–11 Accessing the Database ... 1–12 Beginning a Database Design ... 1–14

Section 2. Defining Enterprise Database Server Database

Structures

Language That Defines the Database... 2–1 Overview of Enterprise Database Server Structures... 2–3 Data Sets... 2–5 Data Set Sections ... 2–6 Sets ... 2–9 Sectioned Sets... 2–11 Relation of Set Sections to Data Set Sections ... 2–13 Subsets ... 2–13 Data Items... 2–15 Global Data Items ... 2–19 Accesses... 2–20 Sectioning for an Access ... 2–20

Section 3. Defining Database Options in DASDL

Facts About the EMPLOYEEDB Database ... 3–2 Auditing the Database... 3–3 Audit Trail... 3–4 Sectioned Audit Files ... 3–6 Variable Audit File Buffers ... 3–7 Creating the Database ... 3–9 Optional Enterprise Database Server Database Functions... 3–10 Managing Structures ... 3–13 Controlling Access to Data ... 3–16 Naming System Files and Tailored Files... 3–21 Audit Trail Options ... 3–22 Control File Location and Usercode... 3–24 Defining the Restart Data Set... 3–25

(8)

Contents

Section 4. Generating a Database

Generating a New Database...4–2 Checking the DASDL Syntax and Compiling the

DASDL Source File ...4–3 Tailored Database Files ...4–7

Section 5. Populating a Database

Populating the Database...5–2 Running a Batch Application Program ...5–2

Section 6. Managing an Active Database

Administering a Database...6–2 Maintaining a Database ...6–3 Enterprise Database Server Database Services ...6–4 Common Maintenance Tasks...6–6 Host System Tasks ...6–6 Initializing Database Files ...6–7 Maintaining the Database Control File ...6–8 Keeping Track of a Processing Job...6–13 Troubleshooting ...6–14 Discontinuing a Program ...6–16 I/O Errors ...6–16

Section 7. Backing Up a Database

Making and Keeping a Recent Backup of Database Files ...7–2 Summary and Order of Backup Tasks ...7–5 Backing Up All or Part of the Database ...7–7 Backing Up the Database by Increments...7–8 Storing the Dump ...7–11 Database Activity During the Backup ...7–14 Performing Online Dumps ...7–15 Performing Offline Dumps ...7–17 Tasks to Be Performed on an Existing Dump ...7–18 Verifying a Dump...7–18 Copying or Duplicating a Dump...7–19 Backing Up Audit Files...7–20 Backing Up Database-Related Files...7–24

(9)

Contents

Section 8. Recovering the Database

Overview... 8–2 Automatic Recovery for Audited Databases... 8–2 Automatic Single Transaction Abort Recovery ... 8–3 Automatic Abort Recovery... 8–4 Monitoring an Abort Recovery... 8–5 Automatic Halt/Load Recovery ... 8–8 Monitoring a Halt/Load Recovery ... 8–10 Manual Recovery for Audited Databases ... 8–12 Reconstructing Parts of a Database ... 8–16 Reconstructing from a Backup Dump ... 8–17 Reconstruction Using an Audit File Only ... 8–18 Rebuilding a Database ... 8–23 Rolling Back a Database... 8–25 Recovering an Unaudited Database... 8–27

Section 9. Monitoring a Database

Monitoring the Database ... 9–2 General Database Monitoring Tasks ... 9–3 Certifying the Consistency of Database Structures... 9–4 Analyzing Logical and Physical Structures ... 9–6 Acquiring Database Status and Performance Statistics... 9–8

Section 10. Using Audit Files as a Diagnostic Tool

Reasons to View an Audit File ... 10–3 Contents of an Audit File View ... 10–4 Types of Records in an Audit File ... 10–7 Requesting an Audit File View ... 10–9 Ordering the Contents of a View... 10–12 Understanding Interval Types... 10–14 Selection Parameters and Examples ... 10–17

Section 11. Updating and Reorganizing the Database

Changing Database Structures ... 11–2 Planning an Update or a Reorganization ... 11–3 Online Set Garbage Collection ... 11–4

Section 12. TranStamp Locking and Record Serial Numbers

(RSNs)

TranStamp Locking ... 12–1 How Traditional Locking Works... 12–2 How TranStamp Locking Works... 12–2 Support of Traditional and TranStamp Locking... 12–3 Record Serial Numbers (RSNs) ... 12–4 How the AA Word Works as a Tiebreaker ... 12–5 How the RSN Works as a Tiebreaker ... 12–5

(10)

Contents

Section 13. Scenarios for Using Enterprise Database Server

Extended Edition

Scenario 1: Data Set Capacity Reaching Limits...13–2 Increasing Data Set Capacity by Specifying File

Attributes ...13–2 Logically Separating a Data Set...13–3 Dividing Data Sets into Sections ...13–3 Scenario 2: Database Performance Limited by Audit Trail

Throughput ...13–5 Reducing the Data Being Written to the Audit Trail...13–5 Improving the Efficiency of Enterprise Database

Server I/O ...13–6 Increasing the Throughput of the Disk Subsystem...13–7 Scenario 3: Database Performance Limited by Set Contention ...13–8 Logically Separating a Data Set...13–9 Using Multiple Sets ...13–9 Using Enterprise Database Server Extended Edition

Sectioned Sets ...13–9 Scenario 4: A General Transaction Processing Environment ...13–10 Sectioning Audit Files...13–10 Sectioning Sets ...13–10 Sectioning Data Sets ...13–11 Using TranStamp Locking and RSNs ...13–11

Section 14. Support Policy and Release Compatibility Overview

Section 15. Installation Process Overview

Preparing for the Installation Process...15–2 Data Management Products...15–3 Keys File ...15–4 General Installation Requirements ...15–5 Products with SDF Plus Screen Interfaces ...15–6

Section 16. Understanding Data Management Environment

Requirements

Memory Requirements...16–2 Planning for VSS-2 ...16–5 SDF Plus Physical Requirements ...16–6 Enterprise Database Server Database Physical Limitations ...16–8

Section 17. Creating a Data Management Environment

Determining Your Installation Environment...17–2 Installation Overview ...17–3 Loading Your Software ...17–4 Verifying SDF Plus Libraries ...17–4 Installing the ADDS Dictionary ...17–5

(11)

Contents

Configuring Remote Database Backup for Use with a

Nonusercoded Database ... 17–7 Running Two Versions of Enterprise Database Server... 17–9 Running a Second Version of Remote Database Backup on

Your System ... 17–11 Configuring the Open Distributed Transaction Processing

Product ... 17–12

Section 18. Upgrading an ADDS Environment to a New Release

Level

Upgrade Overview ... 18–2 Upgrading ADDS Dictionaries ... 18–2 Preparing to Upgrade Your ADDS Dictionary ... 18–3 Recording the Current Dictionary Properties... 18–4 Performing the Upgrade Process on Your ADDS Dictionary ... 18–5

Upgrading ADDS Dictionaries with Fallback

Capabilities ... 18–5 Upgrading ADDS Dictionaries Without Fallback

Capabilities ... 18–10 Upgrading Enterprise Database Server Databases... 18–11 Backing Up an Enterprise Database Server Database... 18–12 Upgrading a Remote Database Backup Environment ... 18–13 Bringing Down Your Databases... 18–14 Providing a Queue for Remote Database

Backup-Related Tasks ... 18–15 Modifying the RDB Support Library for a

Nonusercoded Database... 18–16 Upgrading the Secondary Database ... 18–17 Facilitating the NFT Task Under the AFS Mode ... 18–18

Section 19. Upgrading a Non-ADDS Environment to a New

Release Level

Upgrade Overview ... 19–2 Loading the Data Management Software... 19–2 Verifying SDF Plus Libraries... 19–3 Upgrading Enterprise Database Server Databases... 19–4 Backing Up an Enterprise Database Server Database... 19–5 Upgrading a Remote Database Backup Environment ... 19–5 Bringing Down Your Databases... 19–7 Providing a Queue for Remote Database

Backup-Related Tasks ... 19–8 Modifying the RDB Support Library for a

Nonusercoded Database... 19–9 Upgrading the Secondary Database ... 19–10 Facilitating the NFT Task Under the AFS Mode ... 19–11

(12)

Contents

Section 20. Returning to a Previous Release Level

Returning to a Previous Release Overview ...20–2 Returning to a Previous Release Level of ADDS...20–3 Returning to a Previous Release Level of Enterprise Database

Server ...20–5 Returning to a Previous Release Level of Remote Database

Backup...20–6

Section 21. Installing Interim Corrections Without Closing the

Database

Understanding Software Updates with the DMUPDATE Utility...21–2 Types of Software Updates ...21–3 Planning for a Software Update with the DMUPDATE Utility ...21–3 Software Components for a Software Update ...21–4 Elements of the Configuration File...21–5 Customizing Your Software Update Using the DMUPDATE

Configuration File ...21–7 Comment Header...21–8 Understanding the Software Update Types ...21–9 Controlled Software Update...21–9 Assisted Software Update ...21–11 Automatic Software Update...21–12 Files Used During a Software Update Using the

DMUPDATE Utility...21–14 Performing a Software Update Using the DMUPDATE Utility ...21–15 Backing Out an Installed IC ...21–16 Limitations and Considerations ...21–16 Software Updates That Require a DASDL or

DMCONTROL Update ...21–18 Including or Excluding Particular Databases During

a Software Update ...21–18 Conditions That Result in an Aborted Software

Update Using the DMUPDATE Utility...21–19 Conditions That Result in a Skipped Database ...21–19 Checking On the Success Status of the

DMUPDATE Utility...21–19 Checking On the Status of Open Databases Using

DMUPDATESUPPORT...21–20

Appendix A. DASDL Definition for Sample Database

Appendix B. Database Specifics Chart

Appendix C. SL (Support Library) System Command

(13)

Figures

1–1. Sample Database Files on Primary Family Pack ... 1–10 1–2. Partial List of Sample Database Files on Secondary Family Pack... 1–11 2–1. Part of a Data File... 2–4 2–2. Sample Portion of PERSON Data Set ... 2–5 2–3. Partial DASDL Definition for the PERSON Data Set ... 2–6 2–4. Sample of PERSON-SET Set for the PERSON Data Set... 2–10 2–5. DASDL Definition for the PERSON-SET Set ... 2–11 2–6. Sample of MANAGER Subset for the PERSON Data Set... 2–14 2–7. DASDL Definition for the MANAGER Subset ... 2–15 4–1. Sample DASDL Syntax Error Messages ... 4–4 4–2. DASDL Code Showing Syntax Errors ... 4–5 4–3. Flowchart of a DASDL Compilation ... 4–8 4–4. Creation of an Empty Database ... 4–8 5–1. Software Interaction When the Database Is Open... 5–8 6–1. Jobs Displayed on MARC Screen ... 6–13 8–1. Flowchart of Accessroutines Actions in the Abort Recovery Process ... 8–5 8–2. Flowchart of the Halt/Load Recovery Process... 8–9 10–1. Introductory Lines of Audit File View... 10–5 10–2. Comparison of Audit File View Formats ... 10–6 10–3. Examples of Types of Audit File Records ... 10–8 10–4. Narrowing the Focus of an Audit File View Request ... 10–12

(14)
(15)

Tables

4–1. Explanations of Syntax Error Messages ... 4–6 10–1. Designating Where to Send the Audit File View ... 10–9 10–2. Order and Purpose of Request Parameters... 10–13 10–3. Types of Intervals for Audit File Views ... 10–14 10–4. Interval Types and Examples ... 10–15 10–5. Values for Date and Time in Time Interval ... 10–16 10–6. Results of PRINTAUDIT Verification of Timestamps ... 10–17 10–7. Selection Parameters and Examples ... 10–18 A–1. Summary of Sample EMPLOYEEDB Database Structures ... A–2

(16)
(17)

Section 1

Introducing Enterprise Database

Server

Purpose

The purpose of this guide is to help you understand and start using the Enterprise Database Server. The first 14 sections of the guide discuss basic concepts and information you need to know about the Enterprise Database Server. Sections 15 through 21 are more technical and explain the details involved in installing the Enterprise Database Server and other data management products. This guide contains information previously presented in the Enterprise Database Server Extended Edition Capabilities Overview, Getting Started with DMSII Guide, and Data Management Installation Guide.

Terminology

In this document, the term ClearPath MCP servers refers to ClearPath LX and CS servers, and FS and Libra Series servers.

In This Section

This section provides information about

• Enterprise Database Server

• Enterprise Database Server Extended Edition

• Database Operations Center

• Getting acquainted with Enterprise Database Server files

• Accessing the database

• Beginning a database design

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

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

(18)

Enterprise Database Server

Enterprise Database Server

Definition

Enterprise Database Server is the database management system (DBMS) for ClearPath MCP enterprise servers.

Among many database management systems available in the information technology world today, Enterprise Database Server is a mature, proven DBMS that continues to receive major feature enhancements and performance improvements.

In addition to all of the Enterprise Database Server features (also known as Enterprise Database Server Standard Edition), you have the option of using the Enterprise Database Server Extended Edition features. These can be thought of as “add-on” features to the Enterprise Database Server Standard Edition.

Enterprise Database Server Use

Many large and small businesses throughout the world use Enterprise Database Server. Examples are airline reservation systems, financial institutions, retail chains, insurance companies, utilities, and government agencies.

Enterprise Database Server as a DBMS

As a DBMS, Enterprise Database Server facilitates

• Building database structures for data according to an appropriate logical model (relational, hierarchical, or network)

• Managing database structures

• Keeping structures in stable order while application programs are retrieving or changing data

Enterprise Database Server Data Definition Language

The data definition language that Enterprise Database Server uses is Data and Structure Definition Language (DASDL).

(19)

Enterprise Database Server

Database Management Task Overview

The following table lists briefly the database management tasks that Enterprise Database Server enables you to do. As these tasks are explained in various sections of this guide, you will learn more about how Enterprise Database Server software programs work.

Database Management

Area Tasks Software Tools

Database performance

Monitoring and optimizing database performance Altering run-time performance attributes Utilities: DMMONITOR Accessroutines Visible DBS commands Database control Monitoring multiprogram database access

Database control file and Accessroutines

Data safety Integrity checking Preventing access to the same data by multiple applications at the same time DMUTILITY options: DBCERTIFICATION, CHECKSUM, DIGITCHECK, ADDRESSCHECK, KEYCOMPARE, INDEPENDENTTRANS, LOCK TO MODIFY DETAILS Accessroutines structure locks Database software installation Integrated installation of software updates with enhanced database availability during

installation of an Enterprise Database Server Interim Correction (IC) or a Supplemental Support Package (SSP). DMUPDATE utility Database structure definition and modification

Defining data structures and the data fields within them

Modifying data structures

DASDL compiler

REORGANIZATION program

Data access Developing an application program to retrieve or change data

Third-generation host languages: COBOL, ALGOL, FORTRAN

Utilities: DMINQUIRY and DMINTERPRETER Enterprise Database OLE DB Data Provider for ClearPath MCP

(20)

Enterprise Database Server

Database Management

Area Tasks Software Tools

Database and data security

Preventing unauthorized database access

Host system security Guard files

DASDL: Logical remap and logical database capabilities for applications Independence of application programs from data changes Preventing revision of application programs every time a structure changes

DASDL: Logical remap and logical database capabilities for applications Database and data recovery Resuming database operations after an interruption Utilities: DMRECOVERY, DMUTILITY, ACCESSROUTINES, DMDATARECOVERY, RECONSTRUCT

DASDL AUDIT option and restart data set definition Data change

tracking

Keeping a record of every change made to data

Accessroutines

Data change integrity

Ensuring that update changes are applied to, or removed from, the database in their entirety

DASDL options: INDEPENDENTTRANS, REAPPLYCOMPLETED Having a recent copy of the database in reserve

Backing up the database and storing copies of audit files and all other database files DMUTILITY commands: DUMP, VERIFYDUMP, COPYDUMP, BUILDDUMP DIRECTORY, DUPLICATEDUMP, TAPEDIRECTORY Programs: DMDUMPDIR, and COPYAUDIT DMUTILITY Database scalability

Growing or shrinking the database according to business needs

(21)

Enterprise Database Server Extended Edition

Enterprise Database Server Extended Edition

The goals of the Enterprise Database Server Extended Edition are

• Linear scalability

• Multiterabyte capacity

• Increased database availability

Linear Scalability Goal

Ideally, the Enterprise Database Server Extended Edition seeks to provide linear scaling, meaning that each processor added to a system yields the same performance increment as the processor that preceded it.

Realistically, scaling cannot be truly linear because other factorssuch as hardware, the MCP, and the Enterprise Database Server itselfaffect the scaling results. However, the Enterprise Database Server Extended Edition provides features that allow a much closer approach to the linear scaling ideal than has been possible previously.

Multiterabyte Capacity Goal

The Enterprise Database Server Extended Edition provides multiterabyte data capacity at the data set level.

Existing systems (including the Enterprise Database Server Standard Edition) achieve multiterabyte data capacity by requiring application logic to create multiple logical data structures to simulate capacity expansion.

With the Enterprise Database Server Extended Edition, each data set can hold more than 12 terabytes of data. The Enterprise Database Server Extended Edition implements structures with large amounts of data rather than relying on application logic to piece together several structures with less capacity.

Database Availability Goal

One availability goal of the Enterprise Database Server Extended Edition is to reduce the amount of time during which a database or structure is unavailable because of required maintenance. The Enterprise Database Server Extended Edition addresses this goal by providing an online garbage collection facility for disjoint index sequential sets and subsets.

(22)

Enterprise Database Server Extended Edition

How the Enterprise Database Server Extended Edition Achieves Its

Goals

The Enterprise Database Server Extended Edition revamps the handling of database structures and files to increase

• Parallelism and I/O throughput

• Capacity of individual data sets

• Database availability during online reorganization

Enterprise Database Server Extended Edition Features

To achieve its scalability, capacity, and availability goals, the Enterprise Database Server Extended Edition provides the following features:

• Variable audit file buffers

• Sectioned audit files

• Sectioned disjoint standard data sets

• Sectioned disjoint compact data sets

• Sectioned disjoint random data sets

• Sectioned disjoint direct data sets

• Sectioned disjoint index sequential sets

• TranStamp locking

• Record serial numbers (RSNs)

• Online set garbage collection

Systems That Benefit from the Enterprise Database Server Extended

Edition

To benefit from Enterprise Database Server Extended Edition scalability and capacity features, a system must have processor and memory resources available and must exhibit one or more of the following conditions:

• Restricted I/O throughput in the audit trail

• Set throughput bottleneck

• Nearing data set capacity limits

(23)

Enterprise Database Server Extended Edition

Moving to the Enterprise Database Server Extended Edition

Moving to the Enterprise Database Server Extended Edition from an existing Enterprise Database Server database is relatively simple because of the following principles of coexistence:

• The Enterprise Database Server Extended Edition is based on the Enterprise Database Server Standard Edition and is compatible with existing database structures.

• Movement to the Enterprise Database Server Extended Edition can be on a structure-by-structure basis. The Enterprise Database Server Extended Edition structures and the Enterprise Database Server Standard Edition structures can exist side by side in the same database.

• Transactions can span both the Enterprise Database Server Standard Edition and the Enterprise Database Server Extended Edition structures.

• Migration does not require changes to the logic or methodology of existing database application programs.

Enterprise Database Server Extended Edition Feature Access and Use

Access to specific Enterprise Database Server Extended Edition features requires that you

1. License the Enterprise Database Server Extended Edition. 2. Set the INDEPENDENTTRANS option in DASDL.

3. Explicitly activate each Enterprise Database Server Extended Edition feature for each database or for specific database structures within a database.

Both Enterprise Database Server Extended Edition users and Enterprise Database Server Standard Edition users benefit from the algorithmic changes that have been made to the Enterprise Database Server data engine (Accessroutines) to support new Enterprise Database Server Extended Edition features.

Enterprise Database Server Extended Edition and Other Data

Management Products

Enhanced Software

To maintain full compatibility with the Enterprise Database Server Extended Edition, Remote Database Backup has undergone changes.

Modified Software

The DMINQ interface in the Accessroutines has undergone modification to enable a seamless interfacing under the Enterprise Database Server Extended Edition with the Database Interpreter software component.

Database Certification has been modified for use with the Enterprise Database Server Extended Edition.

(24)

Database Operations Center

Supported Software

The following products are supported for use with Enterprise Database Server Extended Edition features:

• Database Operations Center

• Enterprise Database OLE DB Data Provider of ClearPath MCP

Unsupported Software

The following products are not supported for use with Enterprise Database Server Extended Edition features:

• Advanced Data Dictionary System (ADDS)

• Transaction Processing System (TPS)

Database Operations Center

Database Operations Center is a graphical user interface (GUI) that provides a client-server front-end for Enterprise Database Server Standard Edition and Enterprise Database Server Extended Edition database utilities on ClearPath MCP servers. Database Operations Center

• Performs administrative functions for Enterprise Database Server Standard Edition utilities

• Retains the Enterprise Database Server Edition utility command line for optional use

• Supports Enterprise Database Server Extended Edition utility-related enhancements

• Runs on various Windows operating systems

(25)

Getting Acquainted with Enterprise Database Server Files

Getting Acquainted with Enterprise Database

Server Files

Files That Work with All Databases

Enterprise Database Server provides standard software files that perform services and operations for all databases on your ClearPath MCP server.

After Enterprise Database Server is installed, you can view a list of these files on your terminal. To do this, enter the following Command and Edit (CANDE) FILES commands.

Listing Enterprise Database Server Standard Software Files

The FILES DATABASE ON HUBPACK command lists Enterprise Database Server standard software files that reside on HUBPACK, the Enterprise Database Server software family for the sample EMPLOYEEDB database.

The FILES *SYSTEM/= ON HUBPACK command lists Enterprise Database Server utility files among other host system software files.

Listing Files for a Particular Database

Overview

If you have an existing database, use the CANDE FILES command to see the names of the database files with a first node of the database name. Use the database usercode and family statement.

Every file connected with the database has the database name as either the first or second node of the database file. EMPLOYEEDB is the name of the sample database used for examples in this guide.

The following examples use default pack locations. Your site might have set up different pack locations. In addition, your file lists can vary because of database differences and customizations at your site.

Listing Primary Family Pack Files

The FILES ~/EMPLOYEEDB command lists the files shown in Figure 1–1. (The tilde as the first node is a wild card.)

(26)

Getting Acquainted with Enterprise Database Server Files

FILES ~/EMPLOYEEDB

~/EMPLOYEEDB ON HR File Name Filekind Records Sectors CreationTime

---+---+---+---+--- DMSUPPORT/EMPLOYEEDB DCALGOLCODE 1829 1836 04/04/1997 DESCRIPTION/EMPLOYEEDB DASDLDATA 50 450 04/04/1997

RECONSTRUCT/EMPLOYEEDB DCALGOLCODE 14 18 04/04/1997 4 FILES FOUND #

Figure 1–1. Sample Database Files on Primary Family Pack

Figure 1–1 lists the following tailored database files that Enterprise Database Server generates during the compilation of the database definition:

• DMSUPPORT/EMPLOYEEDB is an object code file—a library containing entry points to procedures that allow an application program to obtain Enterprise Database Server error codes at run time. Enterprise Database Server standard software also uses this library.

• DESCRIPTION/EMPLOYEEDB is a data file containing information used when

Enterprise Database Server compiles all tailored software and all Enterprise Database Server user-language programs for a particular database.

• RECONSTRUCT/EMPLOYEEDB is generated only if the database is audited. This object code file enables a row reconstruction operation.

Listing Secondary Family Pack Files

The FILES EMPLOYEEDB ON HUBPACK command lists files that hold your data and associated files (see

(27)

Getting Acquainted with Enterprise Database Server Files (SYSDBA) ON HUBPACK . EMPLOYEEDB . . RST . . . DATA : DBRESTARTSET . . . RESSET : DBDATA . . FAMILY . . . DATA : DBDATA . . . FAMILY-SET : DBDATA . . PERSON . . . DATA : DBDATA . . . EMP-MGR : DBDATA . . . MANAGER : DBDATA . . . EMPLOYEE : DBDATA . . . PERSON-SET : DBDATA . . . PROJECT-EMPLOYEE : DBDATA . . . PREVIOUS-EMPLOYEE : DBDATA . . CONTROL : DBDATA . . PROJECT . . . DATA : DBDATA . . . PROJECT-SET : DBDATA . . . SUPER-PROJECTS : DBDATA . . EDUCATION . . . DATA : DBDATA

Figure 1–2. Partial List of Sample Database Files on Secondary Family Pack

Figure 1–2 lists files of type DBDATA that hold the data for the sample EMPLOYEEDB database. The file of type DBRESTARTSET identifies the restart data set used by Enterprise Database Server recovery and by the applications when they resume processing after a database recovery.

EMPLOYEEDB/CONTROL controls database operation by

• Verifying compatibility between tailored software and database files

• Verifying that all data files are at the same level of update

• Storing audit control information, dynamic database parameters, and other

information for use by Enterprise Database Server and application software programs

• Controlling locking and unlocking of the database

Tailored Files

During the compilation of the database definition, standard Enterprise Database Server programs tailor several files for use with the particular database only. These files are known as tailored software. The following table lists the tailored database files for the sample EMPLOYEEDB database and some of their characteristics.

(28)

Accessing the Database

Default

Software Name

Descriptive File

Name File Characteristics and Purpose

DESCRIPTION/ EMPLOYEEDB

Description file Static

• Changed only by DASDL compilation

• Serves as a basis for other tailored files

• Used by application compilers EMPLOYEEDB/

CONTROL

Control file Dynamic

• Continually accessed and changed during database access

• Monitors and controls database access; considered the “run-time extension of the description file” DMSUPPORT/

EMPLOYEEDB

DMSUPPORT library

• Static

• Recompiled after a new description file is compiled

• Source of database information at run time RECONSTRUCT/ EMPLOYEEDB RECONSTRUCT program • Static

• Recompiled after a new description file is compiled

• Source for row reconstruction in an audited database

Accessing the Database

The People Involved

People who access the Enterprise Database Server database have three separate roles: application programmer, application program user, and database administrator (DBA).

Application Programmer

The application programmer designs and writes a program that performs a task or set of tasks in relation to the data of an enterprise. This person writes the program in a

computer language, for example, COBOL, ALGOL, RPG, or OLE DB applications. The application programmer thoroughly understands the perspective of the application user and depends on the DBA for information on Enterprise Database Server rules, and the utilities and tools with which the application program must interface.

Application Program User

In the normal course of business, the application program user submits changes to data or retrieves data while running the application program. Changes add, modify, and delete data.

(29)

Accessing the Database

The application user understands how the application helps him or her to accomplish tasks. This person interfaces with the application programmer or DBA when new information is needed from the database or when a problem arises with the application.

DBA

The DBA and his or her assistants access the database to manage and maintain it. As data relationships change or new data relationships are added, the DBA changes the database structure definitions. The DBA obtains information about expanding or changed business perspectives from application programmers or application program users. The DBA keeps the database running smoothly and enforces rules for data integrity and security. While the database is running, the DBA and operators interact with the

database through the Visible DBS commands.

Other DBA responsibilities include making backups of the database, and monitoring, adjusting, testing, and qualifying changes to database performance in relation to other demands within the computer environment.

Interface: Application Programs and Database Software

Users access the database through the application program. The application program does not access data directly. Instead, the program interacts with Enterprise Database Server standard software and database tailored software working together as a unit. This software groupdirected by the Enterprise Database Server Accessroutinesaccesses, retrieves, and stores data in the physical database files.

Reasons for Access

An application program user accesses the data for one of two purposes:

• Inquiry, which is a read of data in the database usually to make a copy elsewhere

• Update, which is a write to the database that adds, deletes, or changes data Access for either purpose contributes to an operation on the database called a transaction.

Transactions

In data management, a transaction is a sequence of operations grouped by a user program because the operations constitute a single logical change to the database. The application programmer decides how many data reads and writes by a program make up a transaction.

At the end transaction point, the transaction is complete and without error. It is

considered “committed” to the database. Committed means that the database has been changed and that the change is visible to other database users.

(30)

Beginning a Database Design

Beginning a Database Design

Real-World Business Map of Data

The design of an Enterprise Database Server database depends upon a real-world business map of the data to be stored. The following table illustrates part of the real-world map for the EMPLOYEEDB database used as an example in this guide.

Creative Samples Inc. Employee Database Information

Data Needed for Each Employee

People Category

Breakdowns Needed ID for Searches

Employee ID number Name (first, last, and middle initial) Birth date Age

Marital status

Address (street, city, state, postal code) Employee job information: • Assignment • Project • Manager • Department Employee number Project number Assignment number

Next of kin (first name, last name, middle initial, relationship, phone)

Benefit Information

Spouse and children

Citizenship Gender Employed (current/former) Hire date Status, title Leave status

Reason for termination Last work date Overall rating Bonus Manager title Department number Head of department Skills Assessment/ Searches Education Assignment Title/level Assignment Start/end date Estimated hours Rating Project number Assignment number Project Information Project number Project title Department number Sub or super project of Program manager Version level Team ID

Acting manager

Where to Put Real-World Business Data in the Database

Real-world business data goes into logical structures that Enterprise Database Server uses to store data. Whoever designs the database maps categories of data to suitable structures.

(31)

Beginning a Database Design

The following table shows the correspondence between some real-world data and Enterprise Database Server data structures. Appendix A shows the complete mapping of data in Enterprise Database Server structures in the EMPLOYEEDB database definition.

Real-World Data Structure Example

Category Data set Person

Data that can serve as an index of a whole data set

Set Employee number

Data that can serve as an index of a data set under a condition

Subset Employee number

Data about each instance of the category

Data item Name

Address Data related to the database as a

whole

Global data item Total number of employees

Related Information Topics

For information about . . . Refer to . . .

Complete sample DASDL definition

Appendix A

DASDL definition for real-world business map of data

Section 2, 3, and Appendix A DASDL Reference Manual

Database Operations Center Database Operations Center Getting Started Guide

Database Operations Center Help Enterprise Database Server

utilities

Varied sections of this guide

Enterprise Database Server Utilities Operations Guide

Installing Enterprise Database Server

Simple Installation Operations Guide

Security Security Administration Guide Tailored files Varied sections of this guide

Enterprise Database Server Utilities Operations Guide

Types of structures Section 2

DASDL Reference Manual

Visible DBS commands Enterprise Database Server Utilities Operations Guide

(32)
(33)

Section 2

Defining Enterprise Database Server

Database Structures

In This Section

This section provides information on

• Data and Structure Definition Language (DASDL)

• Enterprise Database Server structures in general

• Data sets

• Sets

• Subsets

• Data items

• Global data items

• Accesses

Structure examples are from the sample EMPLOYEEDB database used in this guide.

Language That Defines the Database

Introduction

Once you have identified the real-world data to be stored in a database, you need to define that data in relation to Enterprise Database Server data structures that hold data. When you define data within structures, Enterprise Database Server and system software programs and application programs can understand how to make the data accessible for inquiry and change.

(34)

Language That Defines the Database

What This Guide Tells You About DASDL

This guide provides you with

• A good example of a realistic database definitionthe EMPLOYEEDB DASDL definition (see Appendix A for the entire definition)

• DASDL components for data set, set, and subset descriptions (see Figures 2–3, 2–5, and 2–7)

• Brief explanations of the defaults, options, and parameters that are set for the sample EMPLOYEEDB database

DASDL Information You Can Find in Associated Manuals

You can find the following information about DASDL in other Enterprise Database Server reference manuals:

• DASDL language components

• Optional features not used in the sample database

• Remaps and logical databases for security

• Modeling and reorganizing

• Structure formats

You can find the names of associated manuals under the “Related Information Topics” headings in this and other sections of this guide.

What You Define with DASDL

You define two kinds of basic information:

• The data structures to hold your data

• Optional features under which you want the database to run

How to Write the DASDL Definition

You can create a new DASDL definition or make changes to an existing DASDL definition by following the order and format shown in the sample EMPLOYEEDB database. You can also refer to additional information in the manuals listed under “Related Information Topics.”

To create a new file of type DASDL or to edit an existing DASDL file, you can use CANDE (or another editor).

For a new database, the database designer (who might also be the DBA) designs structures. However, anyone who understands the design and DASDL can create the DASDL file.

(35)

Overview of Enterprise Database Server Structures

Overview of Enterprise Database Server Structures

Structure Names and Purposes

Enterprise Database Server structures are the building blocks of every Enterprise Database Server database. All structures are files of type DBDATA. The following table lists the names and purposes for Enterprise Database Server data structures.

Name Purpose

Data item Defines a unit of information about a category in a field (column) of a data set record.

Data set Stores data pertaining to a data category in a collection of records.

Global data item

Stores a unit of information about the entire database or any of its structures.

Set Indexes all records in a data set.

Subset Indexes some records in a data set according to criteria.

Terminology

As you work with an Enterprise Database Server database, you might find that the types of data you talk about are frequently interchanged with the names of data structures. For example,

• In a relational database, a data set is called a table.

• A set or subset is frequently called an index.

• A data item is frequently called a field ora column, or is called by its data name, for example, project.

The structures are made up of common file components: records and fields.

Records

A record is a group of logically related data items in a file. Sometimes a record is called a row. The data items reside in fields in the records. Sometimes a field is called a column.

(36)

Overview of Enterprise Database Server Structures

Figure 2–1 illustrates several records from a file with labels for parts of the record.

Figure 2–1. Part of a Data File

How the Host System Deals with Records

The system treats the record as a unit. The system makes data available to users in records, not individual data items. In programmer language, the record is the unit of data that the system reads from or writes to a file in one execution of a read or write

statement in a program.

In Enterprise Database Server, if the application program wants to change a data item in a record, Enterprise Database Server brings a copy of the record from physical storage to memory, enables the data item to be changed, and writes the changed record back to the file.

For example, if a program was gathering the total salary for the employees on a project, the application program would contain a statement telling the computer to read the record of each employee on the project and write the salary information found in each record in a printed report form and total it.

Fields

A field is a consecutive group of bits or bytes within a component of a record that represents a logical piece of data. A field (or column) is defined by the description of the data item it is to hold.

Types of Structures

Each structure can be standard, or it can have one or more special characteristics that governs either the type of data the database stores or the way applications can access the data.

(37)

Data Sets

Data Sets

Definition

The data set is a physical file—a collection of related data records stored on a random-access storage device (disk) in which your data resides.

Purpose

The data set exists to store data for a database entity. In the PERSON data set for the sample EMPLOYEEDB database, each piece of data about the entity (person) has a place to reside (see Figure 2–2).

The physical data set file is in the form of a table with columns and rows:

• Each column contains a defined data item that describes something about the project for which the data set is built.

• Each row contains one instance of the entity for which the data set was built. After the database is generated, some application programs whose job is to update the database populate the data sets with data. That is, update programs write data to the fields of data set records.

(38)

Data Sets

Writing the Data Set Definition

Figure 2–3 shows the beginning and end of the PERSON data set DASDL definition with labels identifying how DASDL expresses data set components to the system.

Figure 2–3. Partial DASDL Definition for the PERSON Data Set

Keeping a Data Set Up-To-Date

A data set is kept up-to-date in two ways:

• Application programs add, change, or delete individual pieces of data or records stored in the data set.

• The DBA or assistants maintain the structure of the data set. For example, when necessary, the DBA

− Keeps the data set within maximum size limits

− Adds, deletes, or changes the definition of a data item (column)

− Creates new sets or subsets

− Monitors automatic Enterprise Database Server processes that guard data integrity

− Creates guard files to enhance the security of the data

Data Set Sections

Definition

One significant feature of the Enterprise Database Server Extended Edition is the sectioned data set. A sectioned data set is one logical data set structure composed of multiple physical files. A minimal change in the physical record format occurs as a result of spreading the data set across several files.

(39)

Data Sets

Purpose

Sectioned data sets serve two main purposes:

• Enable the Enterprise Database Server Extended Edition to expand the data set capacity from 48 gigabytes per structure to 48 gigabytes per section.

With a maximum of 255 sections per data set, each data set is capable of holding more than 12 terabytes of data.

• Reduce or eliminate the throughput restrictions imposed by the architecture of internal locks within the Enterprise Database Server.

For example, standard data sets contain an available space table (DKTABLE) to efficiently manage space reuse. When a program seeks to add or delete a record from the structure, the program must acquire a lock for the DKTABLE, and the system must adjust the DKTABLE. When many programs seek to add or delete records simultaneously, the potential for having to wait for access to the DKTABLE increases.

When a standard data set is sectioned, each section contains its own DKTABLE. Therefore, although there might be many programs adding or deleting records from the data set, only a fraction of those programs access a given data set section. Not only is contention for the DKTABLE reduced, but also multiple programs can add and delete records simultaneously.

Impact on Application Programs

Logically, sectioned data sets appear identical to nonsectioned data sets, and in fact, application programs cannot detect whether a data set is sectioned. Consequently, when you migrate to sectioned data sets, no changes to application program logic are required. However, application programs do need to be recompiled.

Requirements

The requirements for data set sections are as follows:

• Only disjoint compact, direct, random, and standard data sets can be sectioned.

• A data set cannot be sectioned if it is the target of a link item.

• All sections of a data set must reside on the same pack family.

Specifying Data Set Sections

You specify data set sections in DASDL by setting the EXTENDED option for the data set and, depending on the data set type, performing one of the following tasks:

• For compact and standard data sets, specify the number of sections into which the structure should be divided.

• For direct and random data sets, include the section specification as part of the Access declaration.

(40)

Data Sets

The Enterprise Database Server Extended Edition creates the specified number of files and distributes data set records among the sections using the REORGANIZATION program.

The Enterprise Database Server Extended Edition doubles the size of the absolute address (AA) word to identify records within a sectioned data set:

• The first word contains the section number in which a record resides.

• The second word is identical to the word traditionally used to point to a specific location within the file.

Migrating to sectioned data sets, therefore, requires a reorganization to accommodate the two-word AA word pointing to the sectioned data set. All set structures that point to that sectioned data set need to be reorganized.

Distribution of New Data Set Records

Note: The following text applies to sectioned compact and standard data sets only. When a data set is sectioned, the Enterprise Database Server Extended Edition distributes new data set records among the sections by different schemes, depending on whether the reorganization is done online (the default) or offline:

• Online by a round-robin allocation

• Offline by round-robin allocation (no ORDERBY clause specified)

• Offline by section (ORDERBY clause specified)

The system places the appropriate number of records in the first section before writing any records to the second section, and so forth.

Sectioning Capabilities of Data Sets

The following information describes sectioning capabilities for compact, direct, and random data sets. Detailed information regarding sectioning of these data sets as well as sectioning for standard data sets is available in the DASDL Reference Manual.

Compact Data Sets

You can implement a compact data set as a single logical file, while the underlying physical data store is implemented using multiple files.

Sectioning compact data sets is identical to sectioning standard data sets in that sectioning is performed through the use of multiple physical files and records are added using a round-robin mechanism. This feature reduces contention for internal resources related to physical file I/O because the number of contenders for a resource is reduced to 1/n-th (n equals the number of sections) of those for a single physical file. By reducing the amount of contention, performance scalability increases. In addition, total data storage capacity for the logical structure increases because each section is capable of holding as much data as was previously allowed for the entire logical structure prior to sectioning.

(41)

Sets

Direct Data Sets

You can implement a direct data set as a single logical file, while the underlying physical data store is implemented using multiple files. As with compact data sets, this feature reduces contention for internal resources and increases both scalability and data capacity.

Sectioning of direct data sets is similar to that of standard data sets because these structures also use multiple physical files. However, the method by which these records are assigned is based on a key value rather than the round-robin algorithm. The result is a mixture of the multiple physical file characteristics of a sectioned standard data set combined with the sectioning concepts of indexed sequential sets.

A group item can be specified as the key for a direct data set. Group keys can contain only numeric items and must have a total length of 11 digits or less.

Preallocation cannot be specified for sectioned direct data sets. Sectioning of direct data sets provides the ability to specify the gap areas as separate sections. By not

preallocating these sections, you can effectively eliminate wasted space caused by these gaps.

Sectioning of direct data sets is specified as part of the Access declaration rather than as part of the data set declaration. The syntax for the sectioning specification in the Access declaration is identical to that currently used for sectioning an indexed sequential set.

Random Data Sets

You can implement a random data set as a single logical file, while the underlying physical data store is implemented using multiple files. This feature increases scalability and data capacity.

Sectioning of random data sets is specified as part of the Access declaration rather than as part of the data set declaration. The syntax for the sectioning specification in the Access declaration is identical to that currently used for sectioning an indexed sequential set.

Sets

Definition

A set is a separate stored file that indexes all the records of a single data set. Enterprise Database Server uses sets to locate records in a data set. A set has no meaning apart from its data set.

The collection of information in a set differs depending on the type of set that is being used.

(42)

Sets

Purpose

The set structure enables an application program to access all records of a data set in some logical sequence.

Typically, a set is created to speed up certain types of data retrieval from the data set. The decision to create a set rests on knowledge of how users access data in the data set.

However, access by way of a set can sometimes slow down updates to data. Therefore, after you create a set, you might monitor database performance during updates to ensure that the speed of access is not outweighed by the processing overhead connected with updating both the data set and the set.

How Sets Work

Figure 2–4 shows a sample portion of the PERSON data set with the PERSON-SET set that indexes the data set by Social Security number. The Social Security numbers are sequenced in an ascending order. Alternatively, they could be sequenced in a descending order.

To use the set, an application program identifies the person by Social Security number. To retrieve the record of a person, Enterprise Database Server uses the smaller file, the set, to quickly point to the corresponding record in the larger file, the data set.

(43)

Sets

Writing the Set Definition

The application programmer creates sets based on the ways in which application programs need to access data. Anyone who understands the database design and DASDL can write the DASDL definition for a set.

Figure 2–5 shows the PERSON-SET set description with labels identifying how DASDL expresses set components to the system.

Figure 2–5. DASDL Definition for the PERSON-SET Set

Keeping a Set Up-To-Date

A set is kept up-to-date in two ways:

• When application programs add, change, or delete individual pieces of data or records stored in the data set, Enterprise Database Server automatically makes the corresponding changes in the sets that are affected by such changes.

• The DBA maintains the structure of the set. For example, when necessary, the DBA

− Keeps the set within maximum size limits

− Adds, deletes, or changes a set definition

− Monitors automatic Enterprise Database Server processes that use the set

Sectioned Sets

The two types of sectioned sets are logical and physical.

Logical

A logically sectioned set is one physical structure file within which logical boundaries for a number of sections are defined.

Physical

A physically sectioned set allows more records in the structure than logical sectioning and allows multiple set files for specifying greater key range indexes. You can support a large number of records in a data set and improve the capacity of structure storage. Refer to the DASDL Reference Manual for instructions on how to use the syntax that enables you to define a physically sectioned set.

(44)

Sets

Purpose of Sectioning

When multiple application programs access a data set by way of a set, some contention for set resources occurs. As the number of programs rises, so does the amount of contention. Set sectioning reduces or, in some cases, eliminates set resource contention.

Sectioning of sets is critical for achieving scalability on

• Systems with many processors

• Databases with large data sets

Requirements

Only disjoint index sequential sets can be sectioned. You specify section boundary values in DASDL and then perform a DASDL update.

Understanding the Nature of Set Contention

The reason contention for set resources occurs is that the Enterprise Database Server locks the entries in the coarse and fine tables of the set whenever a program

• Adds or deletes an entry

The program must lock those portions of the set that could possibly be changed as a result of the addition or deletion. Depending on how full the set tables are at the time, many levels of set tables can be locked.

• Searches the set for an entry

To ensure that entries do not change in the middle of the search, the Enterprise Database Server locks that portion of the set where the search is taking place. For find and lock operations, the Enterprise Database Server typically locks only two tables on adjacent levels simultaneously.

How Traditional Sets Work

Locks on tables at higher levels prevent access to more tables than do locks at lower levels, creating an inherent performance bottleneck.

The extreme case occurs when the root table (the uppermost table in a set) is locked, preventing access to the set by other programs. As more programs access or manipulate set entries, more locking occurs. The key to removing this bottleneck is to divide the set in such a way that locks at higher levels affect fewer entries.

(45)

Subsets

How Enterprise Database Server Extended Edition Sectioned Sets

Work

Sectioned sets enables you to define the root table entries to be a set of static values that

• Become the boundary values for the sections.

• Form the first-level table in the set, the “section table.”

Because the values in the section table are fixed and do not change with the addition or deletion of entries, the Enterprise Database Server has no reason to lock the section table.

Root Table for Each Section

The root table for each section is the next level of table below the section table. The root table is the first level where locking occurs.

By forcing the first-level of locks to occur below the section table, the entries that a task can lock are those in one section only. Even if access to one section is locked by a program, access to other sections can continue.

When section boundaries are specified so that the set entries being accessed are evenly distributed among all sections, the contention for set resources can be greatly reduced with a corresponding increase in database throughput. In extreme cases, application programs can be adjusted so that they work on discrete sections of a set, thereby eliminating any possible contention.

Relation of Set Sections to Data Set Sections

Set sectioning is completely independent of data set sectioning. You can specify sectioning for both data sets and sets, neither, or one but not the other. Although set sectioning is independent of data set sectioning, the SECTIONS option requires that the EXTENDED attribute be specified for the related data set. In addition, if a data set has multiple spanning sets, you can section any number of those sets. Each set has its own sectioning specification.

Subsets

Definition

A subset is identical to a set except that the subset need not contain a record for every record of the data set.

A subset is a file that indexes none, one, several, or all of the records in a data set. A subset has no meaning apart from the data set. The collection of information in a subset differs depending on the type of subset that is being used.

(46)

Subsets

Purpose

The subset structure enables an application program to access only records of a data set that meet a particular condition.

Like a set, a subset is created to speed up certain types of data retrievals from the data set records. However, access by way of a subset can sometimes slow down updates to data.

How Subsets Work

An application program compiles a list of people who are managers. Therefore, the application programmer creates the MANAGER subset (see Figure 2–6). To retrieve a manager record, Enterprise Database Server uses the smaller file, the subset, to quickly point to the corresponding records in the larger file, the data set. In this case, typically the resulting list of people would contain relatively few names.

Figure 2–6 shows a sample portion of PERSON data set with the MANAGER subset that indexes the data set by the EMPLOYED value of 3.

(47)

Data Items

Writing the Subset Definition

Figure 2–7 shows the MANAGER subset description with labels identifying how DASDL expresses subset components to the system.

Figure 2–7. DASDL Definition for the MANAGER Subset

Keeping a Subset Up-To-Date

A subset is kept up-to-date in two ways:

• When application programs add, change, or delete individual pieces of data or records stored in the data set, Enterprise Database Server supports either of two ways of updating a subset:

− Automatic update when the subset DASDL definition contains a WHERE clause

− Update by an application program when the subset DASDL definition does not contain a WHERE clause

Enterprise Database Server automatically updates the subsets in the sample EMPLOYEEDB database because each subset contains a WHERE clause.

• The DBA maintains the structure of the subset. For example, when necessary, the DBA

− Keeps the subset within maximum size limits

− Adds, deletes, or changes the subset definition when he or she changes the definition of the data item by which the subset indexes the data set

− Monitors automatic Enterprise Database Server processes that use the subset

Data Items

Definition

A data item is an element of data. In Enterprise Database Server, a data item can also be the field (column) in a database record. For example, SOC-SEC-NO is a data item in the sample PERSON data set.

Purpose

The data item describes the data to be stored. For example, the name of an employee is different from the Social Security number of an employee and needs a different

(48)

Data Items

definition. One difference is that the name requires alphanumeric characters, and the Social Security number requires numbers only.

How Data Items Work

The data item provides to Enterprise Database Server the identitytype, size, location, and attributesof one element of data for a database entity. The data item definition also provides one form of data security during an attempt to add, delete, or modify data. For example, when an application submits an update to a data item, Enterprise Database Server accepts the update if it corresponds to the data item definition. Otherwise, Enterprise Database Server rejects the change and reports an exception.

The DBA adds, deletes, or changes data item definitions.

Kinds of Data Items

The following table lists and explains the types of data items supported by Enterprise Database Server.

Type What the Type Defines Example

Alphanumeric Words and characters, such as names, addresses, dates, and titles. By default, data is stored as EBCDIC characters; if requested, data is stored as Kanji characters. DASDL definition: PROJECT-TITLE ALPHA (20); Data example: Earthworm

Numeric Integers and decimals, with or without signs. Can include

• Precision (number of places to the right of the decimal point)

• A scale factor (number of digits in an item) • A sign (+ or –) DASDL definition: PROJECT-NO NUMBER (12); Data example: 121221

Real Single-precision floating-point numbers that occupy one word (24 bits, up to 12 digits). Stored right-justified with leading zeros filling the gaps.

DASDL definition: EMP-SALARY REAL (08,02); Data examples: 1567324.45 129.25 4800.99

(49)

Data Items

Type What the Type Defines Example

Boolean TRUE and FALSE values. Data takes up one 4-bit digit of storage. Only the rightmost bit contains information. DASDL definition: RETIRED BOOLEAN; Data examples: 0 (FALSE) 1 (TRUE)

Field TRUE and FALSE values in 1 bit of space (saves space). So, a field item can store

• Up to 48 Boolean values • An unsigned, nonnegative integer that is up to 48 bits long DASDL definition: WORKS-ON FIELD ( DISK-PROJECT; PRINTER-PROJECT; TAPE-PROJECT; MEMORY-PROJECT; ); Data examples: 0 (FALSE) 1 (TRUE)

Group Alphabetic or numeric items that can be viewed as a single item.

Used to keep related data together, for example, name, street address, city, state, and postal code. DASDL definition: EMP-NAME GROUP ( FIRST-NAME ALPHA (15); MIDDLE-NAME ALPHA (01); LAST-NAME ALPHA (20); ); Data example: Garcia, Mary 432 Pollard Street Buncombe, IL 60645

Count item A binary integer value indicating the number of counted links that refer to the record. The system

automatically adjusts this value.

DASDL definition:

(50)

Data Items

Type What the Type Defines Example

Filler Space in a record for future information. Filler items enable you to add new data items without reorganizing the database, saving time later in the life of the database.

DASDL definition:

FILLER SIZE 12;

Single Data Item Definition

The data item definition appears in the DASDL declaration that defines the data set. For example, the following partial sample declaration for the PERSON data set of the EMPLOYEEDB database defines some data items for each person’s record in the data set:

PERSON DATA SET ( SOC-SEC-NO NUMBER (12); EMPLOYEE-ID NUMBER (12); . . . US-CITIZEN BOOLEAN; GENDER NUMBER (1); SPOUSE-SSN NUMBER (12); EMPLOYED NUMBER (1); HIRE-DATE ALPHA (8);

Group Data Item Definition

Some data items contain parts that are most useful when kept together. The idea is that the system keeps the parts together and treats them as a unit. The PERSON data set contains several group data items: NAME, CURRENT-RESIDENCE, and NEXT-OF-KIN. The definition for the NAME group data item follows:

NAME GROUP ( FIRST-NAME ALPHA (15); MID-INITIAL ALPHA (1); LAST-NAME ALPHA (20); );

As you see, the data item is identified as group by the word GROUP following the data item name in the definition. The components of the group item are enclosed in

References

Related documents

SQL Server 2000 Standard or Enterprise Edition have a complete set of database management tools, including SQL Server Enterprise Manager, which allows you to perform complete database

Also powered by Microsoft SQL Server for enterprise-class database management, security, and reporting, Enterprise Edition includes a Lite Edition of Workfl ow Automation

Methods based on checklists and in pre-defined evaluation models speed up the process and facilitate the consideration of multiple dimensions of the invention, from the

The database servers run Windows Server 2008 R2 Enterprise and Microsoft SQL Server 2008 Enterprise data management software, and SQL Server Reporting Services is used

• When an “event” is triggered in PDMWorks Enterprise (changes to file listings, list updates, replication schedule changes, etc.), it is added to a file vault database table

The evaluation of the product Database Engine of Microsoft SQL Server 2008 R2 Enterprise Edition and Datacenter Edition (English) x64, Version

1 Este trabajo forma parte de una investigación más amplia desarrollada en el marco de mi tesis doctoral titulada “La seguridad interna como ‘teatro de

The Enterprise edition is based on a Client/Server database (Currently Microsoft SQL Server – including the free SQLExpress) Client/Server databases are different from