© Siemens Nixdorf Informationssysteme AG 1995 UDS/SQL V2.5 Design and Definition Edition September 2007 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Comments… Suggestions… Corrections… The User Documentation Department would like to know your opinion on this manual. Your feedback helps us to optimize our documentation to suit your individual needs. Feel free to send us your comments by e-mail to: manuals@fujitsu-siemens.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.ivz 24. October 2007 Stand 09:57.43 © cognitas GmbH 2001-2007 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 Contents 1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1 Brief product description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Target group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Summary of contents . . .
Contents 3.3 3.3.1 3.3.2 3.3.3 Technical implementation . . . . . . . . . . . . . . . Defining the logical structure of a UDS/SQL database . Defining the physical structure of a UDS/SQL database Views . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Schema DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. October 2007 Stand 09:57.43 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.ivz Contents 4.11 Assigning name and privacy to a schema 4.12 Comprehensive example of DDL application . . . . . . . . . . . . . . . . . . . . 112 4.13 Reserved words of the DDL compiler . . . . . . . . . . . . . . . . . . . . . . . . 123 5 SSL 5.1 5.1.1 5.1.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
Contents 6 Definition of the user interface to the database . . . . . . . . . . . . . . . . . . 183 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.8 Subschema DDL . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning name and privacy to a subschema . . . . . . . . . . . Unlocking a schema for creating a subschema . . . . . . . . . . .
24. October 2007 Stand 09:57.43 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.ivz Contents 9 Reference section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.1 9.1.1 9.1.2 9.1.3 9.1.4 Schema DDL syntax Schema entry . . . . Realm entry . . . . . Record entry . . . . . Set entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k01 24. Oktober 2007 Stand 08:47.56 1 Preface 1.1 Brief product description The Universal Database System UDS/SQL is a high-performance database system based on the structural concept of CODASYL. Its capabilities, however, go far beyond those of CODASYL as it also offers the features of the relational model. Both models can be used in coexistence with each other on the same data resources.
Target group Preface 1.2 Target group This manual is intended to support database designers in designing the logical and physical structure of their database and describing it with DDL and SSL. Furthermore, the manual explains how to make database data available to users in the form they require by using the subschema DDL to create suitable subschemas. The language descriptions are also intended for database application programmers and the database administrator.
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k01 Preface Summary of contents 1.3 Summary of contents What does this manual contain? The “General” chapter contains general information on maintaining data and using databases and explains the various database models and the differences between them. The chapter is concluded by a general overview of UDS/SQL.
Summary of contents Preface Further manuals describing additional UDS/SQL products and functions are listed on page 15.
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Summary of contents Preface User task Contents of the five main manuals Design and definition COBOL/ CALL DML programming SQL Creation Administra- Working programand re- tion and opwith ming structuring eration openUTM Working Working with with UDS-D IQS Manual UDS/SQL Creation and Restructuring Preface – – – B – B B – Overview – – – B B – – – Database creation – – – L – – – – Defining access rights – – – L – – – – Storing and unloading data D – – L – D – –
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Readme file Preface Additional notes on the manuals References to other manuals appear in abbreviated form. The following distinction is made: (see “Application Programming” manual, CONNECT) advises you to look up CONNECT in the “Application Programming” manual. The complete titles of the manuals can be found under References. UDS/SQL Messages This manual contains all messages output by UDS/SQL. The messages are sorted in ascending numerical order, or in alphabetical order for some utility routines.
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k01 Preface Changes since the last version 1.5 Changes since the last version The main changes introduced in UDS/SQL V2.5 in comparison with Version 2.4 are listed in table 2 below together with the manuals and the sections in which the changes are described. If a specific topic has been dealt with in more than one manual, the manual in which a detailed description appears is listed first.
Changes since the last version Preface Topic Manual Chapter Session job variable Additional information DBO 9 Database job variable New job variable with information on the status of a database DBO 9 New utility routine BRENAME for renaming database objects CRE 7 New statement RENAME in the BGSIA utility routine CRE 3 Concept DBO 6 Information on preparations in the database structure CRE 3 Concept DBO 9 Description of the new SQL data types RIR 5 Renaming database objects Auto
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Changes since the last version Topic Preface Manual Chapter RIR 7 CRE 4 RIR 4 Information on UDS/SQL pubset declaration RIR 5 Description of all SQL data types, including the new one for supporting Unicode RIR 5 New utility rountine for initiating a renaming cycle CRE 7 Use of DDL, SSL, BGSIA, BALTER and BGSSIA in the renaming cycle CRE 7 Information on automatic realm extension and UDS/SQL pubset declaration CRE 7 RIR 8 RIR 6 CRE 9 CRE 4 CRE 3 CRE 3 BPRECORD utility ro
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Notational conventions Preface 1.6 Notational conventions This section provides an explanation of the notational conventions used to describe syntax rules. 1.6.1 Warnings and notes Points out particularly important information i ! CAUTION! Warnings 1.6.2 Non-SDF notational conventions Language element Explanation Example KEYWORD Keywords are shown in underlined uppercase DATABASE-KEY letters. You may enter either the underlined parts of the keyword exactly as shown or the complete MANUAL keyword.
24. Oktober 2007 Stand 08:47.56 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k01 Preface Notational conventions Language element Explanation Example ... or ,... The immediately preceding expression can be repeated several times if required. The two language elements distinguish between repetitions which use blanks and those which use commas. item-name,... ..... or . . Indicates where entries have been omitted for reasons of clarity. When the formats are used, these omissions are not allowed.
Notational conventions 24 Preface U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 18. Oktober 2007 Stand 11:29.48 2 General information This chapter provides general information on maintaining data and using databases. It also explains the various database models and the differences between them. It concludes with a general overview of UDS/SQL. 2.
Modern data organization General information How and by whom data is used at the different levels in an organization company, is shown in the figure 1 in form of an information pyramid.
Modern data organization The use of a database system results in a noticeable reduction of costs, particularly in the development of applications. The cost savings are achieved due to the following reasons: – All the people involved in development can use a uniform, non-application-specific database. – Preprogrammed functions are provided. – A data organization which remains stable over the long term solves lots of problems.
CODASYL model General information 2.2 Data models The UDS/SQL database system supports both the network model (CODASYL model) and the relational model. It encompasses the principles and capabilities of both the CODASYL and the relational models in a single system. UDS/SQL can be regarded as the implementation of a coexistence model of a database. The following sections briefly describe the CODASYL model, the relational model, the relative merits of the two models, and the coexistence model. 2.2.
CODASYL model The set between the SUPPLIER and ARTICLE record types has the name SUPPLIES. In the SUPPLIES set, SUPPLIER is the owner record type, and ARTICLE the member record type. As a rule, two or more records of the member record type are assigned to a given record of the owner record type. In this example, the supplier Schmidt supplies the articles gingerbread cookies and marzipan. 18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
CODASYL model General information Relationships between record types and referential integrity In figure 2, the SUPPLIES set indicates that a record of the ARTICLE record type is not an isolated record, but is assigned to a record of the SUPPLIER record type. In UDS/SQL, it is possible to declare in a set definition that no article may be entered without a supplier being assigned to that article. A relationship of this type is an example of referential integrity.
18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information Relational model 2.2.2 Relational model The relational model is based on the theoretical work of E.F. Codd, who described the organization and manipulation of data in database systems in terms of relational algebra. He used precisely defined terms to represent the mathematical model of his relational theory.
Relational model General information The following list shows the terms used in this manual and the corresponding formal terms defined by Codd: Term used in manual Formal term (Codd) table record (row) column, record element value value range relation tuple attribute attribute value domain In the relational model, the data is managed and processed in the form of tables.
18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information Relational model Relationships between tables In the case of relational data organization, record types are linked by means of certain record elements with matching contents. A table in a relational schema thus corresponds to a record type in a CODASYL schema.
Relational model General information SQL - a uniform language for relational database systems Development of the theory of relational databases by Codd and others was paralleled by work on the user interface for such systems. The initial results of this work were first presented in the “System R” prototype and were continually revised and supplemented with further results in the years following.
18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information Relative merits of the data models 2.2.3 Relative merits of the data models Comparing the data models with one another in terms of quality is difficult and possible only from the perspective of a specific field of application. Especially an attempt to weight the relative advantages and disadvantages of the models can be made only for a specific application.
Coexistence General information 2.2.4 Coexistence of the CODASYL and relational models A decision to use UDS/SQL is not a decision in favor of the CODASYL model and against the relational model. UDS/SQL supports both models within a single database system, which is consequently referred to as the coexistence model. Both SQL and CODASYL applications can work with the same data resources at the same time.
Coexistence This results in two different user views of a UDS/SQL database, as is shown in figure 4 below: CODASYL applications 18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information SQL applications Relational user level CODASYL user level CODASYL subschema BPSQLSIA utility routine Relational schema U D S/ SQ L data bas e Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Coexistence General information In summary, UDS/SQL offers the following options for combining program interfaces and data organizations: SQL application CODASYL application C OD A S YL DML interface Relational SQL-DML interface UDS/SQL CC CODASYL data str uctur e RC RR Relational data str ucture Figure 5: Coexistence of interfaces and data models in UDS/SQL Relational SQL program interface → CODASYL data organization (RC) Via the relational SQL program interface, applications access a CODASYL d
18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information Coexistence Relational SQL program interface → relational data organization (RR) Via the relational SQL program interface, applications access a purely relational data organization. This combination of program interface and data organization will be referred to in the following as an RR combination.
Coexistence General information Interface suitability The COBOL-DML or CALL-DML interface is typically used for – high-end OLTP applications and extremely performance-critical applications (Online Transaction Processing) and – special applications that run especially efficiently with network structures, e.g. parts list processing.
18. Oktober 2007 Stand 11:29.48 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k02 General information Universal Database System UDS/SQL 2.3 Universal Database System UDS/SQL The Universal Database System UDS/SQL offers users a wide range of structuring options and an abundance of capabilities for setting up, using and maintaining databases: ● Structuring options The structure of a company’s database is a map reflecting the organizational, business and technical aspects of the company.
Universal Database System UDS/SQL ● General information Central data protection measures UDS/SQL incorporates effective, flexibly usable protective mechanisms to ensure that each user group can access only precisely defined parts and sections of the database. UDS/SQL checks the user’s access rights before requests to the database are actually executed. ● Simultaneous data access by many users UDS/SQL permits application-independent data to be accessed by large numbers of users simultaneously.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k03 18. Oktober 2007 Stand 11:29.49 3 Designing the database In order to design a database with product-specific language resources, it is first necessary to make a precise and detailed analysis of the data items, their interrelationships, their interdependencies and the specific user requirements. This analysis should be performed as thoroughly and as carefully as possible because it is of crucial importance for all subsequent work.
Data modeling Database design The analytical process yields a model which describes the designated section of the real world in such a way that the data can be administered with a database system. The data is complete, consistent and available in normalized form. The type of relationships existing between the data items is defined, e.g. a 1:n relationship between customer and order. The logical structure of the data is also called the conceptional schema.
Database distribution 3.2 Distributing the data The data resources may be distributed over several databases, e.g., a personnel database for the accounting department, a customer database for the order-processing department, etc. The databases can be operated by one or more database handlers (DBHs). Databases may also be distributed over different systems.
Database distribution Database design One DBH - multiple databases This constellation is also referred to as multi-DB operation. Many application programs work with two or more databases simultaneously. An application program (AP) may access several databases within a single transaction. The DBH controls the processing of the databases and ensures the consistency of all the data resources. The databases that are operated by a DBH are part of a database configuration.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k03 Database design Database distribution Multiple DBHs - multiple databases Multi-DB operation is also possible with databases belonging to other configurations. Other configurations may be located on another host in a homogeneous BS2000 network (see figure 7) or on the same host (see figure 8).
Database distribution Database design Reasons for distributing databases among several computers within a network: – Adaptability Work processes can be optimized for the local computer center, and data storage can be adapted even better to the organization of the company. – Availability When distributed databases are used, the data resources are more easily available since especially important and frequently used data can be stored in more than one system, and the copies coupled together.
Database distribution Reasons for having two or more configurations on a single host: – – – – – Improved performance Greater mutual independence of applications Separate administration Separate accounting Separate spheres of responsibility Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Technical implementation Database design 3.3 Technical implementation 3.3.1 Defining the logical structure of a UDS/SQL database The logical structure of a UDS/SQL database, i.e. the UDS/SQL schema, can be defined on the basis of either the CODASYL concept or the relational concept. CODASYL database design In a CODASYL database, data relationships are defined via database structures.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k03 Database design Technical implementation 3.3.2 Defining the physical structure of a UDS/SQL database To define the physical data structure, you use the SSL (Storage Structure Language). The SSL is used to specify mainly: – – – – set information data placement optimization links: internal tables, chains, lists.
Technical implementation 52 Database design U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 24. Oktober 2007 Stand 09:30.23 4 Schema DDL 4.1 Introduction Before you start designing a UDS/SQL schema, it is first necessary to thoroughly analyze the intended database applications and the information which is to processed by them. The analysis must yield not only all the information required, but the relationships between the information as well. The data structure thus derived is translated into a UDS/SQL schema by means of the schema DDL.
Introduction Schema DDL Realm Named physical subdivision of the database. Management unit for data privacy and security as well as for handling concurrent accesses. The language elements of the DDL which are used to define the data units are described on page 55 through page 70. The notational convention are explained on page 22, and the general syntax rules are summarized on page 233. You compile the Schema DDL with the DDL compiler.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining an item 4.2 Defining an item An “item” is the smallest unit of data within a record type that can be assigned a name by means of the schema DDL. “Item” also stands for all the values which can be assumed by the item. The particular value contained in an item is referred to as item content. The entirety of all possible item contents is known as the value range of the item.
Defining an item Schema DDL 4.2.1 Defining an unpacked numeric item [level-number ]item-name PICTURE IS mask-string. Unpacked items can contain numeric values only. They can be used for arithmetic operations and can be printed out. level-number specifies whether the item is part of a repeating group: If the item is not to be part of a repeating group, the specified level number should be the smallest level number in the whole record type.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining an item Symbol Designation specifies the position of the decimal point for the mask defined by the digit symbols 9. Default value is V after the last digit symbol of the mask. V 24. Oktober 2007 Stand 09:30.23 Decimal point symbol P (integer) Explanation is specified if the decimal point is to be more than one position outside the mask defined by digit symbols 9 and cannot be specified by ”V”.
Defining an item Schema DDL 4.2.2 Defining a packed numeric item [level-number ]item-name TYPE IS FIXED REAL DECIMAL [ integer-1[,integer-2]]. Packed items can contain numeric values only. They are exclusively used as computational items by the database programmer and cannot be printed without prior editing by a DML program. Packed items require less storage space and can be processed faster than unpacked items.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining an item 4.2.3 Defining a binary item ⎧15⎫ [level-number ]item-name TYPE IS FIXED REAL BINARY[ ⎨ ⎬]. ⎩31⎭ Binary items can contain integers only. They are used exclusively as computational items by the database programmer and cannot be printed without prior editing by a DML program. Binary items require less storage space and can be processed faster than packed or unpacked items.
Defining an item Schema DDL 4.2.4 Defining an alphanumeric item of fixed length ⎧PICTURE IS mask-string ⎫ [level-number ]item-name ⎨ ⎬. ⎩TYPE IS CHARACTER integer⎭ Alphanumeric items can contain any type of character. level-number denotes whether the item is part of a repeating group: If the item is not to be part of a repeating group, the specified level number should be the smallest level number in the whole record type. This is especially important if the item is to be used as a key item.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining an item integer specifies the number of storage locations the item contains, each storage location being able to contain one character of the character set. 4.2.5 Defining an alphanumeric item of variable length ⎧PICTURE IS LX(integer) ⎫ [level-number ]item-name-1 ⎨ ⎬ ⎩TYPE IS CHARACTER integer⎭ DEPENDING ON item-name-2. Alphanumeric items of variable length can contain any type of character.
Defining an item Schema DDL Since the record must also contain at least the record length item item-name-2 in addition to the variable item, the maximum length of the variable item is equal to: – – – 2010 bytes for a 2048-byte page length 3958 bytes for a 4000-byte page length 8054 bytes for a 8096-byte page length If the record includes other items besides the variable item and the record length item, the maximum length of the variable item decreases accordingly.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining an item 4.2.6 Defining a national item (UTF-16) Detailed information is provided in the COBOL2000 “Language Reference Manual” under “Character representation by UTF-16”. [level-number ]item-name PICTURE IS mask-string. National items can be filled with any characters.
Defining an item Schema DDL 4.2.7 Defining a database key item ⎧DATABASE-KEY. ⎫ [level-number ]item-name TYPE IS ⎨ ⎬ ⎩DATABASE-KEY-LONG.⎭ Database key items are binary items that are intended for storing database key values. At the same time, they are the only items whose contents are interpreted by UDS/SQL as database key values.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Defining a vector 4.3 Defining a vector ⎧PICTURE.....⎫ [level-number ]vector-name ⎨ ⎬ OCCURS integer TIMES. ⎩TYPE..... ⎭ A vector is an item with a repetition factor. The repetition factor must be greater than 1. It denotes how many duplicates of the item are grouped into the vector. A vector is defined in the same way as an item as described on page 55. integer specifies the repetition factor.
Defining a repeating group Schema DDL 4.4 Defining a repeating group [level-number-1 ]group-item-name OCCURS integer TIMES. ⎧ ⎧PICTURE.....⎫ ⎫ ⎨level-number-2 record-element-name[ ⎨ ⎬][ OCCURS.....].⎬... ⎭ ⎭ ⎩ ⎩TYPE..... A group item is a named grouping of record elements within a record type. A record element can in this case be either an item, a vector or even a group item. A repeating group is a group item with repetition factor. The repetition factor must be greater than 1.
Defining a repeating group Example 01 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL ADDRESSES OCCURS 2 TIMES. 02 CUST-ADDRESS PICTURE IS X(20) OCCURS 2 TIMES. 02 TEL PICTURE IS X(12). Repeating group Vectors ADDRESSES CUST-ADDRESS TEL CUST-ADDRESS TEL Items Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Grouping to form a record type Schema DDL 4.5 Grouping record elements to form a record type RECORD NAME IS record-name . . . ⎫ ⎧ ⎧PICTURE.....⎫ ⎨[level-number ]record-element-name[ ⎨ ⎬][ OCCURS.....].⎬... ⎩ ⎩TYPE..... ⎭ ⎭ A record type is a named collection of record elements. A record element may be an item, a vector or a repeating group. A single occurrence of a record type is a record. A record thus consists of one item content each of all the items represented in the record type.
Grouping to form a record type Example RECORD NAME IS CUSTOMER . . . 01 C-NO PICTURE IS 9(10). 01 C-NAME PICTURE IS X(20). 01 ADDRESSES OCCURS 2 TIMES. 02 CUST-ADDRESS PICTURE IS X(20) OCCURS 2 TIMES. 02 TEL PICTURE IS X(12). 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Record type CUSTOMER Repeating group Vectors Items ADDRESSES CUST-ADDRESS C-NO C-NAME TEL CUST-ADDRESS TEL Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Linking record types Schema DDL 4.6 Linking the records of two record types to form a set UDS/SQL depicts the relationships and interdependencies of information existing in a corporate organization and a planned database application as relationships between record types using the set concept. In a relational application, the definition of set relationships causes foreign keys to be assigned appropriately. This is the prerequisite for linking tables (join).
Linking record types Sets and set occurrences are represented according to the following principle: 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Owner record type Owner record 1 Owner record 2 Owner record 3 Set Set occurrence Empty Set occurrence Set occurrence Member rec. 3 Member rec. 2 Member record type Member rec.
Linking record types Schema DDL Example RECORD NAME IS SUPPLIER . . . RECORD NAME IS ARTICLE . . . SET NAME IS ARTICLES-AVAILABLE . . . OWNER IS SUPPLIER. MEMBER IS ARTICLE..... . . .
Linking record types A record type can be part of several sets. This makes the set the basic unit in network-like data structures. 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Figure 14: Network-like data structure Relationships between record types There are three possible types of relationships between record types that are to be linked: Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Linking record types Schema DDL Example of a 1:n relationship The relationship between customers and their orders is a 1:n relationship. A customer can place several orders, but each order can only be placed by one customer. ORDER: 1 CUST.: ADAM ORDER: 2 CUST.: ERIC ORDER: 3 CUST.: ERIC ORDER: 4 CUST.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Linking record types m:n relationship between two record types (many-to-many relationship) An m:n relationship is a relationship in which a member record can be associated with more than one owner record. If m:n relationships are to be represented, they have to be broken down into two 1:n relationships.
Linking record types Schema DDL ORDER: 1 CUST.: ADAM RADIO 5 LAMP 1 ORDER: 2 CUST.: ERIC 2 LAMP CLOCK 30 RADIO 1 ORDER: 3 CUST.: ERIC KETTLE 30 1 RADIO ORDER: 4 CUST.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Linking record types The m:n relationship between ORDERS and ARTICLE is resolved to form two 1:n relationships by creating a new record type (auxiliary record type) ITEM which is a member of both ORDERS and ARTICLE. m:n relationship within one record type (parts list processing) In this special case the m:n relationship is not between two record types, but exists within one record type.
Linking record types PART-LIST PART BICYCLE Schema DDL SUBPART PART-LIST PART QTY. WHEEL 1 1 2 1 1 2 HANDLEBAR FRAME WHEEL BELL LAMP FENDER SUBPART RIM SPOKE TIRE QTY. 1 36 1 PART-LIST PART TIRE SUBPART CASING TUBE QTY.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Linking record types 4.6.2 Defining the type of membership of records in a set ⎧MANDATORY⎫ ⎧AUTOMATIC⎫ MEMBER IS record-name ⎨ ⎬ ⎨ ⎬ ⎩OPTIONAL ⎭ ⎩MANUAL ⎭ The records of a member record type do not automatically have to be members in a set occurrence. The type of membership of a record in a set can be defined under two aspects: 1.
Linking record types Schema DDL Example 1 CUSTOMER CUSTOMER-ORDERS-PLACED (OPTIONAL AUTOMATIC) CUSTOMERORDER Figure 18: Example of OPTIONAL AUTOMATIC The link between a CUSTOMER-ORDER record and a CUSTOMER record is relatively stable. An order only exists if a customer has placed one. The link to the owner record is thus automatic at the time the CUSTOMER-ORDER record is stored.
Linking record types Example 2 The MANUAL option is used if, for example, a record type is a member type of two sets and some of its member records are to belong to one set occurrence only. 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL PROJECT EMPLOYEES HEAD (OPTIONAL MANUAL) EMPLOYEE Figure 19: Example of membership in two parallel sets Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Linking record types Schema DDL Example 3 The MANUAL option is used in cyclic data structures, i.e. a number of record types are connected in such a way that each record type is at the same time owner of one set and member in another.
Linking record types Example 4 In order to resolve a many-to-many relationship, it is necessary to define an auxiliary record type. This requires the following types of set membership: 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL ORDERS ARTICLE (MANDATORY AUTOMATIC) (MANDATORY AUTOMATIC) AUX.
Types of access Schema DDL 4.7 Access paths and record sequences The user can define the following access types using DDL: – direct access on record type level A record is selected from all records of one record type via the content of an item or a combination of items. – sequential access on record type level A record is selected on the basis of its position within the logical sequence of all records of the record type.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Types of access 4.7.1 Direct and sequential access on record type level via database key value The database key value is a unique internal record key assigned at the time a record is stored, and retained for the entire life of the record.
Types of access Schema DDL If LOCATION MODE IS DIRECT-LONG is specified, item-name must be defined as a DATABASE-KEY-LONG item. record-name specifies the record type containing the database key item referred to by item-name. identifier specifies the name of an item which is automatically generated by UDS/SQL for storing database key values. This item serves as a key item, but is not part of a record type. If you specify LOCATION MODE IS DIRECT, UDS/SQL generates the identifier item as a DATABASE-KEY item.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Types of access 4.7.2 Generating additional access paths for direct access on record type level Defining a primary key for conversion by hash routine LOCATION MODE IS CALC[ hash-routine] USING item-name,... DUPLICATES ARE[ NOT] ALLOWED With this clause, the user specifies the distributed storage of records on the basis of a hash routine.
Types of access Schema DDL If you want to define a user-specific hash routine, you must observe the following register conventions: ● Before and after running the routine, all UDS/SQL registers except Register 1 must have the same content. The hash routine is branched to by BALR 14,15; return to the UDS/SQL hash routine is effected by BR 14.
Types of access Example 1 The following exemplifies the conversion of a key value into a physical address using the UDS/SQL standard hash routine. Let the key value be 9952333 and the number of pages in the hash area be 503. This results in the following arithmetic operations: 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL 1) Beginning from the left, the key value is subdivided into words (units of four bytes length).
Types of access Schema DDL Example 2 This example shows how a user can program a user-specific hash routine. The program replaces the first two operations of the UDS/SQL standard hash routine by a division/remainder algorithm. The entire key value is considered a positive binary number which is divided by the number of available CALC pages. The algorithm is the same as a normal-type division, the only difference being that three digits are brought down.
Types of access Example in Assembler: BYTEHASH CSECT READ BYTEHASH AMODE ANY BYTEHASH RMODE ANY USING *,15 STM 4,8,12(13) LM 4,7 ALLZEROS L 8,0(0,1) LA 4,0(0,8) BCTR 4,0 LRLRLRLRLRLRLRLRLRLRLRLRLR IC 5,0(0,2) LRLRLRLRLRLRLRLRLRLRLRLRLR DR 6,5 LRLRLRLRLRLRLRLRLRLRLRLRLR HASHBYTE SRDL 6,24 IC 7,0(4,5) D 6,0(0,3) BCT 5,HASHBYTE LR 1,6 LM 4,8,12(13) BR 14 ALLZEROS DC 4F'0' END (1) (2) (3) (1) Register 4 always contains the address before the CALC key.
Types of access Schema DDL Defining secondary keys for conversion by hash routine SEARCH KEY IS item-name,... USING CALC[ hash-routine] DUPLICATES ARE[ NOT] ALLOWED A key declared by SEARCH KEY IS... is a SEARCH key or secondary key. It may consist of more than one item (compound key). item-name specifies the item(s) comprising the key. All items must be part of the corresponding record type. DUPLICATES ARE[ NOT] ALLOWED specifies whether UDS/SQL is to accept or reject duplicate key values.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Types of access Defining a secondary key for direct access via table SEARCH KEY IS item-name,... USING INDEX [NAME IS name] DUPLICATES ARE[ NOT] ALLOWED A key declared by SEARCH KEY IS... is a SEARCH key or secondary key. It may be made up of more than one item. item-name specifies the item(s) comprising the key. All items must be part of the corresponding record type. name specifies the name of the table.
Types of access Schema DDL 4.7.3 Determining the order of records within a set occurrence Two basic concepts in determining the logical order of the member records within a set occurrence can be distinguished: – – sorting without key values, and sorting according to primary key values They are described in detail below.
Types of access ORDER IS LAST Specifies that the order of the member records in a set occurrence corresponds to the chronological sequence in which they are stored. 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL SUPPLIER PURCH-ORDPLACED Moore LAST 14.2.81 14.2.81 12.2.81 PURCHASEORDER 12.2.81 14.2.81 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Types of access Schema DDL ORDER IS FIRST Specifies the reverse order to that in which the member records were chronologically entered. SUPPLIER PURCH-ORDRECEIVED Moore 12.2.81 12.2.81 13.2.81 14.2.81 PURCHASEORDER 14.2.81 FIRST Figure 23: Record sequence for ORDER IS FIRST ORDER IS NEXT/PRIOR If this type of ordering is specified, the database programmer has the possibility of establishing a certain order when storing the member records. The CRS (current record of set), i.e.
Types of access Sets defined with ORDER IS NEXT or ORDER IS PRIOR cannot be accessed by SQL with INSERT or UPDATE. 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL PURCHASEORDER 13.2.81 Water PURCH-ORD-CONTENTS NEXT Beer PURCH-ORDITEM Cocoa Lemonade PRIOR CRS Figure 24: Record order if ORDER IS NEXT/PRIOR Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Types of access Schema DDL Sorting member records according to primary key values ⎧DATABASE-KEY ⎫ ORDER IS SORTED BY ⎨ ⎬ . ⎩DEFINED KEYS DUPLICATES ARE[ NOT] ALLOWED⎭ . . ⎧ASCENDING ⎫ ⎨ ⎬ KEY IS item-name,... ⎩DESCENDING⎭ ORDER IS SORTED BY DEFINED KEYS DUPLICATES ARE[ NOT] ALLOWED Items defined as keys with this ORDER clause are primary keys of a set.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Types of access 24. Oktober 2007 Stand 09:30.23 SUPPLIER Moore ARTICLESAVAILABLE Water Lemonade Cocoa ARTICLE Beer Figure 25: Sorting a set occurrence according to the key ART-NAME ORDER IS SORTED BY DATABASE-KEY Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 UDS/SQL sorts the member records of the set occurrence in ascending order according to the values of the database key.
Types of access Schema DDL 4.7.4 Generating additional paths for direct access on set level Unlike on record level, on set level UDS/SQL supports direct access only via tables. Only SYSTEM sets (see section “SYSTEM set” on page 105) allow direct access via a hash routine. Two kinds of tables can be defined for direct access on set level: – – a table containing the primary key of the set, or one or more tables containing a secondary key (SEARCH key) of the set.
Types of access Example RECORD NAME IS SUPPLIER . . . 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL RECORD NAME IS ARTICLE . . . 01 ARTICLE-NAME PICTURE IS X(30). SET NAME IS ARTICLES-AVAILABLE ORDER IS SORTED INDEXED BY DEFINED KEYS..... OWNER IS SUPPLIER MEMBER IS ARTICLE..... ASCENDING KEY IS ARTICLE-NAME . . . ORDER IS SORTED INDEXED BY DATABASE-KEY Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Types of access Schema DDL Generating an additional access path via secondary key SEARCH KEY IS item-name,... USING INDEX [NAME IS name] DUPLICATES ARE[ NOT] ALLOWED A key defined by means of SEARCH-KEY IS... is called a SEARCH key or secondary key. It may consist of more than one item. item-name specifies the item(s) comprising the key. All items have to be part of the member. name specifies the name of the table. This name is referred to in SSL statements concerning the table.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Types of access 4.7.5 Determining set occurrence selection SET OCCURRENCE SELECTION IS THRU ⎧CURRENT OF SET ⎫ ⎧item-name ⎫ MULOCATION MODE OF OWNER[ ALIAS FOR ⎨ ⎬ IS identifier-2]...MU ⎩ ⎩identifier-1⎭ ⎭ When accessing records via sets, it is first necessary to select the desired set occurrences.
Types of access Schema DDL Simultaneous automatic selection of several owner records from one record type With certain data structures, it may be necessary to select several set occurrences (i.e. several owner records) at the same time when inserting a new member record, where all owner records are part of the same record type. Such a case applies when the following two conditions are met: – Two record types are connected by more than one set.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL OWNER clause and SEARCH KEY clause 4.8 Special sets 4.8.1 SYSTEM set OWNER IS SYSTEM. A record type which is not related to a higher-ranking record type on the basis of its data structure can still be declared member of a set.
OWNER clause and SEARCH KEY clause Schema DDL hash-routine denotes the name of a module converting the secondary key to a 4-byte binary number. This binary number is subsequently converted into a relative page number by UDS/SQL. The corresponding page contains the pointer to the record (see page 213).
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL SEARCH KEY and ORDER clause 4.
Realm concept Schema DDL 4.10 The realm concept In order to take the aspects of – – – – data privacy, data recovery, concurrent access, and the logical association of certain data into account, it is often advisable to subdivide the database into subunits. These subdivisions are called “realms” or “areas”. They are generated as BS2000 files at database creation (see the “Creation and Restructuring” manual, Database creation).
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Realm concept Handling concurrent access When a transaction is opened, the database programmer states the realms to be accessed within the transaction (see the “Application Programming” manual, READY). He can also define usage modes for realms, restricting or prohibiting concurrent access to these realms by other transactions.
Realm concept Schema DDL 4.10.2 Defining allocation of records to realms RECORD NAME IS record-name WITHIN realm-name-1[,realm-name-2,... AREA-ID IS identifier] The allocation of data to realms and the placement of data within realms is performed mainly when defining the physical storage structure by means of SSL (see the section “Defining the placement of member records, tables and hash areas” on page 160). The allocation of records to realms is however defined by means of the schema DDL.
24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL SCHEMA NAME and PRIVACY LOCK clause 4.11 Assigning name and privacy to a schema schema-name [PRIVACY LOCK FOR COPY IS literal-1[ OR literal-2]]. The definition of a database with the schema DDL always begins with the assigning of a name to the schema. schema-name specifies the name assigned to the schema by the user. This name is later referenced by the SSL, the subschema DDL and the utility routines.
DDL example Schema DDL 4.12 Comprehensive example of DDL application This example shows the schema of a mail order business.
DDL example 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
DDL example Schema DDL A rough selection of articles is possible by means of the criteria ARTICLE-TYPE and ARTICLE-SELECTION. This selection leads to a detailed article description. An article description can comprise several articles differing in color, size and price. The sets CONTAINS and CONTAINED-IN comprise a parts list used for parts supply. In the ARTICLE records, colors are coded by numbers, materials in by abbreviations with percentages.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL DDL example Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.23 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 U929-J-Z125-9-76 * * RECORD NAME IS ORD-ITEM WITHIN CUSTOMER-ORDER-RLM. * 01 ORD-NO-ITEM PICTURE IS 99. 01 ORD-QTY TYPE IS DECIMAL 6.
DDL example Schema DDL 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 116 LOCATION MODE IS CALC USING ARTICLE-NAME DUPLICATES ARE ALLOWED WITHIN CLOTHING, HOUSEHOLD-GOODS, SPORTS-ARTICLES, FOOD, LEISURE, STATIONERY AREA-ID IS RLM-SELECTION-3. * 01 ART-NO 01 ARTICLE-NAME 01 MATERIAL 02 PERZENT 02 MAT-CODE 01 LENGTH-FIELD 01 ART-INFO PICTURE IS 9(6). TYPE IS CHARACTER 40.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL DDL example Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.
DDL example Schema DDL 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 118 01 P-ORD-NO-ITEM PICTURE IS 99. 01 P-ORD-QTY TYPE IS DECIMAL 10. * * * SET NAME IS CST-ORD-PLACED ORDER IS SORTED INDEXED BY DEFINED KEYS DUPLICATES ARE NOT ALLOWED OWNER IS CUSTOMER.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL DDL example Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.
DDL example Schema DDL 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 120 ASCENDING KEY IS SUPPL-NAME, SUPPL-NO. * * SET NAME IS ARTICLES-AVAILABLE ORDER IS SORTED INDEXED BY DEFINED KEYS DUPLICATES ARE ALLOWED OWNER IS SUPPLIER.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL DDL example Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.23 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 U929-J-Z125-9-76 * * SET NAME IS SET IS DYNAMIC ORDER IS IMMATERIAL OWNER IS SYSTEM.
DDL example Schema DDL 373 374 375 376 122 SET NAME IS SET IS DYNAMIC ORDER IS IMMATERIAL OWNER IS SYSTEM.
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k04 Schema DDL Reserved words of the DDL compiler 4.
Reserved words of the DDL compiler 124 Schema DDL COMPUTE CONFIGURATION CONNECT CONSOLE CONTAINS CONTROL CONTROLS COPY CORR CORRESPONDING COUNT CREATING CSP CURRENCY CURRENT CURRENT-DATE CYCLES CYLINDER-OFLO DATA DATABASE-EXCEPTION DATABASE-KEY DATABASE-KEY-LIST DATABASE-KEY-LONG DATABASE-KEY-NAME DATABASE-KEY-RANGE DATABASE-KEYTRANSLATION-TABLE DATABASE-PRIVACY-KEY DATABASE-REALM-NAME DATABASE-RECORD-NAME DATABASE-SET-NAME DATABASE-STATUS DATE DATE-COMPILED DATE-WRITTEN
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Reserved words of the DDL compiler 126 Schema DDL MEMBERS MEMBERSHIP MEMORY MERGE MESSAGE MINUS MIXED MODE MODIFY MODULES MORE-LABELS MOVE MULTIPLE MULTIPLY NAME NAMED NATIONAL NATIVE NEGATIVE NEXT NO NOT NOTE NUMBER NUMERIC OBJECT-COMPUTER OCCURRENCE OCCURS OF OFF OH OMITTED ON ONES ONLY OPEN OPT OPTIMIZATION OPTIONAL OR ORDER ORGANIZATION OTHER OTHERWISE OUTPUT OV OVERFLOW OWNER PA PAGE PAGE-COUNTER PAGES PERCENT PERFORM PERMANENT PF PH PHYSICAL
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 09:30.23 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Reserved words of the DDL compiler 128 Schema DDL SUPPRESS SYMBOLIC SYNC SYNCHRONIZED SYSIN SYSIPT SYSLST SYSOPT SYSOPT-234 SYSOUT SYSPUNCH SYSRDR SYSTEM TABLE TALLY TALLYING TAPE TAPES TEMP TEMPORARY TENANT TERMINAL TERMINATE TEXT THAN THEN THROUGH THRU TIME TIMES TO TODAYS-DATE TOP TRACE TRACK-AREA TRACKS TRAILING TRANSFORM TRY TYPE UNDER UNIT UNITS UNSTRING UNTIL UP UPDATE UPON USAGE USAGE-MODE USE USING VALUE VALUES VARYING VIA WHEN WITH WITHI
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 24. Oktober 2007 Stand 08:58.55 5 SSL 5.1 Introduction The schema DDL is used to describe the logical structure of the data; the Storage Structure Language SSL is used to specify the physical storage structure when storing data and logical relationships between data. The definition of the physical storage structure is optional. If it is omitted, UDS/SQL applies the default values.
Introduction SSL 5.1.1 Methods of physical representation of the logical data structure The physical representation of the entirety of ● ● all records of a record type: DBTT (Database Key Translation Table) Table representing all records of a record type and linking all owner records to the tables of their set occurrences. Record SEARCH key table Table representing all records of a record type.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Introduction 5.1.2 DBTT (Database Key Translation Table) The DBTT establishes the link between the database key value of a database record and the physical page address of that record. Structure of a physical page address The total space available for storing data in the database is divided into realms.
Introduction SSL Structure of a database key value To find the physical address of records and associated tables, UDS/SQL can always make use of an additional identifier, the database key value, which never changes during the life of a record in the database. A record type consists of a number of records which are consecutively numbered. The record types are also numbered. The record sequence number (RSQ) and record type reference (REC-REF) are combined to form the database key value of the record.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Introduction The following applies to the value range for a record sequence number (RSQ): – 1 ≤ RSQ ≤ 224-1 for databases with a 2048-byte page length if the record type is not an owner in any set. – 1 ≤ RSQ ≤ 224- 216- 1 for databases with a 2048-byte if the record type is an owner in a set.
Introduction SSL Database key value for page length of 2048 bytes REC- REF 0 5 DBTT of r ecor d type 05 Colu mn 0 RSQ 0 0 1 b yte 0 0 0 3 Line 3 3 bytes 0 4 0 0 0 0 8 3 Database k ey value for page length of 4000/8096 bytes no t REC- REF u se d 00 05 RS Q Line 3 00 00 00 03 2 bytes 2 bytes 4 bytes 0 6 0 0 0 0 1 4 Line 9 0 5 0 0 0 0 0 9 1 b yte Re al m 01 3 bytes Re al m 04 Re al m 06 001 002 003 004 001 002 00 3 004 001 002 003 004 018 019 01A 01B 083 084 08 5 0
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Introduction If the placement of records changes, updating of the page addresses can be limited to the DBTT. In addition to the page addresses of the owner records, the DBTT of an owner record type contains the page addresses of all tables pertaining to the set occurrences of the owner records.
Population SSL 5.2 Declaring the population 5.2.1 Specifying the number of records in one record type The number of records included in one record type is defined in the DBTT and in the record POPULATION clause. Using this number UDS/SQL computes: – – – the storage space requirement for the DBTT, the hash area size for the primary key, the hash area sizes for secondary keys.
Population Note, however, that UDS/SQL always creates only as many DBTT pages as required for the DBTT and that, depending on the database page length, a maximum of 224-1 or 224- 216- 1 (=16711679) or 231-1 entries per DBTT can be administered. Since a DBTT base can only be created in whole pages and a DBTT extent only in DBTT extent size (128 PAM pages), an excess amount is usually created if the maximum values are specified. This excess amount is not used.
Population SSL Size of a hash area for the primary key POPULATION IS {integer WITHIN realm-name},... The hash area for the primary key of a record type is distributed over several realms if the records of the record type are allocated to several realms by means of the schema DDL (see the section “Defining allocation of records to realms” on page 110). integer specifies the number of records to be stored in the realm referenced by realm-name.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Population Size of the hash area for a secondary key DATABASE-KEY-TRANSLATION-TABLE IS integer integer specifies the number of records of a record type. – If the database has a page length of 2048 bytes, you may specify a maximum value of 224-1 for integer. If the record type in question is the owner in a set, the maximum possible value for integer is 16 711 679.
Population SSL 5.2.2 Specifying the size of the set occurrences of a set POPULATION IS integer The size of the set occurrences must be specified in the following cases: – if you want to store tables and member records in the proximity of the associated owner records, – if you want to facilitate subsequent table extensions, – if you want to specify the size of a hash area for secondary keys in a SYSTEM set in order to avoid overflow pages. integer specifies an average set occurrence population.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Population When storing an owner record, UDS/SQL reserves: – – the calculated storage space, if it is smaller than one page, one page, if the calculated storage space is greater than one page. for each table belonging to the associated set occurrence. In the case of SYSTEM sets, UDS/SQL reserves exactly one database page for each table, regardless of the POPULATION clause.
Population SSL Size of the hash area for a secondary key Only in the case of SYSTEM sets can a secondary key be used for conversion by a hash routine. UDS/SQL calculates the minimum number of pages required for distributed storage of record addresses on the basis of the set occurrence population entry (see the section “Indirect CALC page” on page 213) and then reserves the number of pages corresponding to the next higher prime number.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Population 5.2.
Linkage methods SSL 5.3 Determining the linkage of records 5.3.1 Determining the storage mode for set occurrences UDS/SQL offers three different storage modes for linking member records to form a set occurrence.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods Storing a set occurrence as a pointer array MODE IS POINTER-ARRAY If MODE IS POINTER-ARRAY is defined for a set, UDS/SQL links the member records of its set occurrences via a table called a pointer array. This table contains pointers to each member record of a set occurrence.
Linkage methods SSL Moore . . . . . . . . . DBTT . . . . . . . . . Owner record Pointer array Member records . . . Beer Cocoa Beer . Gin Cocoa . . Milk . . . . Gin Primary key RSQ + PPP Milk . . . . . . Figure 33: Set occurrence stored as a pointer array If a pointer array occupies more than one page, each page is connected by act-keys twice. If ORDER IS SORTED INDEXED, the pointer array is provided with additional higherranking table levels.
Linkage methods Additional pointer from owner to its pointer array MODE IS POINTER-ARRAY.....WITH PHYSICAL LINK The standard UDS/SQL link between an owner record and the pointer array of its member records is via the DBTT. The user can bypass the DBTT and save one page access by specifying WITH PHYSICAL LINK, which generates a pointer to the pointer array in the owner record. DBTT . . . . . . . . . Owner record . Pointer array Member records . . . Beer Cocoa Beer Gin . . Cocoa . Milk .
Linkage methods SSL Storing a set occurrence as a list MODE IS LIST If a set is defined with MODE IS LIST, UDS/SQL stores the member records of a set occurrence in a table called a list. The physical sequence of the records corresponds to the logical sequence defined in the ORDER clause. Moore . . . . . . . . . DBTT . . . . . . . . . Owner record List Beer . . . Gin Cocoa . . . . . . Milk . . .
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods The physical placement of records can be defined only once: – If a record type is a member of several sets, only one of the sets can be defined with MODE IS LIST. – It is not possible to define records with MODE IS LIST and PLACEMENT OPTIMIZATION at the same time (see the section “PLACEMENT OPTIMIZATION” on page 165).
Linkage methods SSL Additional pointer from owner to its list MODE IS LIST.....WITH PHYSICAL LINK The UDS/SQL standard connection between an owner record and the list of its member records is via the DBTT. The user can bypass the DBTT and save one page access by specifying WITH PHYSICAL LINK, which generates a pointer to the list in the owner record. . Moore . . . . . . . . . DBTT . . . . . . . . . Owner record List Beer . . . Gin Cocoa . . . . . . Milk . . .
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods Storing a set occurrence as a chain MODE IS CHAIN If MODE IS CHAIN is defined for a set, each set occurrence of the set is stored as a closed chain of records. The chain comprises the owner record and all member records of the set occurrence. The member records are chained by means of pointers in the order defined in the ORDER clause for the set in the schema DDL.
Linkage methods SSL Additional backward chaining for chain MODE IS CHAIN LINKED TO PRIOR In addition to standard forward chaining, the records of a chain can be concatenated in reverse order. If LINKED TO PRIOR is specified, a further pointer is added to each record pointing to the logically preceding record. In the same way as forward chaining, the pointer is composed of the database key value of the preceding record and the PPP of the page containing this record. . . . . Milk Cocoa . . . . .
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods 5.3.2 Assessing pointer array, list and chain The time required for the execution of a program depends on the storage modes defined for the set occurrences. This section compares retrieval and updating operations when using pointer arrays, lists and chains. The retrieval operations are subdivided into sequential and direct accesses. Updating operations dealt with are insertion and deletion.
Linkage methods SSL List ● Sequential access If MODE IS LIST, the records are grouped together in a contiguous storage area. This storage mode offers fastest sequential processing. The number of accesses when processing large numbers of records depends on the record length. ● Direct access If ORDER IS SORTED INDEXED, all levels of the list must be in memory. The higher levels are used to select the number of the page containing the record. One disk access is required for each level of the table.
Linkage methods Chain ● Sequential access When records are processed in their logical order, a maximum of one disk access for each member record is required. The number of accesses can be considerably reduced by optimizing the placement of the records (see page 165). If the logical order is not adhered to, UDS/SQL will normally have to search large parts of the set occurrence which may involve a large number of disk accesses.
Linkage methods ● SSL Deletion UDS/SQL must find the record to be deleted and also the record preceding it. This requires less time if backward chaining has been specified. In the case of backward chaining, UDS/SQL must also update the pointer in the subsequent record. If ORDER IS SORTED INDEXED, the entry made for this record in the sort key table must be deleted. ● Result MODE IS CHAIN allows fast sequential access if the records are processed in the sequence defined in the ORDER clause.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods 5.3.3 Preventing redundancy in SEARCH key tables TYPE IS DATABASE-KEY-LIST In the description of the logical data structure drawn up using the schema DDL, the user decides if UDS/SQL is to set up a SEARCH key table (SEARCH KEY IS... USING INDEX). The form of this table can be influenced by means of the TYPE clause.
Linkage methods SSL Standard SEARCH key table RSQ+PPP Duplicates table 1923 . 1923 . 1923 . 1945 . Byrne 1945 . Wagner 1945 . 1945 . 1945 . 1923 Miller Martin Walker Smith Sands Vogel 1923 1923 1945 1923 . . . 1945 . . . RSQ . . 1945 1945 1945 1945 Figure 39: Comparison of standard SEARCH key table with duplicates table The pointers in the duplicates table are the RSQs of the associated records.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Linkage methods 5.3.4 Adding a pointer to link a member to its owner MEMBER IS PHYSICALLY LINKED TO OWNER This entry specifies that each member record of a set is provided with a pointer to the associated owner record. This pointer is a PPP. It optimizes access to the owner record if one of its member records has already been selected (see the "Application Programming" manual, FIND 6).
Placement SSL 5.4 Defining the placement of member records, tables and hash areas The SSL provides options to define the placement of the following objects: – – – – – – – member records lists pointer arrays sort key tables SEARCH key tables DBTTs hash areas.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL 5.4.1.1 Placement Placement at realm level The following clauses are used to allocate data to certain realms without specifying its position within the realm. Owner record, member records WITHIN clause of the schema DDL (see the section “Defining allocation of records to realms” on page 110).
Placement SSL If no entry is made for a set SEARCH key table or hash area, UDS/SQL selects the realm according to the following principle: Is the set a SYSTEM set? No Realm of the associated owner record Yes Has a realm name been defined for the list, pointer array or sort key table of set? Yes No Specified realm Yes Has a realm name been defined for the first secondary key defined for this set in the schema DDL? No First realm specified in the DDL WITHIN clause for the member record type Figu
5.4.1.2 Placement Placement within a realm Within a realm, data belonging to one set occurrence can be stored contiguously. If, for example, member records are stored as list, they are physically stored in one page until the page is completely filled. The other possibilities relate to the storage of member records and the associated tables in the proximity of the owner record.
Placement SSL Natural optimization If the user does not influence the placement of data within a realm by means of the DDL and SSL, UDS/SQL physically stores the data in the chronological order in which it is entered. Thus, at initial load time or later on when running unload or load programs, the user can select the load sequence in such a manner that a complete set occurrence with all associated tables is stored in contiguous pages.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Placement PLACEMENT OPTIMIZATION PLACEMENT OPTIMIZATION FOR SET set-name set-name specifies the name of the set to be optimized as an access path. It must not be a SYSTEM set. This entry is to be added to the member record type of the set.
Placement SSL MODE clause ⎧POINTER-ARRAY⎫ MODE IS ⎨ ⎬ ATTACHED TO OWNER ⎩LIST ⎭ This entry is not permitted in SYSTEM sets. If a set occurrence population greater than zero has been specified for the set (see the section “Specifying the size of the set occurrences of a set” on page 140), UDS/SQL sets up all the tables of a set occurrence subsequent to the owner record when the owner record is stored.
Placement INDEX clause INDEX NAME IS name PLACING IS ATTACHED TO OWNER This entry is not permitted for SYSTEM sets. It is used to place tables of primary and secondary keys in the proximity of the associated owner. For further details on the ATTACHED entry see the MODE clause. name specifies the name of the table to be placed. It must have been assigned in the schema DDL (see the section “Assigning names to hash areas and tables” on page 107). Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.
Placement SSL 5.4.2 Defining the placement of record SEARCH key table, DBTT and record hash areas For this data, the user can specify only the realm in which it is to be stored. The following clauses are used to allocate data to specific realms: Record SEARCH key table NDEX NAME IS name PLACING IS WITHIN realm-name DBTT DATABASE-KEY-TRANSLATION-TABLE WITHIN realm-name Hash area for primary key POPULATION IS {integer WITHIN realm-name},...
Placement Example DDL: SET NAME IS CUSTOMER-ORDERS-PLACED . . . OWNER IS CUSTOMER. MEMBER IS CUSTOMER-ORDER . . . 24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL SSL: RECORD NAME IS CUSTOMER-ORDER PLACEMENT OPTIMIZATION FOR SET CUSTOMER-ORDERS-PLACED. SET NAME IS CUSTOMER-ORDERS-PLACED POPULATION IS 10 MODE IS POINTER-ARRAY ATTACHED TO OWNER INDEX NAME IS SEARCH-TAB-C-ORD-PLCD PLACING IS DETACHED.
Placement SSL 5.4.3 Overview of placement statements Type of WITHIN data realmname,... Member records in set with LOCATION MODE IS CALC OWNER PLACEMENT MODE IS OPTIMIZAIS SYSTEM TION FOR SET ...
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
REORGANIZATION clause SSL 5.5 Defining the extent of table reorganization desired DYNAMIC REORGANIZATION SPANS integer PAGES If, when records are stored, the storage space requirements are formed to exceed those initially calculated on the basis of the POPULATION clause, UDS/SQL automatically performs a table extension. A table that is not quite the size of a page but that cannot be extended by at least two table lines within its page is continued in a further page by UDS/SQL.
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL REORGANIZATION clause In case 1), the occupancy level is dependent on the integer specified. It must not fall below the following value: integer Minimum occupancy level [%] = LRLRLRLRLRLRLRLRLR x 100. integer+1 This means that high occupancy levels are most easily obtained if records are stored in sorted order. High occupancy levels reduce storage space requirements for tables and result in shorter access paths.
REORGANIZATION clause SSL In order to insert record 650 (see below), UDS/SQL must set up a new page, since page 2 is completely occupied. The new page accepts as many entries from page 2 as is necessary to ensure even distribution of records over the two pages.
REORGANIZATION clause DYNAMIC REORGANIZATION SPANS 3 PAGES Based on figure 43, the following situation results from inserting record 650. 24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Page 1 Page 2 Page 3 Page 4 216 650 894 1011 470 709 950 611 715 801 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
COMPRESSION clause SSL 5.6 Storing the records of a record type in compressed form COMPRESSION FOR ALL ITEMS A record type containing an item of variable length may not be compressed. Under CALL DML, records can be compressed by storing only part of the items belonging to the record type (see the "Application Programming" manual, STORE 2).
24. Oktober 2007 Stand 08:58.55 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL Calculation formulas 5.7 Formulas for calculating the storage space requirements for records and tables The storage space requirement for records varies depending on whether they are stored in a direct hash area, whether an indirect hash area is set up for them and which type of connection has been specified for them. table 10 and table 11 contain formulas to calculate the storage space requirement.
Calculation formulas SSL Calculation formulas for a database with a 4000 or 8096-byte page length Number of records in the data page page length-20 LRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLR record length1 +12 in the direct CALC page page length-30 LRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLR record length+key length+22 Number of entries in the indirect CALC page page length-30 LRLRLRLRLRLRLRLRLRLRLRLRLRLR key length+10 List Number of table entries per page in a: page length-50 LRLRLRLRLRLRL
SSL example 5.8 Comprehensive example of SSL application STORAGE STRUCTURE OF SCHEMA MAIL-ORDERS. * * RECORD NAME IS CUSTOMER DATABASE-KEY-TRANSLATION-TABLE IS 100. * RECORD NAME IS CST-ORDERS DATABASE-KEY-TRANSLATION-TABLE IS 400 PLACEMENT OPTIMIZATION FOR SET CST-ORD-PLACED. * RECORD NAME IS ORD-ITEM DATABASE-KEY-TRANSLATION-TABLE IS 1000. * RECORD NAME IS INSTALMENT DATABASE-KEY-TRANSLATION-TABLE IS 50 INDEX NAME IS SEARCH-TAB-INSTALMENT TYPE IS DATABASE-KEY-LIST.
SSL example SSL 250 WITHIN INDEX NAME PLACING IS INDEX NAME PLACING IS STATIONERY IS SEARCH-TAB-ARTICLE-1 WITHIN ARTICLE-RLM IS SEARCH-TAB-ARTICLE-2 WITHIN ARTICLE-RLM. * RECORD NAME IS MATERIALS INDEX NAME IS SEARCH-TAB-MATERIAL-1 DYNAMIC REORGANIZATION SPANS 5 PAGES INDEX NAME IS SEARCH-TAB-MATERIAL-2 DYNAMIC REORGANIZATION SPANS 5 PAGES. * RECORD NAME IS SUPPLIER DATABASE-KEY-TRANSLATION-TABLE IS 500 POPULATION IS 200 WITHIN PURCHASE-ORDER-RLM.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k05 SSL SSL example Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 24. Oktober 2007 Stand 08:58.55 SET NAME IS CONTAINING POPULATION IS 10 MEMBER IS PHYSICALLY LINKED TO OWNER. * SET NAME IS CONTAINED-IN MODE IS CHAIN LINKED TO PRIOR MEMBER IS PHYSICALLY LINKED TO OWNER.
Reserved words of the SSL compiler SSL 5.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 18. Oktober 2007 Stand 11:29.49 6 Definition of the user interface to the database 6.1 Subschema DDL 6.1.1 Introduction All data the database requires to perform its tasks must be defined in the UDS/SQL schema. The UDS/SQL schema has no direct interface with the user, however; aspects of user-oriented data editing must not be considered when designing the UDS/SQL schema. The user interface is created when the subschema is defined.
Subschema DDL User interface 6.1.2 Assigning name and privacy to a subschema SUB-SCHEMA NAME IS subschema-name OF SCHEMA NAME schema-name [PRIVACY LOCK FOR COMPILE IS literal-1[ OR literal-2]] subschema-name specifies the name of the subschema and is assigned by the user. Within one DB configuration, subschema-name must be unique in the first 6 characters. schema-name specifies the schema from which the subschema is derived.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 User interface Subschema DDL 6.1.4 Copying entire record types from the schema into the subschema Format 1: COPY ALL RECORDS. Format 2: COPY record-name,... . Format 1 is used if all record types in the schema are to be copied in their entirety into the subschema. Format 2 is used if only part of the record types in the schema are to be copied into the subschema.
Subschema DDL User interface Copying a numeric item, an alphanumeric item of fixed length or a national item level-number item-name PICTURE IS mask-string ⎧DISPLAY ⎫ COMPUTATIONAL-3 [USAGE IS ⎨ ⎬]. COMPUTATIONAL ⎩NATIONAL ⎭ In level-number, the user specifies if an item is to belong to a group item. If the item is not to belong to a group item, the level number specified must be the lowest of any record element in the record type. It may not be lower than 02.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 User interface Subschema DDL The item definition with PICTURE and USAGE clauses can be derived from the following table 12, where n, m and l denote integers.
Subschema DDL User interface Copying a database key item ⎧DATABASE-KEY ⎫ level-number item-name USAGE IS ⎨ ⎬. ⎩DATABASE-KEY-LONG⎭ In level-number, the user specifies if an item is to belong to a group item. If the item is not to belong to a group item, the level number specified must be the lowest of any record element in the record type. It may not be lower than 02. If the item is already part of a repeating group in the schema, it must be defined as part of the same group item in the subschema.
Subschema DDL Copying a vector and reducing it if required level-number vector-name PICTURE IS mask-string ⎧DISPLAY ⎫ COMPUTATIONAL-3 18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 User interface [USAGE IS ⎨COMPUTATIONAL ⎬] NATIONAL DATABASE-KEY ⎩DATABASE-KEY-LONG⎭ [OCCURS integer TIMES]. A vector is an item with a repetition factor. The repetition factor indicates how many duplicates of the item are grouped into the vector.
Subschema DDL User interface Copying a repeating group and reducing it if required level-number-1 group-item-name[ GROUP-USAGE IS NATIONAL] [ OCCURS integer TIMES]. {level-number-2 record-element-name PICTURE..... USAGE..... OCCURS.....}.... A repeating group is a group item with repetition factor. The repetition factor indicates the number of duplicates of this group item to be grouped into the repeating group. A repeating group must be copied into a subschema if one of its items is to be copied.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 User interface Subschema DDL Grouping record elements into a group item level-number-1 group-item-name[ GROUP-USAGE IS NATIONAL] [ OCCURS integer TIMES]. {level-number-2 record-element-name PICTURE..... USAGE..... OCCURS.....}.... A group item is a named group of record elements within a record type. A record element can be an item, a vector or even a group item. group-item-name specifies the name of a group item.
Subschema DDL User interface Defining a condition Detailed information is provided in the COBOL2000 “Language Reference Manual”. 88 condition-name ⎧VALUE IS ⎫ ⎨ ⎬ {literal-1[ THROUGH literal-2]},... . ⎩VALUES ARE⎭ The database programmer can make the execution of program statements dependent on conditions. A condition can be that certain items have certain item contents. Such items are then referred to as condition variables.
18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k06 User interface Subschema DDL 6.1.6 Copying sets from the schema into the subschema Format 1: COPY ALL SETS. Format 2: COPY set-name-1,... . Format 1 is used if all the sets in the schema are to be copied into the subschema. Format 2 is used if only some of the sets in the schema are to be copied into the subschema. set-name specifies the sets to be copied.
Subschema DDL User interface 6.1.7 Copying realms from the schema into the subschema Format 1: COPY ALL AREAS. Format 2: COPY realm-name,... . Format 1 is used if all the realms in the schema are to be copied into the subschema. Format 2 is used if only some of the realms in the schema are to be copied into the subschema. realm-name specifies the realms to be copied. All realms that contain data relating to the record types and sets of the subschema and that the subschema user requires, must be copied.
Subschema DDL (example) 6.1.8 Comprehensive example of subschema DDL IDENTIFICATION DIVISION. SUB-SCHEMA NAME IS ADMIN OF SCHEMA MAIL-ORDERS PRIVACY KEY FOR COPY IS "SHIP-KEY". * * * DATA DIVISION. * AREA SECTION. COPY ALL AREAS. * RECORD SECTION. COPY ALL RECORDS. * SET SECTION. COPY ALL SETS. * * * Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. Oktober 2007 Stand 11:29.49 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Relational schema User interface 6.2 Relational schema The schema DDL can be used to create a schema complying with relational rules or with CODASYL rules. A schema defined according to relational rules contains no set relationships, and the primary and foreign keys are defined by the user. If a schema was defined according to CODASYL rules, the utility routine BPSQLSIA can be used to provide SQL programmers with a relational view of the CODASYL subschema.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 18. Oktober 2007 Stand 11:29.50 7 Structure of pages When creating a database using DDL and SSL, the user does not usually require information on the structure of pages, records and tables. The following two chapters are intended as a reference section for users interested in special details. The entire storage space provided for the data in a database is divided into realms.
Structure of pages The following sections describe the page container and the various types of pages in detail. These descriptions of the individual page types are restricted to the pages themselves, i.e. the header and trailer for pages with a length of 4000 or 8096 bytes are not shown. Displacement values for individual page areas are always with reference to the start of the page. Unless explicitly specified otherwise, the given description applies to pages with lengths of 2048, 4000 and 8096 bytes.
Page container 7.1 Page container 1 18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages Header 64 bytes 65 Page 4000 bytes or 8096 bytes Trailer 32 bytes 4096 bytes or 8192 bytes 4064/8160 4096/8192 Figure 46: Structure of the page container for pages with a length of 4000 or 8096 bytes Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Act-key-0 page / act-key-N page Structure of pages 7.
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages Act-key-0 page / act-key-N page Meaning of the bytes Byte Meaning 1-4 The act-key specifies the address of the page. Since the act-key-0 page is always the first page in a realm, the act-key of this page always contains page number 0. 19-20 The page length can be 2048, 4000 or 8096 bytes. 21-24 Specifies the act-key of the first FPA base page.
FPA page Structure of pages 7.3 FPA page FPA pages constitute one level of the three-level UDS/SQL Free Place Administration and are used to administer free place on the realm level. There is also a free place administration facility on the page and table levels. Note that if a database page contains tables, the value specified in the FPA page does not always indicate storage space actually occupied. Every FPA page contains a separate act-key, which specifies the address of the page.
FPA page Structure of an BASE FPA page with a length of 2048 bytes 1 4 own act-key 18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages 5 page 0=0 2 7 9 2 page 1 ...
FPA page Structure of pages Structure of an FPA extent page with a length of 2048 bytes or of an FPA page with a length of 4000 or 8096 bytes 1 page control information 5th. byte: X‘03‘ (identifier for FPA page) 20 21 page 0=0 2 page 1 2 23 25 ...
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages DBTT pages 7.4 DBTT pages For each record type, UDS/SQL requires a table - known as the DBTT (Database Key Translation Table) - in which all the currently stored records are administered via a database key. Basically, this is an index in the DBTT which points to the physical address of the record in the database as recorded in the table.
DBTT pages Structure of pages 1 1 Page header Own act key 4 20 21 5 29 X‘04‘ (Identifier for DBTT anchor page) 1 6 Beginning of DBTT base 4 19 33 Page length 35 2 Number of DBTT lines of DBTT base 4 39 41 45 total number of DBTT lines of DBTT 4 total number of DBTT extents 4 49 63 65 69 Number of DBTT extents in this page 2 Act key of the next DBTT anchor page 4 Act-Key of the preceding DBTT anchor page 4 73 81 84 Block number Beginning of 1st DBTT extent 3 Block number Beginning o
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages DBTT pages 7.4.2 DBTT page This section describes the layout of a DBTT page and the structure of the DBTT entries in terms of lines and columns. There is precisely one DBTT line for each record of a record type. In the case of record types which are not owner record types, the DBTT consists of only column 0, which contains the act-keys of the records.
DBTT pages Structure of pages Structure of a DBTT page with a length of 2048 bytes For record types which are not owner In owner record types 1 Own act key 5 Column 0 Column 1 4 DBTT line 4 4 Table act key 5 Rec. act key Rec.
DBTT pages Structure of a DBTT page with a length of 4000 or 8096 bytes For record types which are not owner 1 18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages 5 In owner record types Own act key 4 X'02' (Identifier for DBTT) 1 6 Free 13 19 Page length 2 21 25 4 4 Table act key 21 Rec act key Rec act key Column 0 Column 1 4 DBTT line Set 1 Column 0 Table act key 4 DBTT line Dokuschablonen 19x24 Version 7.
Direct CALC page Structure of pages 7.5 Direct CALC page Depending on which page length was defined for the database, the length of a direct CALC page may be 2048 bytes, 4000 bytes or 8096 bytes.
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Direct CALC page Structure of pages Meanings of bytes 1-28 or 1-32 Byte Meaning 1-4 specifies the address of the page 13-16 contains the length and the beginning of the free space. Since the free place is filled with records starting from the CALC table header, the first record stored in the page borders on the CALC table header. The free place begins after the last page index entry and ends before the first record.
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages Indirect CALC page 7.6 Indirect CALC page Indirect CALC pages are created for a record type stored with LOCATION MODE IS CALC if the record type was simultaneously defined with the SSL as one of the following: – – – as a member with MODE IS LIST or with PLACEMENT OPTIMIZATION or with COMPRESSION FOR ALL ITEMS. Indirect CALC pages are always set up when SEARCH KEY USING CALC has been specified.
Indirect CALC page Structure of pages 1 1 Page header Own act key 20 21 4 5 Free 8 13 length 15 Free space 2 beginning Free space 17 19 CALC table header Key value Record RSQ CALC table line 3/6 10 2 Number of page index entries = 0 2 Beginning of CALC table header 2 Number of reserved lines 2 Number of occupied lines 2 forward PPP of the record 4 Chaining 3 backward 3 CALC table line Figure 54: Structure of an indirect CALC page 214 U929-J-Z125-9-76
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages Data page 7.7 Data page Depending on which page length was defined for the database, the length of a data page may be 2048 bytes, 4000 bytes or 8096 bytes.
Data page Structure of pages 21 1 Database key value 1 Page header 4/8 20 25/29 DBTT column 1 26/30 Status 27/31 Beginning of record or table 21 Own act key Free Page index entry 8/12 1 4 5 8 13 length 2 Free space 15 beginning 2 2 17 19 Page index entry Number of page index entries Page length 2 2 8/12 Free space Record or table Record or table Figure 55: Structure of a data page 216 U929-J-Z125-9-76
18. Oktober 2007 Stand 11:29.50 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k07 Structure of pages Data page Meanings of bytes 1-28 or 1-32 Byte Meaning 1-4 contains the address of the page. 13-16 specifies the length and the beginning of the free space. Since the free space is filled with records and tables starting at the end of the page, the beginning of the free space borders on the last stored record or table.
Data page 218 Structure of pages U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k08 24. Oktober 2007 Stand 12:03.14 8 Structure of records and tables In general, the user requires no information on the structure of records and tables when defining a database by means of DDL and SSL. This chapter is a reference chapter for users interested in particular details. 8.
Record structure Structure of records and tables If a variable item or compression has not been defined for a record type, its records are stored in the format below: Record (as per schema) SCD Set Set n 1 Figure 56: Standard format of a user-defined record The following format is used to store the records of a record type if a variable item or compression has been specified for it: SCD Compression Compression header entry No. of comp. entries Rec.
Record structure Anchor record In addition to the records defined in the schema DDL, UDS/SQL automatically generates one anchor record for each SYSTEM set. In SYSTEM sets, the anchor record assumes the function that the DBTT of an owner record type performs in a normal set. The anchor record contains its own act-key as well as the act-keys of the tables belonging to the SYSTEM set. It is extended by SCD if the records of the SYSTEM set are stored as a chain. Dokuschablonen 19x24 Version 7.
Record structure Structure of records and tables Set connection data When a record is stored, UDS/SQL automatically adds set connection data (SCD) if the record has to be connected with other records or tables. table 20 shows what the SCD consists of in each case. The length of the SCD may vary, depending on which page length was defined for the database. The effect of the database page length on that of the SCD is indicated in table 20 in the column “SCD length in bytes” by means of 2 values (e.g.
24. Oktober 2007 Stand 12:03.14 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Table structure Structure of records and tables 8.2 Structure of tables 1 Page header 20 21 Page index entry 8/12 29/33 Page index entry 8/12 Free space No. of reserv. 2 lines No. of occupied 2 lines next page 3 Chaining prev.
24. Oktober 2007 Stand 12:03.14 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k08 Structure of records and tables Table structure Explanation of figure 58: 1) follows the last table line in the case of lists. 2) bit 27 =1: list 26 =1: multi-level table 25 =1: table ATTACHED TO OWNER 24 =1: duplicates table 3) does not apply to duplicates tables (see figure 60 and figure 61). 4) applies to the highest table page of a multi-level table or to the first table page of a single-level table only.
Table structure Structure of records and tables The following overview shows which of the three available table lines corresponds to which table type: DDL/SSL clauses Table type Content of a table line: lowest level MODE IS POINTER-ARRAY ORDER IS LAST/ FIRST/NEXT/PRIOR MODE IS POINTER-ARRAY ORDER IS SORTED INDEXED BY DATABASE-KEY single-level RSQ, PPP - multi-level RSQ, PPP RSQ, act-key multi-level key value, RSQ, PPP MODE IS LIST ORDER IS LAST/ FIRST/NEXT/PRIOR single-level member record -
24. Oktober 2007 Stand 12:03.14 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k08 Structure of records and tables DDL/SSL clauses Table structure Table type MODE IS CHAIN ORDER IS SORTED INDEXED BY DATABASE-KEY MODE IS CHAIN ORDER IS SORTED INDEXED BY DEFINED KEYS ASCENDING/ DESCENDING KEY IS... SEARCH KEY IS... USING INDEX multi-level SEARCH KEY IS...
Table structure Structure of records and tables DBTT of owner record type Page header Page index Free space Table header Level 2 30125 60073 81010 Page header Page index Table header 350 523 Page header Page index Table header 30289 30450 30125 60073 Page header Page index Table header 134 198 Page header Page index Table header 355 365 Page header Page index Table header 60280 Level 1 81010 350 Page header Page index Table header 80635 80650 81010 523 Records Level 0 Records Records
Table structure Duplicates table 1 Page header 24. Oktober 2007 Stand 12:03.14 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k08 Structure of records and tables 20 21 Page index entry 8/12 29/33 Beginning of 3) duplicates header 2 Page index entry 8/12 Free space No. of table index entries next Chaining page prev. page Type2) Occupied space Level Table header 18 Key value 2 Next overflow page 3 © cognitas GmbH 2001-2007 Preceding overflow page No.
Table structure Structure of records and tables The lengths of the entries for the database key value, the record sequence number (RSQ), and for the page index entries depend on the page length that was defined for the database: 230 – In tables of a database with a 2048-byte page length, the entry for the database key value is 4 bytes long; the RSQ entry is 3 bytes, and the page index entry is 8 bytes.
Table structure Overflow page of a duplicates table 21 24. Oktober 2007 Stand 12:03.14 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k08 Structure of records and tables Internal information 1 22 Page number for 3 table header 25 Free (only for 4000/ 8096-byte pages) 4 25/29 26/30 27/31 DBTT Column Status = 1 1 Beginning of duplicated header 2 Nexxt overflow page 20 21 Page index entry 29 Duplicated header 3 Preceding overflow 3 page No.
Table structure 232 Structure of records and tables U929-J-Z125-9-76
The previous chapters cover the functions and applications of the schema DDL, schema SSL and subschema DDL clauses. This chapter deals with the syntax rules you must observe in order to use the respective language correctly. The notational conventions are described on page 22. Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. Oktober 2007 Stand 11:29.
General syntax rules Reference section General syntax rules variable must be replaced by a current value when applying the format. Four categories of variables can be distinguished: Variable schema-name subschema-name realm-name set-name record-name record-element-name group-item-name vector-name item-name identifier hashroutine Current value must begin with a letter and may consist of up to 30 characters. The characters used may include letters, digits and hyphens.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Reserved words Page feed is indicated by / in column 7. Continuation line Entries exceeding column 72 can be continued in a new lines line that must start with a hyphen in column 7. Uppercase The COBOL compiler accepts uppercase letters only. Column conventions Each of the three languages is made up of clauses. Clauses are generally written starting at column 12.
Schema DDL Reference section 9.1 Schema DDL syntax Schema entry ⎧SCHEMA NAME clause ⎨ ⎩[PRIVACY LOCK clause]. Realm entry ⎧AREA NAME clause ⎨ ⎩[TEMPORARY clause]. ⎧RECORD NAME clause [LOCATION MODE clause] WITHIN clause Record entry ⎨ [SEARCH KEY clause]. record element name clause [PICTURE clause] [TYPE clause] ⎩[OCCURS clause]. ⎧SET NAME clause [DYNAMIC clause] ORDER clause Set entry ⎨ OWNER clause.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Schema DDL 9.1.1 Schema entry SCHEMA NAME IS schema-name [PRIVACY LOCK FOR COPY IS literal-1[ OR literal-2]]. literal-1,-2 may consist of up to 10 characters. The schema entry is used to assign a name to the schema. Passwords can be specified to prevent unauthorized creation of subschemas from the schema. 9.1.2 Realm entry AREA NAME IS realm-name [AREA IS TEMPORARY].
Schema DDL Reference section 9.1.3 Record entry RECORD NAME IS record-name ⎧ ⎧ ⎧IN⎫ ⎫⎫ ⎧DIRECT ⎫ item-name-1 ⎨ ⎬ record-name ⎨ ⎬ ⎨ ⎩OF⎭ ⎬ ⎩DIRECT-LONG⎭ [LOCATION MODE IS ⎨ ⎩identifier-1 ⎭⎬] CALC[ hash-routine] USING item-name-2,... ⎩ ⎭ DUPLICATES ARE[ NOT] ALLOWED WITHIN realm-name-1[,realm-name-2,... AREA-ID IS identifier-2] ⎧CALC[ hash-routine]⎫ [SEARCH KEY IS item-name-3,...USING ⎨ ⎬[ NAME IS name] ⎩INDEX ⎭ DUPLICATES ARE[ NOT] ALLOWED]....
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section i Schema DDL A maximum of 253 record types may be defined in a database with a page length of 2048 bytes, and a maximum of 32 766 record types may be defined in databases with a page length of 4000 or 8096 bytes. The individual clauses of the record entry are explained below. RECORD NAME IS record-name A name is assigned to a record type.
Schema DDL Reference section WITHIN realm-name-1[,realm-name-2,... AREA-ID IS identifier] realm-name-1,-2,... must not be temporary realms. The records of the record type are allocated to certain realms. ⎧CALC[ hash-routine]⎫ [SEARCH KEY IS item-name,... USING ⎨ ⎬[ NAME IS name] ⎩INDEX ⎭ DUPLICATES ARE[ NOT] ALLOWED].... item-name specifies an item of fixed length belonging to the record type. name specifies tables for SEARCH keys; referred to in the SSL statements.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Schema DDL ⎧mask-string ⎫ PICTURE IS ⎨ ⎬ ⎩LX(integer-1) DEPENDING ON item-name⎭ mask-string may consist of the following symbols: Symbol Syntax rule S can be specified once only at the beginning of the mask string. X at least one of these symbols must be entered. Each can be specified more than once or followed by a repetition symbol. 9 may not be placed to the left of A or X.
Schema DDL Reference section ⎧ TYPE IS ⎨ ⎧ ⎧15⎫ BINARY[ ⎨ ⎬] FIXED REAL ⎨ ⎩31⎭ ⎫⎫ ⎬ ⎩DECIMAL[ integer-1[,integer-2]] ⎭ ⎬ CHARACTER[ integer-3[ DEPENDING ON item-name]] DATABASE-KEY ⎩DATABASE-KEY-LONG ⎭ BINARY If no number is specified, the default value used by UDS/SQL is 15. integer-1 must be an integer between 1 and 18. Default value: 18 integer-2 must not be greater than 18 and not less than {integer-1} - 18. Default value: 0.
Schema DDL 9.1.4 Set entry SET NAME IS set-name [SET IS DYNAMIC] ⎧LAST 18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section ⎫ FIRST NEXT ORDER IS ⎨ PRIOR ⎬ IMMATERIAL SORTED[ INDEXED[ NAME IS name]] ⎧DATABASE-KEY ⎫ BY ⎨ ⎬ ⎩DEFINED KEYS DUPLICATES ARE[ NOT] ALLOWED⎭⎭ ⎩ ⎧record-name⎫ OWNER IS ⎨ ⎬. ⎩SYSTEM ⎭ ⎧MANDATORY⎫ ⎧AUTOMATIC⎫ [MEMBER IS record-name ⎨ ⎬ ⎨ ⎬ ⎩OPTIONAL ⎭ ⎩MANUAL ⎭ ⎧ASCENDING ⎫ [⎨ ⎬ KEY IS item-name-1,...
Schema DDL Reference section This clause is used to assign a name to a set and to – declare the set a dynamic set if required, – define the sequence of the member records within the set occurrences for sequential processing, – define additional access paths via primary and secondary keys, – declare a record type to be the owner record type of the set, – declare a record type to be a member record type of the set if required, and define the type of membership of member records in a set, and – sp
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Schema DDL ⎧LAST ⎫ FIRST NEXT ORDER IS ⎨ PRIOR ⎬ IMMATERIAL SORTED[ INDEXED[ NAME IS name]] ⎩ ⎧DATABASE-KEY ⎫ BY ⎨ ⎬ ⎩DEFINED KEYS DUPLICATES ARE[ NOT] ALLOWED⎭⎭ This clause is used to define – – the sequence of the records within the set occurrences for sequential processing. an additional direct access path via the primary key. ⎧record-name⎫ OWNER IS ⎨ ⎬.
Schema DDL Reference section ⎧ASCENDING ⎫ [⎨ ⎬ KEY IS item-name,...] ⎩DESCENDING⎭ item-name,... denotes an item of fixed length that belongs to the record type. This clause is used to define an item or a combination of items of the member record type as sort key. The member records within the set occurrence are sorted in ascending or descending order, according to the values of this key. ⎧CALC[ hash-routine]⎫ [SEARCH KEY IS item-name,... USING ⎨ ⎬[ NAME IS name] ⎩INDEX ⎭ DUPLICATES ARE[ NOT] ALLOWED]...
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Schema DDL [SET OCCURRENCE SELECTION IS ⎧CURRENT OF SET ⎫ ⎧item-name ⎫ THRU ⎨LOCATION MODE OF OWNER[ ALIAS FOR ⎨ ⎬⎬] ⎩identifier-1⎭ ⎩ IS identifier-2]...⎭ item-name must denote an item specified in the LOCATION MODE clause for the owner record type. identifier-1 must be an identifier specified in the LOCATION MODE clause for the owner record type.
SSL Reference section 9.2 SSL syntax Schema entry STORAGE clause. ⎧[RECORD NAME clause [DATABASE-KEY-TRANSLATION-TABLE clause] Record entry ⎨ [record POPULATION clause] [PLACEMENT-OPTIMIZATION clause] [INDEX clause] ⎩[COMPRESSION clause]]. ⎧[SET NAME clause [set POPULATION clause] Set entry ⎨[MODE clause] [INDEX clause] ⎩[PHYSICALLY LINKED clause]]. Figure 63: Structure of SSL The description of the physical storage structure is optional.
SSL 9.2.2 Record entry RECORD NAME IS record-name [DATABASE-KEY-TRANSLATION-TABLE[ IS integer-1][ WITHIN realm-name-1]] 18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section [POPULATION IS {integer-2 WITHIN realm-name-2},...] [PLACEMENT OPTIMIZATION FOR SET set-name] [INDEX NAME IS name [PLACING IS WITHIN realm-name-3] ⎧DATABASE-KEY-LIST [TYPE IS ⎨REPEATED-KEY ⎩ ⎫ MU]]... [DYNAMIC REORGANIZATION SPANS integer-3 PAGES]⎭ [COMPRESSION FOR ALL ITEMS].
SSL Reference section [DATABASE-KEY-TRANSLATION-TABLE[ IS integer][ WITHIN realm-name]] integer must be greater than 0. If this entry is omitted, UDS/SQL reserves one page each for the DBTT and the hash area of a record SEARCH key. realm-name must not denote a temporary realm. If this entry is omitted, the DBTT is placed in the realm first mentioned in the DDL WITHIN clause for this record type.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section SSL [PLACEMENT OPTIMIZATION FOR SET set-name] set-name must not denote a SYSTEM set. This clause is used to store the member records of the set set-name in the vicinity of their owner record. i The record type must be an AUTOMATIC member of the set set-name.
SSL Reference section [INDEX NAME IS name [PLACING IS WITHIN realm-name] ⎧DATABASE-KEY-LIST [TYPE IS ⎨REPEATED-KEY ⎩ name ⎫ ⎬]]... [DYNAMIC REORGANIZATION SPANS integer PAGES]⎭ must have been defined in the schema DDL for a record SEARCH key table or a hash area of this record type. realm-name must not be a temporary realm. If this entry is omitted, UDS/SQL places the record SEARCH key table or the hash area in the first realm referenced in the DDL WITHIN clause for this record type.
SSL [COMPRESSION FOR ALL ITEMS] This clause causes UDS/SQL to store the records in compressed form, provided they are made available in this form at the DML interface. i If the record type has been defined with LOCATION MODE IS CALC, indirect CALC pages are created due to the compression. Compression is not allowed if the record type contains an item of variable length or is a member of a set which has been defined with MODE IS LIST. Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
SSL Reference section 9.2.3 Set entry SET NAME IS set-name [POPULATION IS integer-1[ INCREASE IS integer-2]] ⎧CHAIN[ LINKED TO PRIOR] ⎫ ⎧POINTER-ARRAY⎫ ⎧ATTACHED TO OWNER ⎫ [MODE IS ⎨ ⎬] ⎨ ⎬ ⎨DETACHED[ WITHIN realm-name-1]⎬ ⎩⎩LIST ⎭ ⎩ [ WITH PHYSICAL LINK] ⎭⎭ [DYNAMIC REORGANIZATION SPANS integer-3 PAGES] [INDEX NAME IS name ⎧ATTACHED TO OWNER ⎫ [PLACING IS ⎨ ⎬] ⎩DETACHED[ WITHIN realm-name-2]⎭ ⎧DATABASE-KEY-LIST [TYPE IS ⎨REPEATED-KEY ⎩ ⎫ ⎬]]...
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section SSL SET NAME IS set-name This clause is used to specify the name of the set to which the set entry applies. [POPULATION IS integer-1[ INCREASE IS integer-2]] integer-1 must be greater or equal to 0. Default value: 0 integer-2 must be greater than 0.
SSL Reference section LIST may be specified only if the following conditions are satisfied: – The membership of the member record type in the set was defined as MANDATORY AUTOMATIC. – Member records (including pointers, see page 219, SCD) are no longer than – 993 bytes for databases with a page length of 2048 bytes, – 1963 bytes for databases with a page length of 4000 bytes, and – 4011 bytes for databases with a page length of 8096 bytes.
SSL [INDEX NAME IS name ⎧ATTACHED TO OWNER ⎫ [PLACING IS ⎨ ⎬] ⎩DETACHED[ WITHIN realm-name]⎭ ⎧DATABASE-KEY-LIST 18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section [TYPE IS ⎨REPEATED-KEY ⎩ name ⎫ ⎬]]... [DYNAMIC REORGANIZATION SPANS integer PAGES]⎭ must be the name of a table or of a hash area specified in the Schema DDL. ATTACHED may be specified only if the set is not a SYSTEM set. realm-name must not denote a temporary realm.
Subschema DDL Reference section 9.3 Subschema DDL syntax IDENTIFICATION DIVISION. SUB-SCHEMA NAME clause [PRIVACY LOCK clause] [PRIVACY KEY clause]. DATA DIVISION. AREA SECTION. COPY clause. RECORD SECTION. [COPY clause.] ⎧[record name clause. record element name clause [GROUP-USAGE clause] Record entry ⎨ [PICTURE clause] [USAGE clause] [OCCURS clause]. [condition name clause ⎩VALUE clause.]] [SET SECTION. COPY clause.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Subschema DDL 9.3.1 IDENTIFICATION DIVISION IDENTIFICATION DIVISION. SUB-SCHEMA NAME IS subschema-name OF SCHEMA NAME schema-name [PRIVACY LOCK FOR COMPILE IS literal-1[ OR literal-2]] [PRIVACY KEY FOR COPY IS literal-3]. literal-1,-2 may consist of up to 10 characters. literal-3 must be a password defined in the schema entry of the schema DDL.
Subschema DDL Reference section 9.3.3 RECORD SECTION RECORD SECTION. ⎧COPY ALL RECORDS. ⎫ [⎨ ⎬] ⎩{COPY record-name-1,...}....⎭ [01 record-name-2. {level-number record-element-name[ PICTURE IS mask-string] [ GROUP-USAGE IS NATIONAL] ⎧DISPLAY ⎫ COMPUTATIONAL-3 COMPUTATIONAL [ USAGE IS ⎨ NATIONAL ⎬] DATABASE-KEY ⎩DATABASE-KEY-LONG⎭ [ OCCURS integer TIMES].}... [88 condition-name ⎧VALUE IS ⎫ ⎨ ⎬ {literal-1[ THROUGH literal-2]},... .]...]...
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.k09 Reference section Subschema DDL USAGE If this entry is omitted, DISPLAY is assumed by default. Exception: if the PICTURE clause contains the symbol N, NATIONAL is assumed if the USAGE clause is missing. literal-1 must be less than literal-2. The user has the choice of either completely copying all record types contained in the schema into the subschema or only a selection of records or items.
Subschema DDL 262 Reference section U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix 18. Oktober 2007 Stand 11:29.52 Glossary This Glossary contains the definitions of some of the important terms and concepts used in the UDS/SQL manuals. Terms that appear in italics within a particular definition have also been defined in this Glossary. In cases where two or more terms are used synonymously, a “See” reference points to the more commonly used term in these manuals. A access, contending See contending access.
A Glossary act-key (actual key) Actual address of a page, consisting of realm number and page number. act-key-0 page First page of a realm; contains general information on the realm such as – when the realm was created, – when the realm was last updated, – internal version number of the realm, – system break information – if applicable, warm start information. act-key-N page Characteristic page of a realm, with the highest page number. Copy of the act-key-0 page. address, physical See act-key or PPP.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary A ALOG sequence number See sequence number. anchor record Record automatically created by UDS/SQL as owner record for SYSTEM sets. It cannot contain any items defined with the schema DDL and cannot be accessed. application Realization of a job in one or several user programs working with UDS/SQL databases. application program (AP) E.g. COBOL DML program or IQS. area See realm.
B Glossary B backup database See shadow database. base interface block (BIB) (Base Interface Block) Standard interface between UDS/SQL and each individual user; it contains, among other things, the RECORD AREA (user records as defined in the subschema). before-image Copy of a page taken before its contents are updated. The DBH writes before-images to the RLOG files during database operation before the updates are applied to the database. A prerequisite is that the RLOG files exist. BFIM See before-image.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary C CALC table Table in the direct/indirect CALC page whose entries point to the stored records. Each line contains: – the CALC key, – the record sequence number – the displacement to the related page index entry (direct CALC page) or the probable position pointer (indirect CALC page). CALL DML DML that is called by various programming languages (Assembler, COBOL, FORTRAN, PASCAL, PL/1) via the CALL interface.
C Glossary clone pair, clone pubset, clone session, clone unit A clone unit is the copy of an (original) unit (logical disk in BS2000/OSD) at a particular time (“Point-in-Time copy”). The TimeFinder/Clone component creates this copy optionally as a complete copy or as a “snapshot”. After they have been activated, the unit and clone unit are split; applications can access both. The unit and clone unit together form a clone pair. TimeFinder/Clone manages this pair in what is known as a clone session.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary C compiler database The realms and files of the database which are required by the UDS/SQL compiler. They are – DBDIR (Database Directory) – DBCOM (Database Compiler Realm) – COSSD (COBOL Subschema Directory). COMPILER-SCHEMA UDS/SQL-internal schema of the compiler database. COMPILER-SUBSCHEMA UDS/SQL-internal subschema of the compiler database. compound key Key consisting of several key items.
C Glossary consistency, logical State of the database in which the stored data has no internal conflicts and reflects the real-world situation. consistency, physical State of the database in which the stored data is consistent with regard to correct physical storage, access paths and description information. consistency, storage See physical consistency. consistency error A violation of the physical consistency of the stored data. consistency point Point (in time) at which the database is consistent, i.e.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary D CRR (Current Record of Record) Record which is marked in the currency table as the current record of a particular record type (Record). CRS 18. Oktober 2007 Stand 11:29.52 (Current Record of Set) Record which is marked in the currency table as the current record of a particular set. CRU (Current Record of Rununit) Record which is marked in the currency table as the current record of the processing chain.
D Glossary data protection (privacy) Protection against unauthorized access to data. Implemented in UDS/SQL by means of the schema/subschema concept and access authorization. Access rights are granted by means of the BPRIVACY utility routine. database (DB) Related data resources that are evaluated, processed and administered with the help of a database system. A database is identified by the database name. An UDS/SQL database consists of the user database and the compiler database.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary D database key item Item of type DATABASE-KEY or DATABASE-KEY-LONG that is used to accommodate database key values. Items of type DATABASE-KEY and DATABASE-KEY-LONG differ in terms of the item length (4 bytes / 8 bytes) and value range. DATABASE-KEY item See database key item. DATABASE-KEY-LONG item See database key item. database page See page.
D Glossary DBDIR See database directory. DBH Database Handler: program (or group of programs) which controls access to the database(s) of a session and assumes all the attendant administrative functions. DBH end End of the DBH program run. DBH end can be either a session end or a session abort. DBH, independent See independent DBH. DB key See database key. DBH, linked-in See linked-in DBH. DBH load parameters See load parameters (DBH). DBH start Start of the DBH program run.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary D DBTT extent see DBTT DBTT page Page containing the DBTT or part of the DBTT for a particular record type. DCAM Component of the TRANSDATA data communication program. DCAM application Communication application using the DCAM communication method. A DCAM application enables communication between – a DCAM application and terminals.
D Glossary distributed transaction Transaction that addresses at least one remote configuration. A transaction can be distributed over: – UDS-D, – openUTM-D, – UDS-D and openUTM-D. distribution pool Area in the independent DBH used for communication between UDSCT, server tasks, user tasks and the master task with regard to UDS-D-specific data. The distribution pool contains the distribution table and the UDS-D-specific system tables.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary E 18. Oktober 2007 Stand 11:29.52 duplicates table Special SEARCH-KEY table in which a key value which occurs more than once is stored only once. For each key value, the duplicates table contains: – a table index entry with the key value and a pointer to the associated table entry – a table entry (DB key list), which can extend over several pages, containing the record sequence numbers of the records which contain this key value.
G Glossary FPA base See free place administration. FPA extent See free place administration. FPA page Free place administration page. free place administration (FPA) Free space is managed both at realm level (FPA pages) and at page and table level. Free place administration of the pages is carried out in a base table (FPA base) and possibly in one or more extension tables (FPA extents) created by means of an online realm extension or BREORG.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary I HASHLIB Module library for the storage of hash routines for one database. I identifier Name allocated by the database designer to an item that UDS/SQL creates automatically. UDS/SQL adapts item type and length to the specified item usage. implicit set SYSTEM set created by UDS/SQL when a SEARCH key is defined at record type level.
K Glossary integrity State of the database in which the data contained in it is complete and free of errors. – entity integrity – referential integrity – user integrity interconfiguration Concerning at least one remote configuration. interconfiguration consistency A distributed transaction that has caused updates in at least one remote configuration is terminated in such a way that the updates are either executed on the databases in each participating DB configuration or on none at all.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary L key Item used by the database programmer for direct access to records; an optimized access path is provided for the key by UDS/SQL in accordance with the schema definition. 18. Oktober 2007 Stand 11:29.52 key, compound Key consisting of several key items. key item Item defined as a key in the schema. key reference number Keys are numbered consecutively in ascending order, beginning at 1.
M Glossary local configuration The configuration assigned to an application program before it is called using /SET-FILE-LINK LINK-NAME=DATABASE,FILE-NAME=conf-name. The application program communicates with the local configuration via the communication pool. The local configuration is in the same host as the application program. local database Database in a local configuration. local distribution table A distribution table is considered local to a DBH if it is held in the DBH’s distribution pool.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary M member See member record or member record type. member, AUTOMATIC Record is inserted at storage time. member, MANDATORY Record cannot be removed. member, MANUAL Record is not inserted automatically at storage time. member, OPTIONAL Record can be removed. member record Lower-ranking record in a set occurrence. member record type Lower-ranking record type in a set.
N Glossary multithreading A mechanism that enables the DBH to fully exploit the CPU. Multithreading means that the DBH processes several jobs concurrently by using so-called threads. Each thread has information on the current status of a particular job stored in it. When a job needs to wait for the completion of an I/O operation, DBH uses the CPU to process some other job. N network All computers linked via TRANSDATA.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary P openUTM (universal transaction monitor) Facilitates the creation and operation of transaction-oriented applications. 18. Oktober 2007 Stand 11:29.52 operator task (OT) See master task original database The term “original database” refers solely to the naming of the database files (dbname.dbfile), not to the status of the database content (see also shadow database).
P Glossary page container Pages with a length of 4000 or 8096 bytes are embedded in a so-called page container, which consists of a 64-byte header that precedes the page and a 32-byte trailer at the end of the page. page header (page info) The first 20 bytes of a database page (except for the FPA and DBTT pages with a length of 2048 bytes). They contain: – the act-key of the page itself, – the number of page index entries – the length and displacement of the bytes which are still vacant in this page.
P PETA Preliminary end of transaction: UDS-D or openUTM-D statement that causes a preliminary transaction end. The PETA statement belongs to the first phase of the two-phase commit protocol which terminates a distributed transaction. The PETA statement stores the following information failproof in the RLOG file of the local DBH: – each updated page – rollback and locking information – the names of all participating configurations. This information is required for any future warm start. 18.
P Glossary primary subtransaction Subtransaction that runs in the local configuration. The primary subtransaction is opened by the first READY statement in a transaction on a local database. If the first READY statement addresses a remote database, UDS-D generates a dummy subtransaction as the primary subtransaction. PRIVACY-AND-IQF SCHEMA UDS/SQL-internal schema for protection against unauthorized access. PRIVACY-AND-IQF SUBSCHEMA UDS/SQL-internal subschema for protection against unauthorized access.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary R R READY Start of a transaction or a processing chain in COBOL DML programs. READYC Start of a transaction or a processing chain in CALL DML programs. realm Nameable physical subunit of the database. Equivalent to a file. Apart from the user realms for user data there are also the realms DBDIR and DBCOM, which are required by UDS/SQL.
R Glossary RECORD AREA Area in the USER WORK AREA (UWA) which can be referenced by the user. The record area contains the record types and the implicitly defined items (IMPLICITLY-DEFINED-DATA-NAMES) of the database such as the AREA-ID items of the WITHIN clauses of the schema. The length of the record area is essentially defined by the record types contained in it. record element Item, vector or group item.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary R remote configuration DB-configurations that are not assigned to the application program via /SET-FILELINK LINK-NAME=DATABASE,FILE-NAME=conf-name but via the distribution table once the application program is running. The connection module of the application program communicates with the remote configurations via DCAM applications. Remote configurations can be situated on local or remote hosts.
S Glossary rollback Canceling of all updates effected within a transaction. RSQ See record sequence number. RUNUNIT-ID See transaction identification. S schema Formalized description of all data structures permitted in the database. A UDS/SQL schema is defined by means of the Schema DDL. Schema DDL Formalized language for defining a schema. Schema Information Area (SIA) The SIA contains the complete database definition. The DBH loads the SIA into main memory at the start of DB processing.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary S sequential access Accessing a record on the basis of its position within a predefined record sequence. server task Task of the independent DBH in which the UDSSUB module executes; processes the requests of the DB application programs. session Period between starting and normal termination of the DBH (independent/ linkedin) in which it is possible to work with the databases of the configuration.
S Glossary session restart Starting of the DBH, under the same configuration name and configuration user ID, after a session abort. With the aid of the SLF, the DBH load parameters and the current file identifiers which existed when the session aborted are re-established, and the databases of the previous configuration are reconnected, if necessary by means of a warm start.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary S set SEARCH KEY table SEARCH KEY table for selecting a member record from a set occurrence. SF pubset See single feature pubset shadow database Backup of all the files of a database, each saved under the name ”dbname.dbfile.copyname”. A shadow database can be created at any time and processed parallel to the original database in RETRIEVAL mode.
S Glossary snap pair, snap pubset, snap session, snap unit A snap unit is the copy of an (original) unit (logical disk in BS2000/OSD) at a particular time (“Point-in-Time copy”). The TimeFinder/Snap component creates this copy as a “snapshot” in accordance with the “Copy-On-First-Write strategy“: Only if data is modified is the original data concerned written beforehand into a central save pool of the Symmetrix system. The snap unit contains the references (track pointers) to the original data.
18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary S SQL Interface Block (SIB) Interface between UDS/SQL and SQL application program(s); contains the SQL statement, any existing parameters and the statement results. SQL transaction Related sequence of SQL statements which is processed by UDS/SQL either as a whole or not at all. This method ensures that the database(s) is/are always in a consistent state. SSIA See Subschema Information Area.
S Glossary subschema Section of a schema required for a particular application; it can be restructured, within limits, for the intended application; a subschema is defined by means of the Subschema DDL. Subschema DDL Formalized language for defining a subschema. Subschema Information Area (SSIA) The SSIA contains all subschema information required by the DBH to carry out, on behalf of the user, the database accesses permitted within the specified subschema.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary T 18. Oktober 2007 Stand 11:29.52 system buffer pools Input/output buffer for database pages (see page). The buffer is part of the common pool (independent DBH) or the DBH work area (linked-in DBH). Its size is determined by the DBH load parameters 2KB-BUFFER-SIZE, 4KB-BUFFERSIZE or 8KB-BUFFER-SIZE.
T Glossary TANGRAM (Task and Group Affinity Management) Subsystem of BS2000/OSD that plans the allocation of processors for task groups which access large quantities of shared data in multi-task applications. task attribute TP There are 4 task attributes in BS2000/OSD: SYS, TP, DIALOG and BATCH. Special runtime parameters that are significant for task scheduling are assigned to each of these task attributes.
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary U transaction, rolling back a Terminating a transaction with FINISH WITH CANCEL, i.e. all updates performed on the database within the transaction are rolled back. 18. Oktober 2007 Stand 11:29.52 Transaction Currency Area (TCUA) Contains currency information. transaction identification (TA-ID) Assigned by the DBH to identify a particular transaction. Can be requested with the DAL command DISPLAY.
U Glossary UDS-D task UDSCT Task started for each configuration by UDS/SQL so that it can participate in distributed processing with UDS-D. UDS/SQL / openUTM-D consistency A transaction that has updated both openUTM data and UDS/SQL databases is terminated in such a way that the openUTM data and the UDS/SQL databases are either updated together or not at all. UDS/SQL pubset declaration Declaration in a pubset declaration job variable for restricting the UDS/SQL pubset environment.
V V vector Item with repetition factor. The repetition factor must be greater than 1. It specifies how many duplicates of the item are combined in the vector. 18. Oktober 2007 Stand 11:29.52 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.mix Glossary version number, internal See internal version number. W warm start Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
W 304 Glossary U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.abk 18. Oktober 2007 Stand 11:29.52 © cognitas GmbH 2001-2007 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Abbreviations 306 FC Function Code FPA Free Place Administration GS Global Store HSMS Hierarchic Storage Management System ID Identification IQL Interactive Query Language IQS Interactive Query System KDBS Kompatible Datenbank-Schnittstelle (= compatible database interface) KDCS Kompatible Datenkommunikationsschnittstelle (= compatible data communications interface) LM Lock Manager LMS Library Maintenance System MPVS Multiple Public Volume Set MR-NR Mainref Number MT Master task
SLF Session Log File SQL Structured Query Language SSD Solid State Disk SSIA SubSchema Information Area SSITAB SubSchema Information TABle SSL Storage Structure Language ST Server Task STT Sekundäre Teiltransaktion (= secondary subtransaction) TA TransAction TA-ID TransAction IDentification TANGRAM TAsk aNd GRoup Affinity Management TCUA Transaction CUrrency Area UDS/SQL Universal Database System/Structured Query Language UWA User Work Area Dokuschablonen 19x24 Version 7.
Abbreviations 308 U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.lit 24. Oktober 2007 Stand 09:07.33 Related publications The manuals are available as online manuals, see http://manuals.fujitsu-siemens.com, or in printed form which must be paid for and ordered separately at http://FSC-manualshop.com. UDS/SQL (BS2000/OSD) Application Programming User Guide UDS/SQL (BS2000/OSD) Creation and Restructuring User Guide UDS/SQL (BS2000/OSD) Database Operation User Guide Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.
Related publications UDS-KDBS (BS2000/OSD) Compatible Database Interface User Guide SQL for UDS/SQL Language Reference Manual BS2000/OSD-BC Commands, Volumes 1 - 5 User Guide BS2000/OSD-BC Commands, Volume 6, Output in S Variables and SDF-P-BASYS User Guide BS2000/OSD-BC System Messages, Volumes 1 - 3 User Guide BS2000/OSD-BC Introductory Guide to Systems Support User Guide BS2000/OSD-BC Executive Macros User Guide BS2000/OSD-BC Introductory Guide to DMS User Guide SDF (BS2000/OSD) Introductory Guide to th
24. Oktober 2007 Stand 09:07.33 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.lit Related publications LMS (BS2000) SDF Format User Guide DSSM/SSCM Subsystem Management in BS2000/OSD User Guide ARCHIVE (BS2000/OSD) User Guide DRV (BS2000/OSD) Dual Recording by Volume User Guide HSMS / HSMS-SV (BS2000/OSD) Hierarchical Storage Management System Volume 1: Functions, Management and Installation User Guide SECOS (BS2000/OSD) Security Control System User Guide Dokuschablonen 19x24 Version 7.
Related publications OMNIS/OMNIS-MENU (TRANSDATA, BS2000) Administration and Programming User Guide openUTM Concepts and Functions User Guide openUTM (BS2000/OSD, UNIX, Windows) Programming Applications with KDCS for COBOL, C and C++ User Guide openUTM (BS2000/OSD, UNIX, Windows) Generating Applications User Guide openUTM (BS2000/OSD, UNIX, Windows) Administering Applications User Guide openUTM (BS2000/OSD) Messages, Debugging and Diagnostics User Guide COBOL2000 (BS2000/OSD) COBOL Compiler Reference Manua
24. Oktober 2007 Stand 09:07.33 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Related publications 314 U929-J-Z125-9-76
Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.six 18. October 2007 Stand 11:29.53 © cognitas GmbH 2001-2007 Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.
Index CALC SEARCH key 266 CALC table 210, 267 CALC table header 210 calculation formulas, storage space requirement 177 CALL DML 47, 267 catalog identifier 267 CC 39 CHAIN 130, 136, 144, 156, 223 chain 130, 144, 151, 155, 267 Character Separated Values (CSV) 267 check records 267 checkpoint 267 CHECK-TABLE 267 clone 268 COBOL DML 30, 47, 268 COBOL runtime system 268 COBOL Subschema Directory (COSSD) 268 CODASYL 53 CODASYL model 28, 35, 36 Codd 31 coexistence 36 column 32 column conventions 235 comment 234
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. October 2007 Stand 11:29.53 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Index domain 32 DRIVE 40 DRV 42 dummy subtransaction 276 duplicate table 157 DUPLICATES clause 87 duplicates header 276 duplicates table 229, 277 main level 277 DYNAMIC clause 106, 244 dynamic set 106, 277 E ESTIMATE-REPORT 277 event name 277 exclusive buffer pool 277 F FASTPAM access method 42 flexibility 35 foreign key 32, 33, 36, 50, 277 FPA 277 FPA base 202, 278 FPA extent 202, 278 FPA page 197, 202, 278 free place administration 197, 202, 212, 215, 225, 278 function analysis 43 function code 278 G gro
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. October 2007 Stand 11:29.53 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Index owner 29, 36, 285 OWNER clause 105, 245 owner record 70, 103, 110, 140, 147, 150, 159, 161, 163, 165, 251, 285 owner record type 70, 244, 285 P P1 eventing 288 page 131, 197, 198, 285 overflow 138 structure 200 page address 131, 285 page container 197, 199, 286 page feed 235 page format 61, 68, 108, 149, 240 page header page header (page info) 286 page index entry 210, 215, 286 page length 61, 68, 108, 133, 149, 197, 202, 207, 210, 213, 215, 225, 230, 239, 240 page number 131, 286 relative 87, 92, 10
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. October 2007 Stand 11:29.53 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Index SEARCH key table 93, 102, 130, 136, 140, 154, 157, 172, 177, 225, 254, 257 form 157 naming 240, 246 placement 160, 167, 172 storage space requirement 177 secondary key 92, 100, 102, 107, 136, 139, 142, 161, 168, 172, 238, 240, 244, 246, 292 secondary subtransaction 292 security 42 security concept 42 selection method for set occurrences 103 selection option for set occurrences 244, 247 semicolon 234 sequence number 292 sequence of records 71 sequential access 293 server task 293 session 293 abort 293
Dokuschablonen 19x24 Version 7.3us für FrameMaker V7.x vom 14.02.2007 © cognitas GmbH 2001-2007 18. October 2007 Stand 11:29.53 Pfad: G:\vogt\fsc\uds\Manuale\en\udsent_e\udsent.
Index value range 32 of condition 192 of item 55 variable 22 vector 53, 65, 183, 189, 242, 303 version number internal 303 324 view 32 relational 51 W warm start 303 WITHIN clause 109, 161, 168, 240 U929-J-Z125-9-76
