Building Access Path

Building Access Paths

Release 6.2

Published bySterling Software, Inc.

TrademarksCOOL:2E is a trademark of Sterling Software, Inc.

IBM, DB2/400, Operating System/2, OS/2 are trademarks ofInternational Business Machines Corporation

Microsoft, MS, MS-DOS, Windows, Windows for Workgroups, SNA Server,and Windows NT are trademarks of Microsoft Corporation

Copyright © 1999, Sterling Software, Inc.

All rights reserved.

Licensees of Sterling Software, Inc. are permitted to distribute and duplicatethis work for their internal use only. No other distribution or duplication of this work

in whole or in part, is permitted without the express written consentof Sterling Software, Inc.

Country of Origin: U.S.A.

Contents

About This Module

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Related Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Acronyms and Terms Used in this Module . . . . . . . . . . . . . . . . ivAcronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

1. Access Paths: An Introduction

Understanding Access Paths . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Recognizing the Basic Properties of Access Paths. . . . . . . . . 1-2Identifying Access Path Types . . . . . . . . . . . . . . . . . . . . . 1-2

Physical (PHY) Access Path . . . . . . . . . . . . . . . . . . . 1-2Update (UPD) Access Path . . . . . . . . . . . . . . . . . . . . 1-3Retrieval (RTV) Access Path . . . . . . . . . . . . . . . . . . . 1-3Resequence (RSQ) Access Path . . . . . . . . . . . . . . . . 1-4Query (QRY) Access Path . . . . . . . . . . . . . . . . . . . . . 1-5Span (SPN) Access Path . . . . . . . . . . . . . . . . . . . . . . 1-6

Characteristics of Access Paths . . . . . . . . . . . . . . . . . . . . 1-7Naming Access Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Recognizing Access Path Components . . . . . . . . . . . . . . . . . 1-8Access Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Access Path Format Entries . . . . . . . . . . . . . . . . . . . . . . . 1-8Access Path Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Access Path Auxiliaries . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Narrative Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Understanding Generator Types . . . . . . . . . . . . . . . . . . . . . . 1-10

2. Setting Default Options for Your Access Paths

Model Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Changing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Building Access Paths 1

Contents

Allocating Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Controlling Auxiliary Names . . . . . . . . . . . . . . . . . . . . . . 2-4Creating an SQL Environment. . . . . . . . . . . . . . . . . . . . . 2-5Specifying Generation Mode . . . . . . . . . . . . . . . . . . . . . . 2-5Changing the Generation Mode at the Access Path Level 2-6

Changing Compiler Overrides . . . . . . . . . . . . . . . . . . . . . . . . 2-7

3. Adding Access Paths

Before Adding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Edit File Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Adding an Access Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Adding a Physical (PHY) Access Path . . . . . . . . . . . . . . 3-4Adding a Resequence (RSQ) Access Path . . . . . . . . . . . 3-5Adding a Query (QRY) Access Path . . . . . . . . . . . . . . . . 3-5Adding a Span (SPN) Access Path . . . . . . . . . . . . . . . . . 3-6

4. Modifying Access Paths

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Before Modifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Navigational Techniques and Aids . . . . . . . . . . . . . . . . . 4-2Automatic Add Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Trimming an Access Path . . . . . . . . . . . . . . . . . . . . . . . . 4-4Virtualizing an Access Path . . . . . . . . . . . . . . . . . . . . . . . 4-4Locking an Access Path . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

Temporary Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Permanent Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

Displaying Usages for Access Paths. . . . . . . . . . . . . . . . 4-5

Building Distributed Relational Database Applications . . . . . 4-6Specifying Distributed Files . . . . . . . . . . . . . . . . . . . . . . . 4-6

Modifying Access Path Details. . . . . . . . . . . . . . . . . . . . . . . . 4-7Editing Access Path Details. . . . . . . . . . . . . . . . . . . . . . . 4-9

Specifying Unique/Duplicate Key Retrieval Sequence 4-9Specifying Access Path Maintenance . . . . . . . . . . . 4-10Specifying Alternate Collating Sequence . . . . . . . . 4-11Specifying Select/Omit Criteria . . . . . . . . . . . . . . . . 4-12Specifying Generation Mode. . . . . . . . . . . . . . . . . . 4-13Implications of Using SQL and DDS . . . . . . . . . . . . 4-13Changing Source Member Text and Names. . . . . . 4-15

2 Building Access Paths

Contents

Modifying Access Path Format Entries . . . . . . . . . . . . . . . . . 4-16Identifying Access Path Format Text . . . . . . . . . . . . . . . 4-16Identifying Access Path Format Keys . . . . . . . . . . . . . . . 4-16Editing Access Path Format Entries . . . . . . . . . . . . . . . . 4-17Editing Physical File Format Entries . . . . . . . . . . . . . . . . 4-18

Modifying Access Path Relations . . . . . . . . . . . . . . . . . . . . . 4-20Understanding Required Relations . . . . . . . . . . . . . . . . . 4-20Adding Relations to a File . . . . . . . . . . . . . . . . . . . . . . . . 4-21Editing Access Path Relations . . . . . . . . . . . . . . . . . . . . 4-21

Modifying Virtual Field Entries . . . . . . . . . . . . . . . . . . . . . . . . 4-23Understanding Access Path Virtual Field Entries . . . . . . 4-23Identifying Relations with Virtual Fields. . . . . . . . . . . . . . 4-24Specifying File and Access Path Relations. . . . . . . . . . . 4-24Editing Virtual Field Entries . . . . . . . . . . . . . . . . . . . . . . . 4-25Tailoring Virtual Fields for Access Paths. . . . . . . . . . . . . 4-27

Choosing Select/Omit Criteria . . . . . . . . . . . . . . . . . . . . . . . . 4-27Understanding Select/Omit . . . . . . . . . . . . . . . . . . . . . . . 4-27Specifying Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Specifying Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

Changing a Referenced Access Path . . . . . . . . . . . . . . . . . . 4-30F4 Prompt Function Assignment. . . . . . . . . . . . . . . . . . . 4-32

Modifying Access Path Auxiliaries. . . . . . . . . . . . . . . . . . . . . 4-33Understanding Access Path Auxiliaries . . . . . . . . . . . . . 4-33Editing Access Path Auxiliaries. . . . . . . . . . . . . . . . . . . . 4-34

5. Deleting Access Paths

Deleting an Access Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Determining the Usage of an Access Path . . . . . . . . . . . . . . . 5-3

6. Defining Arrays

Understanding Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Structuring Field Data Using Arrays . . . . . . . . . . . . . . . . . . . . 6-2

Passing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Storing Data Between Calls . . . . . . . . . . . . . . . . . . . . . . . 6-3

Defining an Array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Editing an Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Building Access Paths 3

Contents

Viewing Function References . . . . . . . . . . . . . . . . . . . . . 6-6Changing the Name of an Array . . . . . . . . . . . . . . . . . . . 6-6

Deleting an Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7

7. Generating and Comspiling

Implementing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1OS/400 Index Versus COOL:2E Index . . . . . . . . . . . . . . 7-1Setting Your Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Identifying the Implementation Attributes . . . . . . . . . . . . 7-2Generating an Access Path. . . . . . . . . . . . . . . . . . . . . . . 7-3

8. Documenting Access Paths

Documenting an Access Path . . . . . . . . . . . . . . . . . . . . . . . . 8-1Creating the Documentation . . . . . . . . . . . . . . . . . . . . . . 8-1

9. Tailoring for Performance

Considering the Types of Data in the Physical File . . . . . . . . 9-2

Minimizing the Number of Active Indices . . . . . . . . . . . . . . . . 9-2The Active Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3Sharing Active Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Access Path Maintenance (Immediate, Delay, or Rebuild) . . 9-4Maintenance for Query (QRY) Access Paths . . . . . . . . . 9-6

Using Select/Omit Maintenance. . . . . . . . . . . . . . . . . . . . . . . 9-7

Using Join Logicals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Using Multi-Format Access Paths . . . . . . . . . . . . . . . . . . . . 9-10

Using Open Data Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

Creating Default Retrieval Access Paths . . . . . . . . . . . . . . . 9-11

4 Building Access Paths

nd

ys

,

,

hed,

s toes

About This Module

This preface introduces theBuilding Access Pathsmodule. It provides youwith information on how the module is structured, identifies the contents, aexplains the established conventions.Building Access Pathsis part of a set ofmodules that provide instructions on how to use the COOL:2E product.

PurposeThis module describes how to build access paths and arrain COOL:2E. It explains how to set up your COOL:2Esystem and model values and how to add, modify, deleteand document access paths and arrays. Each chapter isdesigned to provide the complete information needed toperform the tasks identified in the chapter. Review theentire module or refer to the chapter that relates to thespecific task you want to perform.

OrganizationThis module contains a preface, an introductory chapterand eight task-oriented chapters.

The introduction provides a high level overview of theCOOL:2E concepts for building access paths. Seven of tremaining eight chapters contain conceptual material aninstructions on the specific tasks required to add, modifydelete, and generate access paths. One chapter dealsspecifically with building arrays.

Where necessary, these chapters also contain referenceother topics and chapters in this module and other modulor reference manuals with related information.

Building Access Paths i

Contents

E

d

ContentsThe chapters in this module are as follows:

1. Access Paths: An IntroductionThis chapter contains an introduction to the types ofaccess paths and a high level overview of the COOL:2concepts for building access paths.

2. Setting Default Options For Your Access PathsThis chapter contains conceptual material andinstructions on setting COOL:2E model values forallocating prefixes, file names and SQL libraries. It alsoincludes details on generating database file values andinstructions on changing compiler overrides.

3. Adding Access PathsThis chapter contains conceptual material andinstructions for editing file details and adding thefollowing six access paths: physical, update, retrieval,resequence, query, and span.

4. Modifying Access PathsThis chapter contains conceptual material andinstructions on how to modify existing access paths,including the details, format entries, relations, andauxiliaries. It also contains information on modifyingvirtual field entries and select/omit criteria.

5. Deleting Access PathsThis chapter contains conceptual material andinstructions on how to delete existing access paths.

6. Defining ArraysThis chapter contains conceptual material andinstructions on how to add, edit, and delete an array.

7. Generating and CompilingThis chapter contains conceptual material andinstructions on how to set up your generation options anhow to generate and compile your access paths.

ii Building Access Paths

Related Information

ted

ce.

w

in

se.

8. Documenting Access PathsThis chapter contains conceptual material andinstructions on how to document the access paths creain COOL:2E.

9. Tailoring For PerformanceThis chapter contains material that can help you tailoryour access paths to obtain the best system performan

Related InformationBefore you build your access paths you should read or reviethe material in the following modules:

Overview

Getting Started

Defining a Data Model

The following modules contain additional informationrelating to the generation of access paths and associatedfunctions.

Building Applications

Generating and Implementing Applications

COOL:Xtras Performance Expert User Guide

You may want to refer to the following IBM documentationin the context of using this module.

IBM AS/400 DDS Reference Manual

AS/400 Database Guide

ConventionsThis module uses the following conventions:

● Commands, data entry text, and function keys appearboldface type. Data entry text appears in caps foremphasis; however, you can enter the data in lower ca

Building Access Paths iii

Acronyms and Terms Used in this Module

to00

r

s,

:

lem

● All terms (commands, access paths, files, fields) referCOOL:2E unless otherwise indicated, such as the OS/4Save Library (SAVLIB ) command or theCOOL:Xtras 400 Toolkit Build Library List(YBLDLIBLST ) command.

● The first reference to features with abbreviated namesincludes both the spelled out and abbreviated name; foexample, the Edit File (EDTFIL) function or NationalLanguage Support (NLS). Subsequently, only theabbreviated name identifies the feature. For commandthis name appears in boldface type.

● Two icons appear in the left margin, where appropriatean open book, which indicates references to relatedinformation in COOL:2E modules and IBM manuals; anda pen in hand, which indicates a special note.

Acronyms and Terms Used in this ModuleDescriptions of the acronyms and values used in this moduare defined once, in this chapter. Thereafter, only the acronyor value is used.

AcronymsThe following acronyms appear in this module:

ANSI American National Standards Institute

CBL COBOL

CL Control Language

DDL Data Definition Language

DDS Data Description Specifications

DML Data Manipulation Language

DRDA Distributed Relational Database Architecture

ESF External Source Format

FCFO First Changed, First Out

FIFO First In, First Out

HLL High level language

IBM International Business Machines Corporation

I/O Input/Output

iv Building Access Paths


ValuesThe following values appear in this module:

LIFO Last In, First Out

ODP Open Data Path

RPG Report Program Generator

SAA Systems Application Architecture

SQL Structured Query Language

CPT Capture file

PHY Physical access path

QRY Query access path

REF Reference file

RSQ Resequence access path

RTV Retrieval access path

SPN Span access path

UPD Update access path

Building Access Paths v


vi Building Access Paths

s tourE

r

tionromor

l

Access Paths: An Introduction 1This chapter provides an overview to building access paths. Its purpose ihelp you understand the COOL:2E concepts for using access paths in yodesign model. In this module, the term access path refers to the COOL:2definition exclusively unless identified as an OS/400 access path.

Understanding Access PathsA COOL:2E access path can be implemented as one ormore OS/400 objects. Access paths can be created ovefiles that have been defined, but before the functionsassociated with the access path are created. The applicauses access paths to retrieve, sequence, or update data fthe physical file. COOL:2E creates default access paths fyou when you define a file in your model. However, youcan create additional access paths for your file.

An access path defines the physical file and/or the logicaviews of that file. When you build one, you specify thefollowing:

● the order in which you want to retrieve records from afile

● which fields will be present

● your select/omit criteria for deciding which recordsfrom the file will be retrieved by the access path

Building Access Paths 1–1

Recognizing the Basic Properties of Access Paths

ss

s.

s

a

d

Recognizing the Basic Properties of Access PathsThere are six different types of access paths, each with adifferent purpose. These types are defined in this topic. Accepaths are allowed for both Reference (REF) and Capture(CPT) files. In addition, each access path must have a validCOOL:2E name.

� For more information:on REF and CPT files, refer to Defining a Data Model,Chapter 3, “Understanding Your Data Model,” UsingFiles topic.

Identifying Access Path TypesThe following is a description of the six types of access path

Physical (PHY) Access PathA PHY access path is a single-format file containing the fieldderived from the resolution of all the relations on a file. Thisaccess path type

● is unkeyed.

● has no virtual fields.

● is created automatically by COOL:2E for every definedREF or CPT file.

● is not referenced directly by functions.

● allows no additional PHY access path to be created forgiven COOL:2E file.

● is created in a model if an existing physical file isretrieved into the model through assimilation.

� For more information:on assimilation, refer toDefining a Data Model, Chapter7, “Assimilation.”

on editing physical file format entries for assimilatedfiles, refer to Chapter 4, “Modifying Access Paths.”

ExamplesEvery COOL:2E file has one access path of type PHY, callePhysical file by default. For example:

● Physical file for the Company file

1–2 Building Access Paths


atng

e

e

s

th

in

ata

● Physical file for the Product file

● Physical file for the Order file

● Physical file for the Order detail file

Update (UPD) Access PathAn UPD access path specifies a uniquely keyed, single-formaccess path that describes a view to the function for updatithe file. This access path type

● is always keyed on the fields that identify the file. Thesentries arise from the resolution of the key relations.

● has no virtual fields.

● is created automatically by COOL:2E for every definedREF or CPT file.

You can create additional UPD access paths, with the samkeys as specified on the file, but which have a subset of thefields defined by the relations. Additional UPD access pathare seldom required.

ExamplesEvery COOL:2E file has a default COOL:2E UPD access pathat will be called Update index by default. For example:

● Update index for the Company file

● Update index for the Product file

● Update index for the Order file

● Update index for the Order detail file

You can create other COOL:2E UPD access paths for usefunctions that update only some fields from a file, forexample:

● Company address update only

● Batch status only

Retrieval (RTV) Access PathA RTV access path specifies a uniquely keyed, single- formaccess path that functions can use to retrieve records fromfile. This access path type

● is always keyed in exactly the same way as the UPDaccess path using the relations of the based-on file.



ch

e

d

to

e

ue.

● allows virtual fields on the access path.

● is automatically created by COOL:2E for every definedREF or CPT file.

● defaults to the virtual fields of the based-on file'srelations. These are then present on the access path'srelations.

● is associated with an UPD access path; COOL:2Eautomatically makes this association.

● can be edited or trimmed to drop some or all non-keyfields from the record layout.

● can define select/omit logic to select or omit records fromthe access path.

● can be set not to pick up virtual fields.

You can create many RTV access paths for a given file. Eacan contain a different combination of fields and/or virtualfields and a different set of selection criteria, but all have thsame key fields.

ExamplesEvery COOL:2E file has a default RTV access path, createfor it automatically by COOL:2E, called Retrieval index bydefault. For example:

● Retrieval index for the Company file

You can define other COOL:2E RTV access paths for thesame COOL:2E file. For example:

● Company active index (selecting active records only)

● Company summary index (with a subset of the filerelations)

Resequence (RSQ) Access PathA RSQ access path specifies a uniquely or non-uniquelykeyed, single-format access path you can use to describeCOOL:2E functions how records are to be retrieved from afile. This access path type

● must be created explicitly.

● defaults to those keys defined by the key relations for thbased-on file, but allows them to be overridden to analternative key sequence that does not need to be uniq



ch

sto

ey

to

● allows virtual fields to be specified on the access path.

● is associated with a RTV access path that points to anassociated UPD access path.


You can create many RSQ access paths for a given file. Eacan contain a different combination of data fields and/orvirtual fields, a different set of selection criteria, or analternative key order.

Examples● CompanyKnown by Company code; RSQ by Company

name

● OrderKnown by Order no.; RSQ by Order date

● PersonKnown by Person code; RSQ by Height

Query (QRY) Access PathA QRY access path specifies a keyed, single-format accespath you can use to describe to functions how records arebe retrieved from a file. This access path type

● allows virtual fields to be specified as key and non-keyfields on the access path.

● can use virtual fields as key fields.

● is available for use with the following function types:Display File, Select Record, Retrieve Object, PrintObject, and Print File.

● defaults to those keys defined by the key relations for thfile, but allows them to be overridden to an alternative kesequence.


● is associated with a RTV access path that in turn pointsan associated UPD access path.




chle

r.ds

.

th.nds

red

s

tes

s.

You can create many QRY access paths for a given file. Eacan contain a different combination of data fields and virtuafields, a different set of selection criteria, and/or an alternativkey sequence.

Examples● CustomerKnown by Customer code; OrderRefers to

Customer and Customer name is a virtual field on OrdeUsing a QRY access path, you can retrieve Order recorin Customer name order.

● ProductKnown by Product code; Order lineRefers toProduct and Product name is a virtual field on Order lineUsing a QRY access path, you can retrieve Order linerecords in Product name order.

● CompanyKnown by Company code; EmployeeOwnedby Company and Company name is a virtual field onEmployee. Using a QRY access path, you can retrieveEmployee records in Company name order.

Span (SPN) Access PathA SPN access path specifies a keyed multi-format access paIt can be used to describe to the edit and display transactiofunctions how records are to be retrieved from a pair of relatefiles. These files possess a common foreign key. These filemust be related by anOwned by or Refers to relation. TheSPN access path must be created over the owning or referto file. This access path type

● initially defaults to those keys defined by the key relationof the based-on files but can be overridden to analternative key sequence.

● allows virtual fields to be specified on the access pathrelations.


● is associated with a RTV access path that points to anassociated UPD access path used to carry out any updato the based-on file.

● allows explicit selection of multiple access path format




chet

not

f

ss

berateeanof

Examples● Order and Order details (Order detailOwned by Order)

● Race and Entries (EntryOwned by Race)

● Orders for Customer (OrderRefers to Customer)

You can create many SPN access paths for a given file. Eacan contain a different combination of formats, a different sof selection criteria, and/or an alternative key sequence.

The RTV access path is used automatically by COOL:2E totell functions to retrieve any virtual fields specified for theSPN access path. This is necessary because OS/400 doessupport join logical multi-format files.

Each trio of associated SPN, RTV, and UPD access pathsshould contain the same access path relations. Otherwise,COOL:2E transaction functions (EDTTRN and DSPTRN)based on the SPN access path will not operate correctly.EDTTRN and DSPTRN functions use the first two formats oa multi-format span access path.

Characteristics of Access PathsThe following table shows characteristics of COOL:2E accepaths.

Naming Access PathsA name for an access path can be free format and up to 25characters. Within a given file, the access path names mustunique. Since each access path is implemented as a sepaOS/400 object, each access path also will be given a uniqusource member name (in the model) before source code cbe generated for it. The member name becomes the namethe object used to implement the access path.

Access path type Realfields

Keyfields

Virtualfields

Virtualkeys

PHY Physical Yes No No No

UPD UpdateRTV RetrievalRSQ ResequenceQRY QuerySPN Span

YesYesYesYesYes

RelationRelationUserUserUser

NoYesYesYesYes

NoNoNoYesNo


Recognizing Access Path Components

er

s

ath

ontse

ns

y-

COOL:2E supplies a default name if the Allocate Name(YALCVNM) model value is set to *YES or *MNC.

� For more information:on changing a default name, refer to this module Chapt2, “Setting Up Default Options for Your Access Paths.”

on naming implementation objects, refer toGettingStarted, Chapter 4, “Using Your DevelopmentEnvironment,” Setting Up the User Environment topic,Naming Control subtopic.

on theYCHGMDLVAL command, refer to COOL:2ECommand Reference.

Recognizing Access Path Components

Access Path DetailsAccess Path Details are the various implementation optionspecified for access paths. These options include changingsource names and text, allowing selection criteria, andspecifying generation mode, unique key sequence, access pmaintenance, and alternate collating sequence.

Access Path Format EntriesAccess Path Format Entries show which fields are presentthe access path, which of those fields are key fields for thaaccess path, and the order of those keys. SPN access pathhave at least two formats. Other access path types can havonly one format.

Access Path RelationsAccess Path Relations are the set or subset of a file's relatiothat apply to a particular access path. The compulsoryrelations for an access path are the key level relations. Themust be present on all access paths for the file. Each file-tofile relation on the access path can be associated with adifferent set of virtual fields.


Narrative Text

al.

s

ic

d

s

Access Path AuxiliariesAccess Path Auxiliaries refer to:

● the three different OS/400 objects used to implement aquery access path for DDS objects. They include a logicfile, a physical file, and a control language (CL) program

● the SQL index created for an SQL-implemented accespath with *IMMED index maintenance.

� For more information:on auxiliaries, refer to this module, Chapter 3, “AddingAccess Paths,” Adding a Query (QRY) Access Path topand Chapter 3, "Modifying Access Paths," ModifyingAccess Path Auxiliaries topic.

Narrative TextNarrative text is user-added text associated with anyCOOL:2E object. You can add narrative text to any accesspath you create. After you create the access paths, add thenarrative text to describe its definition and function. It is usein the following places:

● documentation of the model

● interactive explanation of the model

● generation of help text for functions

● generation of program synopses

� For more information:on using narrative text, refer toGetting Started,Chapter3, “Using Your Model,” Using Narrative Text topic.

refer to this module, Chapter 8, “Documenting an AccesPath.”


Understanding Generator Types

d

r

Understanding Generator TypesWithin a COOL:2E design model, you can use both DDS anSQL to implement data definitions for all types of accesspaths.

� For more information:on generator types, refer to the following:

this module, Chapter 2, “Setting Up Default Options foYour Access Paths” and Chapter 7, “Generating andCompiling.”

Building Applications, Chapter 2, “Setting Up DefaultOptions for Your Functions.”

Getting Started, Chapter 4, “Using Your DevelopmentEnvironment.”

Generating and Implementing Applications


d to

e

Setting Default Options forYour Access Paths 2This chapter explains how to set up options for the model values assignethe access paths that you build and explains how to change compileroverrides.

Model ValuesModel-specific values control particular features of theinteractive use of COOL:2E, code generation, andimplementation.

� For more information:on what a model value is, refer toGetting Started,Chapter 4, “Using Your Development Environment.”

The model values you need to be concerned with whenbuilding access paths are

YALCVNM The Allocate Valid Name (YALCVNM) model valuespecifies whether DDS and SQL object names are to beallocated automatically by COOL:2E or by a specificstandard you establish for the COOL:2E model.

YOBJPFX The Object Prefix (YOBJPFX) model value specifies theprefix to be used when generating system objects.

YFILPFX The Last Used File Prefix (YFILPFX) model valuecontains the last 2-character identifying mnemonicCOOL:2E used when creating a new file. These twocharacters occupy positions three and four of the new filname, following the model object prefix.

� For more information:on object name prefixes, refer toGetting Started,Chapter 2, “Creating and Managing Your Model” and


Model Values

l

es

th.

er

d

nes

ly

tsw

Chapter 4, “Using Your Development Environment,”Setting Up the User Environment topic, Naming Controsubtopic.

YDBFGEN The Database Generation (YDBFGEN) model value specifithe default method of source generation (DDS or SQL) fordatabase definition.

You can set your source generation type by

● setting the model value YDBFGEN at the time that youcreate your COOL:2E model.

● changing the model value YDBFGEN after creating themodel.

● changing the generation mode on a specific access pa

� For more information:on setting the source generation type for your model, refto Getting Started, Chapter 2, “Creating and ManagingYour Model.”

YSQLLIB The SQL Library (YSQLLIB) model value specifies thelibrary (collection) in which to place the SQL objects needeto implement an SQL database.

YSQLVNM The SQL Naming (YSQLVNM) model value specifieswhether to use the extended SQL naming capability. You caspecify either DDS names (the shipped default) or the namof COOL:2E objects in the model (extend SQL naming).

YSQLLEN The SQL Naming Length (YSQLLEN) model value is anumeric value that controls the length of the extended SQLname. Its maximum value is 25. This model value is used onwhen YSQLVNM is *SQL.

� For more information:on extended SQL naming, refer toGetting Started,Appendix A, “SQL Implementation”.

YDBFACC The Database Access Method (YDBFACC) model value leyou specify whether to access data from a table or from a viewhen an access path and the table over which it is basedcontain the same fields.


Changing Values

l

,

r

ce

� For more information:on direct table access, refer toGetting Started, AppendixA, “SQL Implementation”.

You can set your model values when you create your modeor change the model value with theYCHGMDLVALcommand. However, once you have set your model valuesyou can then override many of these defaults for a specificaccess path using the access path detail options.

� For more information:on model values and how to set model values, refer toYCHGMDLVAL in COOL:2ECommand Reference.

Changing ValuesUse the following information to change the model values foyour access paths.

Allocating NamesThis topic tells you how to control the names assigned toCOOL:2E objects by changing the names given to the sourmember names when the access paths are built.

Allocating a Source Member Name for an AccessPath

1. Zoom into the file. At the Edit Database Relation panel,typeZ next to any relation for the file and pressEnter .

The Edit File Details panel displays.

2. Zoom into the access path.TypeZ next to the one youwant to rename and pressEnter .


Changing Values

ion

iesth

e

,

The Edit Access Path Details panel displays.

3. Enter the new source member name.Type the newsource member name in the source member name optfield and pressEnter .

Controlling Auxiliary NamesCOOL:2E generates default values for access path auxiliarfor Query (QRY) access paths and SQL tables or views wi*IMMED maintenance capability.

� For more information:on SQL generation, refer to Specifying Generation Modlater in this topic.

on SQL naming and separate view and index creation,refer toGetting Started, Appendix A, “SQLImplementation.”

Change the name of auxiliaries by using the followingprocedure.

1. Zoom into the file. At the Edit Database Relations paneltypeZ next to the relation for the file and pressEnter .


2. Zoom into the access path.TypeZ next to the selectedQRY (or SQL) access path and pressEnter .


Changing Values

ss in

e

n

g:

ytufic

The Edit Access Path Details panel displays with thedetails for the selected access path.

3. View the auxiliaries. PressF7 to view the access pathauxiliaries.

The Edit Access Path Auxiliaries panel displays.

4. Type the new source member names and pressEnter .

Creating an SQL EnvironmentUsing SQL facilitates the portability of generated applicationand is the only means of database access across machineDistributed Relational Database Architecture (DRDA).

� For more information:on SQL, refer toGetting Started, Appendix A, “SQLImplementation.”

on DRDA, refer to this module, Chapter 4, “ModifyingAccess Paths,” Building Distributed Relational DatabasApplications topic andGenerating and ImplementingApplications, Chapter 7, “Distributed RelationalDatabase Architecture.”

To create SQL tables and views for your model, you need aSQL library known as a collection. This collection containsthe SQL objects, including the catalog, a data dictionary, ajournal, and two journal receivers.

When creating an SQL environment, use one of the followin

● SQLLIB parameter on theYCRTMDLLIB commandcreates a collection library name with MDL replaced bySQL or a name of your choosing.

● Create SQL Library (YCRTSQLLIB ) command creates acollection and links it to a model.

Specifying Generation ModeThe choice of which generation mode to use is controlled bthe Database File Generation (YDBFGEN) model value thaacts as an implementation flag. The default value is DDS. Yocan use the following procedure to assign a value to a speciaccess path when it is built. The options you have areDDS andSQL.


Changing Values

at

,

Changing the Generation Mode at the Access Path LevelTo change the generation mode for a specific access paththe access path level:

1. Zoom into the file. At the Edit Database Relations paneltypeZ next to the relations for the file and pressEnter .


2. Zoom into the access path. TypeZ next to the accesspath whose generation mode you want to change andpressEnter .


3. Change the generation mode.Type the character thatrepresents the new generation model value.

Your options are:

D for DDS

S for SQL

M for MDLVAL

� Note: If an access path specifiesM for MDLVAL when it isgenerated, it will use the current value for theYDBFGEN model value. If you want to override thisvalue, enterD or S . The default isM.

4. PressEnter.


Changing Compiler Overrides

0

er

s

Changing Compiler OverridesWithin COOL:2E, there are various properties of the OS/40database files that you can modify by specifying compileroverrides. The overrides are the parameters on the compilcommands.

COOL:2E allows you to prompt for and store these overridethat are then automatically applied by the compile pre-processor when you compile your programs.

Some of the overrides you can specify are:

● Physical files: OS/400 Create Physical File (CRTPF)command

● MAXMBRS, SIZE

� Note: MAXMBRS is a parameter that specifies themaximum number of members the file can hold.

● Logical files: OS/400 Create Logical File (CRTLF)command

● MAXMBRS, DTAMBRS

� Note: Some of the compile parameters (MAINT, TEXT)are specified by the access path details. Overridevalues should not be specified for these values.

� For more information:on how to prompt for and store overrides, refer to thismodule's Chapter 7, “Generating and Compiling,”Changing Compiler Overrides topic.

on the OS/400 commands, refer toIBM AS/400 CLCommand Reference.


Changing Compiler Overrides


pesn

ofsethe

s

Adding Access Paths 3This chapter describes how to build an access path. A description of the tyof access paths is provided in this module's Chapter 1, “Access Paths: AIntroduction,” Recognizing the Basic Properties of Access Paths topic.

Before AddingWhen you create and define your file, COOL:2Eautomatically creates the following three default accesspaths for the file: physical, update, and retrieval. Thesedefault access paths have default values equal to thosethe model values. Generally, the access path options arewhen you create your model. However, you can change tvalues for the access paths at other times.

� For more information:on how to change the model values or values for aspecific access path, refer to the instructions in thismodule's Chapter 2, “Setting Up Default Options forYour Access Paths” and Chapter 4, “ModifyingAccess Paths.”

on model values, refer to theYCHGMDLVALcommand in COOL:2ECommand Reference.

Adding access paths to your design model allowsCOOL:2E to provide you with specific views of the data inthe physical files for your application. These views allowyou to retrieve data in a format that most suits your needwith less system overhead.

� For more information:on tailoring your access paths, refer to this module'sChapter 9, “Tailoring for Performance.”


Edit File Details

thst

r

Edit File DetailsThe Edit File Details panel is where you add new access pato your model, modify existing access paths, or view the lisof the existing access paths for a selected file.

1. Zoom into the file. TypeZ next to any relation for theselected file on the Edit Database Relations panel andpressEnter . Alternatively, you can use selection option2 from the Edit Model Object List panel.

The Edit File Details panel displays with a list of theaccess paths built over that file, the source membernames, key sequence, and implementation attributes.

2. Review the details.At the top half of this panel, view thedetails for the file.

3. Review existing access paths.At the bottom half of thepanel, view the list of all access paths already defined fothe file, including the three default access paths (PHY,RTV, and UPD).

Default access paths File details

Access path name Name to be givento generated file

Access pathimplementation

Automatic add of

Access path type


Adding an Access Path

en

s

e

of

his

d

Adding an Access PathA list of the available types of access paths follows:

● Physical (PHY)

● Update (UPD)

● Retrieval (RTV)

● Resequence (RSQ)

● Query (QRY)

● Span (SPN)

In addition to the three default access path types created whthe file is defined, you can create additional update andretrieval access paths or resequence, query, or span accespaths using the following instructions.

To add any access path, except a PHY access path, use thfollowing steps:

1. Zoom into the file. TypeZ next to any relation for theselected file on the Edit Database Relations panel andpressEnter . Alternatively, you can use selection option2 from the Edit Model Object List panel.

The Edit File Details panel displays with a list of anyexisting (default) access paths for the file.

2. Add the new access path.At the next available line onthis panel (use the Roll Up key, if necessary), type theaccess path value type in the Typ column and the namethe access path in the Access Path column and pressEnter .

Your options for the Typ column areUPD, RTV, RSQ,QRY, andSPN.

� For more information:on each access path type and when to use it, refer to tmodule's Chapter 1, “Access Paths: An Introduction.”

COOL:2E displays the following information for the newaccess path:

❍ source member name in the Source Mbr field

❍ unique and non-unique key selection in the Key fiel



l.

t

a

of

❍ maintenance selection (immediate, delay, andrebuild) in the Index field

3. View the access path details.TypeZ next to the newaccess path and pressEnter .


At this point, you have defined an access path to the mode

� For more information:on making changes to the access paths, such as to thekeys, or to add virtuals, refer to the instructions in thismodule, Chapter 4, “Modifying Access Paths.”

For additional instructions that are commonly used whenadding RSQ, QRY, and SPN type access paths, refer to thamaterial in the following topics.

Adding a Physical (PHY) Access PathUnlike other access path types, you cannot add a physicalaccess path to an existing file. The PHY access pathcorresponds to an arrival sequence OS/400 physical file orSQL table. When you create and define your file and thenzoom into the file from the Edit Database Relations panel,COOL:2E automatically creates a PHY access path as onethe three defaults.

� For more information:on creating and defining a file and instructions onassimilating a physical file, refer toDefining a DataModel, Chapter 4, “Creating/Defining Your Data Model”and Chapter 7, “Assimilation.”



in

he

n.ied

ns

ctsS

a

Adding a Resequence (RSQ) Access PathOnce you add the RSQ access path, follow the instructionsthe preceding topic, Adding an Access Path. At the EditAccess Paths Format Entries panel, you can also identify tnew key sequence order.

Changing the key sequence

1. Remove the old key sequence order from the Key no.column.

2. Add the new key sequence order in the Key no. columAscending or descending sequence can also be speciffor each field in the key sequence.

� Note: Lower key numbers indicate a higher key order or amajor key. The key sequence numbering should beunique.

Adding a Query (QRY) Access PathOnce you add the QRY access path, following the instructioin the preceding topic, Adding an Access Path, COOL:2Ecreates and generates default values for three auxiliary objefor DDS only. Each object type has its own source, either DDor CL, that is held in the appropriate source file in thegeneration library. These objects include

● logical file, which is based on the physical file whose datis being referenced.



h.

ed

s

an

nso

e

e

● physical file, which never contains data and is used todefine a record format and keys to any HLL programgenerated for a function based on the QRY access pat

● CL program, which executes the Open Query File(OPNQRYF) command. This command is called atexecution by any program generated for a function bason the QRY access path.

� For more information:on how the auxiliaries are implemented, refer to theImplementation table in this module's Chapter 7,“Generating and Compiling.”

Adding a Span (SPN) Access PathThe SPN access path is a multi-format view that allows viewof two or more formats. The SPN access path can only bespecified over files withOwned by or Refers torelationships. The SPN access path must be created overowning or referred to file.

Once you add the SPN access path, following the instructioin the preceding topic, Adding an Access Path, you can alsadd the new format entries:

1. View the SPN access path.PressF9 from the EditAccess Path Details panel to select formats.

The Display Access Path Formats panel displays wheryou select the format.

2. Select the primary format. Type anX next to theprimary format for the specified file and pressEnter.

� Note: You always select theRefers to or Owned by filefirst.

The Edit Access Paths Details panel redisplays whichshows the format selection indicated by the number in thSeq column next to the format.



deddl,

th,

ce

nt

3. Repeat the above process for each format.Follow steps1 and 2 to select the secondary format.

� Note: The keys of the second format must include all ofthe keys of the first format, in the same order. Anyadditional keys on the second format must besequenced after the first format keys.

Once you have completed the preceding steps, you have adthe SPN access path. To view the entries on the format anchange the key order, at the Edit Access Path Details paneperform the following.

4. Zoom into the format. TypeZ next to the format nameof the format.

The Edit Access Path Format Entries panel displays wia list of the details (fields), field type, source name, typekey number, alternate collating sequence, and referencount for your format.

5. Change the key order number for the format. At theEdit Access Path Format Entries panel, type the differesequence for the key order numbers and pressEnter .

COOL:2E stores the key sequence.




inedyouects

ownu

ltsre

ts

nser

is

er

Modifying Access Paths 4This chapter explains how to modify an existing access path. It contains ntopics that identify where you can modify the access paths. Once you adaccess paths to your model, you can modify the details, values, or optionsselected. COOL:2E provides sensible defaults for the selections and protthe values that should not be changed. However, in creating your ownapplication, you may need to change some of the defaults based on yourorganization's application design conventions. These procedures walk yothrough the process.

Before You BeginWhen an access path is created, it is created with defaubased on your model values. Some of the model values aspecifically used with access paths. By changing theoptions for one of these model values, it is possible tomodify the access paths if your application design warranthe changes.

� For more information:on the types of access paths available in COOL:2E,refer to this module's Chapter 1, “Access Paths: AnIntroduction.”

on the default values for access paths and instructioon how to change them, refer to this module's Chapt2, “Setting Default Options for Your Access Paths.”

on how to add access paths to your model, refer to thmodule's Chapter 3, “Adding Access Paths.”

on how to generate and compile an access path, refto this module's Chapter 7, “Generating andCompiling.”


Before Modifying

in

or

she

el

g

eaed

Before ModifyingThis topic describes navigational techniques and aids usedthe subfile selection area of the left margin of the panel andthe selection options found in the command text area at thebottom of the panels. This topic also identifies procedures fadding and removing virtual fields, holding and lockingaccess paths, and displaying access path references.

Navigational Techniques and AidsCOOL:2E provides you with ways to navigate to differentpanels other than by using function keys. COOL:2E identifiea number of standard line selection values usually found in tcommand text area at the bottom of the panel.

For example, you can useZ to zoom into a file orD to delete.When you place one of these selections next to a file in thesubfile selection area of your Edit Database Relations panand pressEnter , COOL:2E executes the action.

� For more information:on navigation, refer to Getting Started, Chapter 3, “UsinYour Model,” Navigation Facilities topic and Generatingand Implementing Applications, Chapter 1, “ManagingModel Objects,” Editing Model Object Lists topic.

Automatic Add OptionsEach access path initially contains all of the relations for thfile on which it is based, but none of the virtuals. If you addnew relation to a file, the effect on the access path is controllby the Automatic Add setting. Following are the three AutoAdd settings:

Changing the Auto Add Setting

1. Zoom into the file. TypeZ next to any relation for theselected file on the Edit Database Relations panel andpress Enter.

*Attr Only Only attributes are added (physical filechanges).

*All Both virtuals and attributes are added.

*Held No changes are made to the access path. Thisprevents level checking.


Before Modifying

s

sss

sat

sds

ed


2. Toggle the Auto Add setting. At the Edit File Detailspanel, typeH next to the selected access path and presEnter.

The allowable Auto Add settings and defaults are asfollows.

A refreshed panel displays with the indicator ALL, ATRONLY, or HELD showing that the selected access pathhas changed its Auto Add setting.

� Note: The key relations (Known by , Owned by , andQualified by ) are added to the access path regardleof the Auto Add setting. These relations must alwaybe present on all access paths for the file.

If a relation is added to an access path and functionthat use the access path already exist, the entries thresult from resolving the new relations are added toany device designs (reports and panels) used by thefunctions. For example, if the entries are not key fieldon the access path, they will be added as hidden fielto the device designs.

If they are key fields on the access path, they are addas input fields to the device designs. The devicedesigns may therefore require readjustment beforethey can be successfully regenerated.

� For more information:on readjusting the device designs, refer toBuildingApplications, Chapter 6, “Modifying Device Designs.”

Access Path Atr Only Held All

PHY Default No No

UPD Default Yes No

RTV Default Yes Yes

RSQ Default Yes Yes

QRY Default Yes Yes


Before Modifying

h

,

s

g

o

Trimming an Access PathYou can remove all virtuals from an access path using theTrim option.

To trim an Access Path:

1. Zoom into the file. TypeZ next to any relation for theselected file on the Edit Database Relations panel andpressEnter .


2. Trim the Access Path.At the Edit File Details panel,typeT next to the selected access path and pressEnter .You need to repeat the action to confirm.

� Note: You can also trim a format using the Edit Access PatDetails panel.

If you trim an access path that has Auto Add set to ALLAuto Add is reset to ATR ONLY.

Virtualizing an Access PathYou can add all virtual fields to an access path using theVirtualize option.

To Virtualize an Access Path:

1. Zoom into the file. TypeZ next to any relation for theselected file on the Edit Database Relations panel andpressEnter .


2. Virtualize the Access Path.At the Edit File Detailspanel enterV next to the selected access path and presEnter . You need to repeat the action to confirm.

� Note: You can also virtualize a format of an access path usinthe Edit Access Path Details panel.

If you virtualize an access path that has Auto Add set tHeld, it will be reset to All.


Before Modifying

d

omee

e.

t

ectee,n

sdd

el:

Locking an Access PathCOOL:2E supports two types of object locks: temporary anpermanent.

Temporary LocksTemporary locks are imposed automatically by COOL:2E tprevent two users from working on the same object at the satime. These locks are normally cleared by COOL:2E when thobject is no longer in use. Temporary locks hold the accesspaths so that they can be changed only by one user at a timThis lock is automatically placed on each COOL:2E objectwhile it is in use.

If you are using an object and leave the model abnormally,such as with a subsystem termination or power failure, atemporary lock can be left on the object. This lock nowprevents you from accessing the object. To remove thisinactive temporary lock, select L from the bottom of the EdiFile Details panel to view the locks in your model. COOL:2Eautomatically removes the locks no longer required.

Permanent LocksPermanent locks can be placed by the designer on any objto prevent any modification or generation of that object. Theslocks stay in effect, even if the object and model are not in usuntil they are removed by the designer. Permanent locks cabe placed on COOL:2E objects. A permanent lock preventusers from changing a COOL:2E object. For designers to aand remove permanent locks, they must have *OBJOWNrights to the YMDLLIBRFA data area.

� For more information:on locks, refer toGetting Started, Chapter 3, “Using YourModel,” Locking Objects topic.

Displaying Usages for Access PathsTo view a list of where each access path is used in the mod

View the usages.From the Edit File Details panel, typeU orF next to the selected access path and pressEnter .

The Display Model Usages panel displays with a list of allmodel objects that use the selected access path.


Building Distributed Relational Database Applications

s.ld

r

let

an

y.

o

� For more information:on usages, refer toGenerating and ImplementingApplications,Chapter 1, “Managing Model Objects,”Impact Analysis topic.

Building Distributed Relational DatabaseApplications

This topic discusses Distributed Relational DatabaseArchitecture (DRDA). DRDA is IBM's architecture thatprovides access to data distributed across various machineThe objective of DRDA is to provide the user, via a high-leveprogramming language, access to relational databases anfiles that reside on multiple machines.

Specifying Distributed FilesCOOL:2E lets you flag any files you create for DRDA on theEdit File Details panel. The distributed flag indicates whethethe file is distributed or local. The field has two values;Ymeans it is distributed andN means it is local. The default isN. YGENRDB is the model value that specifies the relationadatabase used when distributed functions are used. If it is sto *NONE, the flag is ignored regardless of its content.

AY implies that any access paths that are based on this file cconceivably exist on a remote machine. Files initiallydesigned and created as DistributedN can be changed toDistributedY, just as files created as DistributedY can bechanged to DistributedN.

� Note: Any functions built over this file must be regeneratedand recompiled to contain the distributed functionalit

� For more information:on Distributed Relational Database Architecture refer tGenerating and Implementing Applications,Chapter 7,“Distributed Relational Database Architecture.”


Modifying Access Path Details

nele,

s.

file

.

Modifying Access Path DetailsThis topic discusses use of the Edit Access Path Details paincluding specifying unique/duplicate key retrieval sequencaccess path maintenance, alternate collating sequence,select/omit criteria, generation mode, and changing sourcemember text and names.

Access paths are implemented as separate OS/400 objectYou can specify various implementation options for eachaccess path such as the OS/400 object name for the logicaland whether the access path maintenance will be Rebuild,Delay, or Immediate. COOL:2E provides defaults for thoseoptions and protects the values that should not be changed

For instance, OS/400 requires that immediate access pathmaintenance be specified if you specify the DDS UNIQUEkeyword. The values allowed for the implementation detailsdepend on the access path. A table of OS/400 access pathimplementation attributes follows.

Access path type(1) (2)Unique orDup keysequence(DDS only)

(3)Access pathmaint.

(4)Alt Col (DDSonly)

(5)Selection

PHY PhysicalUPD Update (default)UPD UpdateRTV Retrieval (default)RTV RetrievalRSQ ResequenceQRY QuerySPN Span

-UU/L/F/ /CUU/L/F/ /CU/L/F/ /CFU/L/F/ /C

-II,D,RII,D,RI,D,RI,D,RI,D,R

-----Yes-Yes

---S/DS/DS/DDS/D

The following legend applies for the access path types:(1) Unique key status (DDS unique keyword or SQL unique keyword

with create index statement). U indicates unique; if not unique, seenote (2). The default UPD and RTV access paths must be unique.

(2) Duplicate key sequence for DDS only (L=LIFO, F=FIFO,' '=undefined,C=FCFO)

(3) OS/400 access path maintenance (I=*IMMED, R=*REBLD, D=*DLY);for QRY access paths (I=*FIRSTIO, D=*MINWAIT, R=*ALLIO). Referto the following table.

(4) Alternative collating sequence table for DDS only (DDS ALTCOLkeyword)

(5) Selection type (S=static, D=dynamic) (DDS DYNSLT keyword)



is
The following table shows the effect of each of the AccessPath Maintenance options depending on whether this optionimplemented in DDS, CL, or SQL.
� For more information:on parameters for theOPNQRYF command, refer toIBM AS/400 Control Language Reference.

Edit Access PathDetails PanelMaintenanceOption

Method Used to Implement the Access PathMaintenance Option

DDS(Non-QRY Access

Paths)

(1)OPNQRYFcommand

(QRY AccessPaths)

SQL

I (immediate) *IMMED *FIRSTIO Create Index

D (delay) *DLY *MINWAIT No Index

R (rebuild) *REBLD *ALLIO No Index

(1) For QRY access paths the access path maintenance options areimplemented using OPTIMIZE parameter values on the OS/400OPNQRYF command.



ss

st

Editing Access Path DetailsYou can display and change the details for a COOL:2E accepath using the Edit Access Path Details panel.

You can display and edit the following details for an accesspath using the Edit Access Path Details panel.

Unique/Duplicate Key sequence

Access Path Maintenance

Alternate Collating Sequence

Select/Omit Criteria

Generation Mode

Source Member Name and Text

Specifying Unique/Duplicate Key Retrieval SequenceCOOL:2E lets you determine if the key values of the accespath are unique or duplicate and, if they are duplicate, whathe sequence would be.

1. Zoom into the file. From the Edit Database Relationspanel, typeZ next to the selected file and pressEnter .The Edit File Details panel displays.

2. Zoom into the access path.TypeZ next to the selectedaccess path and pressEnter . The Edit Access PathDetails panel displays.



e.

he

ons,ot

tion

3. Specify the key sequence.Change the key sequence byentering the selected option in the Duplicate Sequencefield and pressEnter .

The possible options are

U for unique (this requires Immediate maintenanc

F for first in, first out (FIFO).

L for last in, first out (LIFO).

C for first changed, first out (FCFO).

Blank means an unspecified sequence is used.

� For more information:on the unique/duplicate key sequence, refer toIBMAS/400 DDS Reference ManualandAS/400 DatabaseGuide.

Specifying Access Path MaintenanceCOOL:2E lets you select the type of maintenance for yourOS/400 access paths. OS/400 maintains all access pathsimmediately, while they are open, regardless of themaintenance option. However, when the file is closed, theaccess path maintenance option specifies to OS/400 how taccess path should be maintained.

The type of access path maintenance you specify dependsthe number of records, the frequency of additions, deletionand updates to a file, and the frequency of opens. If you do nspecify the type of maintenance, the default is immediatemaintenance.

Specify access path maintenance. At the Edit AccessPath Details panel, enter or change the maintenance selecfor updating the records in the Maintenance field and pressEnter.



r

n

The access path maintenance options are:

� Note: SpecifyI (immediate maintenance) for all files thatrequire unique keys in order to ensure uniqueness foinserts and updates.

� For more information:on access path maintenance, refer to this module'sChapter 9, “Tailoring for Performance” andIBM AS/400DDS Reference Manual.

on the OS/400OPNQRYF command, refer toIBMAS/400 Control Language Reference.

Specifying Alternate Collating SequenceCOOL:2E lets you specify a keyword to direct the OS/400program to use an alternative collating sequence table whesequencing the records.

I=*IMMED Immediate Maintenance. The OS/400 access pathis maintained as changes are made to itsassociated data, regardless of whether theOS/400 file is open.

For QRY access paths, the OPNQRYFcommand's OPTIMIZE parameter is set to*FIRSTIO, which minimizes time required to openthe file and to retrieve the first buffer of recordsfrom the file.

D=*DLY Delay maintenance. Any maintenance for theOS/400 access path is done the next time theassociated file is opened.

For QRY access paths, the OPNQRYFcommand's OPTIMIZE parameter is set to*MINWAIT, which minimizes delays while readingthe file.

R=*REBLD Rebuild maintenance. The OS/400 access path iscompletely rebuilt each time the file is opened.

For QRY access paths, the OPNQRYFcommand's OPTIMIZE parameter is set to *ALLIO,which attempts to minimize total processing time.



thathe

ss

th

A typical example is to use the OS/400-supplied translatetable, QCASE256, to make the collating sequence for bothupper and lower case the same. This creates an access pathsuppresses unwanted upper/lower case discrepancies in tcollating sequence while preserving the upper/lower casedifferences in the data. Any field used as a key for this accepath should be similarly translated (upper-case only).

Specify Alternate Collating Sequence. At the Edit Access PaDetails panel, enter or change the keyword name of thealternative collating sequence table in the AlternatingCollating Table field and pressEnter .

Use the OS/400 Create Table (CRTTBL ) command to createthe table or use an existing OS/400 table, such asQSYSTRNTBL or QCASE256.

Specifying Select/Omit CriteriaCOOL:2E allows you to specify select/omit criteria that filteryour view of the records for the RTV, RSQ, SPN, and QRYtype access paths.

� For more information:on select/omit criteria, refer to this chapter, ChoosingSelect/Omit Criteria topic.

Specify select/omit criteria. At the Edit Access Path Detailspanel, enter or change the select/omit criteria at the AllowSelect/Omit field and pressEnter .

Options are:

S for static, which applies the selection and omissioncriteria as the records are added (stored)

D for dynamic, which specifies the selection andomission of logical file records performed duringprocessing, instead of when the access path (if any) ismaintained

Blank for no selection/omission criteria

� Note: Dynamic must be specified if there are any virtualfields on the access paths. For QRY access paths,dynamic will be defaulted if required.



e

ion

ateL

ed.

Specifying Generation ModeCOOL:2E lets you specify the mode in which you generate thsource (Data Definition Language).

Specify Generation Mode. At the Edit Access Path Detailspanel enter or change the generation mode at the GeneratMode field and pressEnter .

Options are:

D for DDS

S for SQL

M for Model value

In COOL:2E, some combinations of files and access paths thuse different Data Definition Languages are permitted, whilsome are not. For example, you cannot have a COOL:2E SQlogical file over a COOL:2E DDS physical file. The followingtable outlines these rules.

Implications of Using SQL and DDS

SQL and DDS JoinsTo join information from tables/files, SQL uses inner joinsand DDS uses outer joins. Outer joins are not part of theAmerican National Standards Institute (ANSI) standard forSQL. If you switch an access path from DDS to SQL or vicversa, be aware that the same records might not be include

COOL:2E Logical Access Path

COOL:2EPhysicalAccessPath

DDS SQL

DDS Yes No

SQL Yes Yes



,ne.

on

n

The following examples illustrate an SQL inner join and aDDS outer join, where the joins resolve to a different set ofrecords:

In the above example, the customer record for Order # 002Cust. # 2, does not exist in the Customer file. In the SQL joifile, the record for Order # 002 is dropped from the file. In thDDS join file, the record for Order # 002 is included in the fileNote that the virtual field Cust. Name is filled with blanks inthe DDS join file.

Copying an Access Path Generated with SQLIf you use the Copy Model Objects (YCPYMDLOBJ )command to copy an SQL generated access path or functito a model that does not have a SQL environment,YCPYMDLOBJ runs successfully, but you need to create aSQL collection for the receiving access path before you cagenerate source.

Order File(Primary File)

Customer File(Secondary File)

Order # Cust. # Order Date Cust. # Cust. Name

001002003

123

4/1/924/2/924/3/92

134

JONESSMITHBROWN

Resulting Joined file–SQL

Order # Cust. # Cust. Name Order Date

Inner Join 001003

13

JONESSMITH

4/1/924/2/92

Resulting Joined file–DDS

Order # Cust. # Cust. Name Order Date

Outer Join 001002003

123

JONES*SMITH

4/1/924/2/924/2/92

* = spaces



ext

or

Changing Source Member Text and NamesCOOL:2E lets you change the source member names and tcreated.

Change the text or name. At the Edit Access Path Detailspanel, change the name in the Source Member Name fieldthe text in the Source Member Text field and pressEnter .


Modifying Access Path Format Entries

e

ds

her

lermat

y

e

or

h,

be

,s

Modifying Access Path Format EntriesThis topic provides information on identifying access pathformat text and keys and instructions on changing the keysequence and editing access path format entries.

An access path format shows which fields are present in thaccess path. It also indicates which of those fields are keyfields for the access path, and the order in which the key fielappear.

SPN type access paths can have more than one format. Ottypes of access paths have only one format.

Identifying Access Path Format TextAn access path format can have up to fifty characters ofdescriptive text. The default text is a concatenation of the finame and the access path name. The text appears in the FoText field on the Edit Access Path Format Entries panel.

Identifying Access Path Format KeysThe keys of UPD and RTV access paths come from the kerelations for the based-on file and cannot be changed.

The keys of the RSQ, SPN, and QRY type access paths arinitially defaulted to the entries defined by the key relationsbut can be changed. Keys can be sequenced in ascendingdescending order.

� For more information:on the OS/400 limit on the number of keys that can bespecified, refer toAS/400 Database Guide.

If an alternative collating table is specified for the access patyou can specify whether to use it to collate particular keyfields. You can use this panel to flag those keys that are toalternately collated.

Changing the Key Sequence

1. Zoom into the file. At the Edit Database Relations paneltypeZ next to any relation for the selected file and presEnter . Alternatively, you can use selection option2 fromthe Edit Model Object List panel.




aare

e's

ss

2. Zoom into the access path.TypeZ next to the selectedaccess path and pressEnter .


3. Zoom into the format. TypeZ next to the selectedformat and pressEnter .

The Edit Access Path Format Entries panel displays.

4. Change the key sequence.Change the key order asappropriate by changing the numbers in the Key no.column.

Numbers represent the order of the fields that make upcomposite key. Ensure that the key sequence numbersunique. Low key order indicates the sequence of themajor keys.

5. Generate the access path.For the new specification totake effect, you must regenerate the access path.

� For more information:on how to generate an access path, refer to this modulChapter 7, “Generating and Compiling.”

Editing Access Path Format EntriesThe presence of a field on an access path format (an accepath entry) is controlled by the relations specified for theaccess path. By default, all the relations specified for the



so

thereth

e

ath

ts

n

ile

s

,s

based-on file are declared to be present on an access paththat all the fields from the file are initially present. Bydropping particular relations from an access path, you canomit fields from the access path's format.

To display and change the relations for an access path, useEdit Access Path Relations panel. To display the fields that apresent on the access path format, use the Edit Access PaFormat Entries panel.

You can use the Edit Access Path Format Entries panel tospecify an alternative key order for RSQ, QRY, and SPN typaccess paths. COOL:2E lets you edit access path formatentries using the Edit Access Path Details panel. Access pformats are created automatically for all access path typesexcept SPN. For SPN access paths you need to add formaexplicitly.

� For more information:on adding SPN access path format entries, refer to thismodule's Chapter 3, “Adding Access Paths.”

� Note: Relations are present on an access path if they wereadded to the based-on file after a hold was specified othe access path.

Editing Physical File Format EntriesThe physical file format entries for an assimilated COOL:2Ephysical access path can be edited using the Edit Physical FFormat Entries panel. You use the panel to specify overridevalues to be used when generating source.

This panel allows you to specify

● that the fields in a given database file have differentimplementation names from those used in the logical filebased over them.

● that the fields occur in a different order from that shownon the Edit Access Path Entries panel.

Altering Field Sequence or Implementation Name

1. Zoom into the file. At the Edit Database Relations paneltypeZ next to any relation for the selected file and pres



ss

Enter . Alternatively, you can use selection option2 fromthe Edit Model Object List panel.


2. Zoom into the physical access path of the assimilatedfile. TypeZ next to the PHY access path and pressEnter .


3. Zoom into the format. TypeZ next to the format andpressEnter .

The Edit Access Path Format Entries panel displays.

4. Access the Edit Physical File Format Entries panel.PressF8.

The Edit Physical File Format Entries panel displays.

5. Change the DDS Name or the Sequence.Change theDDS name or the file sequence as appropriate and preEnter .

Fields in format Overrideorder

Overridename


Modifying Access Path Relations

rth.e

ofss

's,

g

e.

s

Modifying Access Path RelationsThis topic discusses required relations and providesinstructions on editing access path relations.

The relations for an access path are composed of the set osubset of a file's relations that apply to a particular access paFor a specific access path belonging to a given file, only somof the relations specified for the file need to apply.

In other words, a particular access path may not require allthe fields and relations from the file to be present on the accepath. Each access path may have its own subset of the fileattributes and relations. When you drop file-to-file relationssuch asRefers to , those key fields associated with the relationare dropped as are all associated virtual fields. The followinis an illustration of access path and file relations.

� For more information:on relations, refer toDefining a Data Model,Chapter 3,“Understanding Your Data Model,” Using Relationstopic.

Understanding Required RelationsThe key level relations for a file (Known by , Owned by , andQualified by ) must be present on all access paths for the fil

A PHY type access path always contains all of the relationsfor the file on which it is based. On UPD and RTV type accespaths, define the entries resulting from the resolution of the

File A

AAAA

bcDE

Known byHasRefers toRefers to

Access path (1)

AAAA

bcDE

Known byHasRefers toRefers to

Access path (2)

AA

A

bc

E

Known byHas

Refers to

Access path (3)

A

A

b

D

Known by

Refers to



aththe

lele'seld

hed

dy

e

than

relations as the keys of the access path. On other access ptypes, the relations merely cause the fields to be present onfile, not necessarily as key fields.

� For more information:on how to define specific required relations, refer to theinstructions in this chapter, Adding Relations to a Filetopic.

Adding Relations to a FileEach access path initially contains all the relations for the fion which it is based. If a new relation is added to a file, it wilbe added to the list of access path relations for each of the filaccess paths provided that the access paths are not held. Haccess paths remain unchanged, as do any functions attacto them.

If a relation is added to an access path and functions alreaexist that use that access path, the entries that result fromresolving the new relations will be added to the function'sdevice designs as follows:

● If they are not key fields on the access path, they will badded as hidden fields to the device design.

● If they are key fields, they will be added as input fields tothe device designs.

Editing Access Path RelationsCOOL:2E lets you display and edit access path relations withe Edit Access Path Relations panel. On this panel, you creinstate or drop relations from an access path.

1. Zoom into the file. From the Edit Database Relationspanel, type aZ next to any relation for the selected fileand pressEnter . Alternatively, you can use selectionoption2 from the Edit Model Object List panel.



The Edit Access Paths Details panel displays.

3. Select the access path relation.Type anR next to theselected access path and pressEnter .



ete'sld.

The Edit Access Path Relations panel displays.

4. Specify the access path relations.Type+ (plus) or-(minus) next to the relations you want to reinstate orremove from the access path and pressEnter .

Each access path initially contains all of the relations for thfile on which it is based. If a new relation is added to a file, iis added to the list of access path relations for each of the filaccess paths except those access paths specified to be heHeld access paths remain unchanged as do any functionsattached to them.


Modifying Virtual Field Entries

alon

ss

ld

h.

s

of

Modifying Virtual Field EntriesThis topic explains how to identify relations with virtualfields, specify file and access path relations, and tailor virtufields for access paths. This topic also contains instructionsediting virtual field entries.

A virtual field specified on a relation of a file is added, bydefault, to each instance of that relation on a particular accepath of the file.

Understanding Access Path Virtual Field EntriesAn access path virtual field is a field that is logically, ratherthan physically, present on an access path. Although the fiedoes not reside on the based-on physical file, a view of it isavailable through the relations that exist for the access pat

It is possible to omit particular virtual fields from a particularaccess path. The virtual fields for an access path can beselected only from among fields that have been specified avirtual fields for the file.

For example, if Customer file has five fields (Customer no.,Branch name, Branch no., Customer name, and Customeraddress), and if Customer fileRefers To Branch file withonly Branch name field as a virtual field, only the Branchname field is available as a virtual field on all access pathsCustomer file.

Branch Known by Branch no.

Branch Has Branch name

Branch Has Branch address

Customer Known by Customer no.

Customer Has Customer name

Customer Has Customer address

Customer Refers to Branch



th

eted

d

er.

is

The CustomerRefers to relation adds the field Branch No. tothe Customer file. Virtualization allows you to add the fieldBranch name as a virtual field to the Customer file. You caninclude or drop this virtual field from any access paths overthe Customer file.

Identifying Relations with Virtual FieldsCOOL:2E lets you specify only virtual fields on theOwnedby, Refers to , andExtended by relation types. Virtual fieldscan be used only as read-only fields in standard functions.This read-only field is implemented as a join logical file orSQL view. It checks on the generation mode and access patype.

Different access paths for a file can contain differentcombinations of relations, and each file-to-file relation on thaccess path can have a different set of virtual fields associawith it.

� For more information:on files and relations, refer toDefining a Data Model,Chapter 3, “Understanding Your Data Model” andChapter 4, “Creating/Defining Your Data Model.”

Specifying File and Access Path RelationsSpecifying virtual fields is a two level process: for a field tobe used as a virtual field, you must specify it as a virtual fielon both the file relations and the access path relations.

In the previous example, the field Branch address is notavailable as a virtual field on any access path of the Customfile, as it is not specified as a field on the relations for the file

� For more information:on specifying virtual fields on a file, refer toDefining aData Model, Chapter 5, “Maintaining Your Data Model,”Adding/Modifying Virtual Fields topic.

on specifying virtual fields on an access path, refer to thtopic, the Tailoring Virtual Fields for Access Pathssubtopic.



ve

l

sss

,s

The following example shows you how access paths can hasubsets of the relations on the file.

Editing Virtual Field EntriesCOOL:2E lets you edit the virtual field entries on both the fileand the access path. Field level virtual fields are specifiedusing the Edit Virtual Field Entries panel. Access path virtuafields are specified using the Edit Access Path RelationVirtual Fields panel.

The file level panel declares that a field is available for use aa virtual field on any of the access paths for the file. The accepath level panel specifies that a virtual field is present on aparticular access path.


The Edit File Detail panel displays.

File A

AAA

A

bcD

E

Known byHasRefers to

Vrt: x,y,zRefers to

Vrt: h

Access path (2)

AA

A

bc

E

Known byHas

Refers to

Access path (3)

A

A

b

D

Known by

Refers toVrt: z

Access path (1)

AAA

A

bcD

E

Known byHasRefers to

Vrt: x,y,zRefers to

Vrt: h

File E

EEE

Known byHasHas

fgh

File D

DDDDDD

wxyzrt

Known byHasHasHasHasHas



d.



3. Zoom into the format. TypeZ next to the selectedformat and pressEnter .

The Edit Access Path Format Entry panel displays.

4. Specify virtual fields. PressF7 andEnter .


5. Select the virtual field entry. TypeV next to the selectedrelation and pressEnter .

The Edit Access Path Relation Virtual Field paneldisplays.

� Note: The selected relation must be anOwned by ,Refers to , orExtended by relation or you will notbe able to virtualize the field.

6. Edit the virtual field entry. Type+ (plus) or– (minus)next to the field(s) you want to virtualize and pressEnter .

A refreshed panel displays with your choices highlighte


Choosing Select/Omit Criteria

nt

ssdes

orn

Aited

teds

mitif

hee

Tailoring Virtual Fields for Access PathsIt is important to consider the design of your application whespecifying virtual fields. Ensure that the join logicals you seup when you virtualize provide you with the data you need.This saves the operating system from having to dounnecessary Input/Output (I/O) to other files.

� For more information:on tailoring virtuals, refer to this module's Chapter 9,“Tailoring for Performance,” Using Join Logicals topic.

Choosing Select/Omit CriteriaThis topic provides instructions on specifying selection andconditions.

Access path selection lets you specify that a particular accepath retrieves only the records from the file that meet specifieselect/omit criteria, such as those that contain specified valufor particular fields.

For example, you have a personnel file containing records fboth full-time and part-time employees. If you want to obtaia view of only the part-time employees, you can define anaccess path with selection on an employee type field thatidentifies part-time employees.

Understanding Select/OmitCOOL:2E lets you specify selection using a select/omit set.given access path may have none, one, or many select/omsets specified. If there is more than one set, the sets are ORtogether.

Once a record satisfies a select or omit set, it is either selecor omitted and further sets are not relevant. If a record doenot satisfy a select or omit set, it will be tested againstsubsequent sets. If a record does not satisfy any select or oset, it is omitted if the last set was a select set and selectedthe last set was an omit set.

Each set is made up of one or more conditions that specify tactual values that a field may take. If there is more than oncondition, the conditions within a set are ANDed together.



r is

ed

p

,s

e

For example, if there are two conditions, both must be validfor the entire set to be valid.

In the following example, the access path suspended ordemade of two select/omit sets: Awaiting Confirmation andPassed Credit Check. Each of the select/omit sets are definby one or more conditions.

Specifying SelectionUse the Edit Access Path Select/Omit panel to specifyselection and the names of the select/omit sets that make uthe selection criteria. The following steps tell you how tospecify selection.





3. Select the format.TypeS next to the selected format andpressEnter .

The Edit Access Path Select/Omit panel displays.

� Note: The Allow Select/Omit access path option must bset to either S or D.

Accpth Select/Omit set Field Condition Op Value

Suspendedorder

Select 001 Passed creditcheck 001

AND 002Order statusCredit limit

OpenNot exceeded

*EQ*GT

H5000

Select 002 Awaitingconfirmation

001AND 002

Invoice statusInvoice value

Unconfirmednot zero

*EQ*GT

U0



p

n

it

e

4. Specify selection.Enter anS for select orO for omit inthe S/O column and the text description to indicate thename for the selection criteria set.

5. Zoom into the selection.TypeZ next to the selection tospecify the conditions and pressEnter .

The Edit Access Path Conditions panel displays.

Specifying ConditionsUse the Edit Access Path Conditions panel to specifyconditions (which are the actual field conditions that make ua given select/omit set).

1. Specify the condition.Enter the field and conditionname for the selection in the appropriate column. If youdo not know the field or condition name, place a questiomark in the appropriate column and pressEnter .

The Display Access Path Format Entries panel or the EdField Conditions panel displays.

2. View the fields or conditions.TypeX next to theselected field or condition and pressEnter .

The Edit Access Path Conditions panel displays with thselections.


Changing a Referenced Access Path

heressisu

athe

he

ult

d

� For more information:on how to add conditions, refer toDefining a Data Model,Chapter 5, “Maintaining Your Data Model,”Adding/Modifying Conditions topic.

Changing a Referenced Access PathThis topic discusses referenced access paths.

When an access path includes a relation that refers to anotfile, the relation always references an access path. This accpath is used by functions for validation and, by default, thisthe access path RTV automatically created by COOL:2E. Yocan, however, alter the relation so that a different access pis used. This enables you to specify selection criteria for threlationship.

Using the F4 prompt function assignment you can change tprompt function assigned to a file-to-file relation. If youchange the access path, then the prompt function will defato the SELRCD function for that access path.

� For more information:on function assignment, refer to the information at the enof this topic.

In a database recording pedigrees, you could specify thatMothers be only female, and Fathers be only male byspecifying the access path selection on the relation.

Animal

Mother Father



s

s

d

s,

The relations you would need to specify the pedigree are afollows:

Then, having attached two conditions to gender, Male andFemale, you can define two additional retrieval access pathon the Animal file that select on each gender respectively.

Having added the new access paths, you can return to therelations for the original retrieval COOL:2E access path anspecify that theRefers to relations are to use the additionalCOOL:2E access paths with gender-specific selection. Thufathers must be male, and mothers must be female.

1. Zoom into the access path details.TypeZ next to theselected access path on the Edit File Details panel.


FIL Animal REF Known by FLD Animal code CDE

FIL Animal REF Has FLD Animal name TXT

FIL Animal REF Has FLD Gender STS

FIL Animal REF Refers to FIL Animal REF

FIL For Mother Sharing:

FIL Animal REF Refers to FIL Animal REF

FIL For Father Sharing:

Z option to transfer to access path details display

COOL:2E access paths for file



to

orer

,

2. Go to the access path relations panel.TypeR next tothe formats and pressEnter .


3. Select the Referenced Access Paths option.TypeAnext to the relation and pressEnter .

The Display File Access Paths panel displays.

4. Select the access path.TypeX next to the appropriateaccess path and pressEnter .

F4 Prompt Function AssignmentCOOL:2E allows you to change the access path assignedthe file-to-file relation and to assign a new prompt functionover the access path. This can be done at the access pathfunction level. Function level overrides take precedence ovaccess path level overrides.

� For more information:on F4 prompt function assignment at the function levelrefer to Building Applications, Chapter 3, “DefiningFunctions,” SELRCD topic.

To prompt for a new function assignment:

The A option is used to call a subsidiary panel to change the relationsto use the appropriate COOL:2E access paths in the based-on file.


Modifying Access Path Auxiliaries

dit

ess

,es

ay

nt

a,L

1. Use the instructions on the previous page to get to the EAccess Path Relations panel.

2. TypeS next to the selected file-to-file relation you wantto assign to the access path and pressEnter .

The Edit Function panel displays.

3. TypeX next to the selected function and pressEnter .

You can select any external function other than Print Fil(PRTFIL) and the function can be based over any accepath that is valid for the function type you select.

To cancel the function assignment and return to the defaultfunction:

TypeT next to the selected relation and pressEnter.

Modifying Access Path AuxiliariesThis topic provides instructions on editing access pathauxiliaries.

To implement QRY type access paths for DDS, use theOS/400 Open Query File (OPNQRYF) command. For SQLuse dynamic SQL. In order to do this, COOL:2E holds somadditional information for QRY access paths and SQL tableand views with *IMMED maintenance capability, which isshown on the Edit Access Path Auxiliaries panel. COOL:2Egenerates default values for the access path auxiliary displwhen the access path is created.

Understanding Access Path Auxiliaries

For DDS Query (QRY) Access PathsUse the following three types of OS/400 objects to implemea QRY access path in DDS:

● an OS/400 logical file based on the real physical filewhose data is being referenced.

● an OS/400 physical file, which does not contain any datbut is used to define a record format and keys to any HLprogram generated for a function based on the QRYaccess path.



It

hy.

e

r to

dn

,s

● a CL program that executes the OPNQRYF command.is called at execution by any program generated for afunction based on the QRY access path.

Each object type has its own source, either DDS or CL, whicis held in the appropriate source file in the generation librar

All three of the auxiliary objects must be generated andcompiled.

You can control the implementation names given to theauxiliary objects by controlling the names given to the sourcmembers generated for them. If the YALCVNM model valueis set to YES, COOL:2E will automatically supply sourcemember names.

� For more information:on access path auxiliaries and QRY access paths, refethis module's Chapter 1, “Access Paths: AnIntroduction.”

For SQL Access Paths with *IMMED MaintenanceWhen an access path that is implemented in SQL is createwith *IMMED index maintenance, COOL:2E also creates aSQL index as an access path auxiliary. You can suppressgeneration of the SQL index and also retain *IMMEDmaintenance capability.

� For more information:on SQL, refer toGetting Started, Appendix A, "SQLImplementation."

Editing Access Path AuxiliariesUse the Edit Access Path Auxiliaries panel to display andchange the auxiliary details for a QRY(or SQL) access pathincluding changing source member names.

1. Zoom into the file. At the Edit Database Relations paneltypeZ next to any relation for the selected file and presEnter. Alternatively, you can use selection option2 fromthe Edit Model Object List panel.


2. Zoom into the access path.TypeZ on the selected QRY(or SQL) access path and pressEnter .



d


3. View the auxiliaries. PressF7.

The Edit Access Path Auxiliaries panel displays.

� Note: In order to get theF7 option for auxiliaries, youmust zoom into the access path by typingZ next tothe access path.

4. Edit the auxiliaries. Change any of the following detailsas appropriate:

❍ Source Member Name

❍ Source Member Text

❍ Index Name for SQL only. Type*NONE to suppressgeneration of the SQL index.

5. Generate the access path.For the new specifications totake effect, you need to regenerate the access path.

� For more information:on how to generate the access path, refer to theinstructions in this module's Chapter 7, “Generating anCompiling.”




ure no

ed

w

Deleting Access Paths 5This chapter contains instructions on how to delete access paths from yoapplication. You may want to delete access paths created in error or thoslonger needed.

Deleting an Access PathAccess paths can be deleted only if they are not referencby any other function or access path. A cross-referencepanel, Display Access Path Reference, is available to shoyou where a given access path is used.

To delete an access path:

1. Zoom into the file. At the Edit Database Relationspanel, typeZ next to any relation for the selected fileand pressEnter . Alternatively, you can use selectionoption2 from the Edit Model Object List panel.

The Edit File Details panel displays with a list of theaccess paths for the file.

2. Delete the access path.TypeD next to the access pathyou want to delete and pressEnter .


Deleting an Access Path

fy

if

tege

The Delete Access Path panel displays.

3. Validate your actions. PressEnter to validate thedeletion.

An additional confirmation prompt displays before theaccess path is deleted. This prompt allows you to specithat the source and object are to be deleted.

COOL:2E does not allow you to delete the access pathit is referenced by any other function or access path.

You must eliminate the references before you can delethe access path. You can do so by determining the usaof an access path.

4. Confirm the deletion. At prompt, pressEnter toconfirm the deletion.


Determining the Usage of an Access Path

s

eiltan

Determining the Usage of an Access Path1. View the access path usages.EnterU next to the selected

access path on the Edit File Details panel and pressEnter .

The Display Model Usages panel displays with a list offunctions and other access paths that reference theselected access path.

2. View the functions that use the access path.TypeFnext to the selected access path on the Edit File Detailpanel and pressEnter .

The Display Model Usages panel appears with a list of thfunctions that reference the access path. A function buover an access path is an example of a function usingaccess path.

� For more information:on usages, refer toGenerating and ImplementingApplications,Chapter 1, “Managing Model Objects,”Impact Analysis topic and the COOL:2ECommandReference, YDSPMDLUSG command.


Determining the Usage of an Access Path


tingThehes theas

use

of

ndtsds

sis

esy

Defining Arrays 6This chapter contains procedures for defining, editing, renaming, and delean array. An array is a structure that stores sets of data within a function.contents of an array are available only as long as the function is active. Tstructure has a defined layout and each entry (element) of the structure hasame layout. Define this layout with any set of fields from the model, suchattribute, code, and function fields.

Use arrays to

● improve performance where a function requires repeated access andof a finite number of entries, such as table lookups.

● move between a field and a data structure.

● sequence a finite set of data by a set of unrelated key fields.

Programmers (*PGMR) and designers (*DSNR) can define arrays.

Understanding ArraysThe array has a defined layout and each entry (element)the structure has the same layout. Define this layout withany set of fields from the model, such as attribute, code, afunction fields. The array must have a defined key that acas an index into the array. The key is any subset of the fielin the array structure, up to a maximum composite keylength of 990. Each key field in the composite key list actas a different dimension to the array. The composite keydefined as being either unique or non-unique.

COOL:2E does not guarantee the sequence of equallykeyed elements in a non-unique array. The key also isdefined as ascending or descending. This definition applito the complete composite key. When determining the kesequence, COOL:2E ignores the signs of any numericalfields in the key of the array.

Arrays can be used only by the *CVTVAR built-in functionand the following four standard data function types:


Structuring Field Data Using Arrays

re,

th

Create Object (CRTOBJ) to add an element

Change Object (CHGOBJ) to change an element

Delete Object (DLTOBJ) to delete an element

Retrieve Object (RTVOBJ) to read an element or set ofelements

� For more information:on how to use or clear the data from an array, refer toBuilding Applications, Chapter 3, “Defining Functions,”Array Processing topic.

Structuring Field Data Using ArraysSince a single-element array is equivalent to a data structuyou can use the *CVTVAR built-in function and the ELMcontext to apply a data structure to a field. This gives you asimple way to decompose a field into a structure and to(re)compose a set of fields into a single field in a singleoperation.

Structure files (STR) provide a similar capability, but youneed to be a designer (*DSNR) to define a structure file. Bo*DSNR and *PGMR can define arrays.

� For more information:on structuring field data and examples, refer toBuildingApplications, Chapter 7, “Modifying Action Diagrams,”Understanding Built-In Functions” (*CVTVAR) and“Understanding Contexts” (ELM).


Passing Parameters

nwse

nhe

reM

set

al

r

Passing ParametersYou can also use arrays to define a set of fields that are theused as a parameter entry to any function. This process alloyou to define a large number of parameters of any field typto a function without creating a structure file (a *DSNRfunction).

Storing Data Between CallsFor programs that do not close down, arrays are initialized othe first call to the program. Subsequent calls do not clear tarray. The first call loads the array and subsequent callsretrieve that data. In addition, you can define an array to stoand restore any fields in the program between calls. The PGcontext variableInitial Call can be used to distinguishbetween first and subsequent calls. This variable is alwaysto *YES if the program closes down.

� For more information:on defining arrays, refer toBuilding Applications.

Defining an ArrayThis topic tells you how to create and fully define an array.This process includes selecting the fields for the array anddefining the relative order of the fields by assigning sequentinumbers to key fields.

1. View the list of files. At the Edit Database Relationspanel, type*a or * ARRAYS in the positioner field at thetop of the panel and pressEnter .

The list of the COOL:2E reserved files displays.

2. Zoom into the array file. TypeZ next to the *Arrays fileand pressEnter.

The Edit Array panel displays.

3. Define the array. Type the name of the new array undethe Arrays heading in the first blank line and pressEnter .

The name must be a unique array name. This fieldbecomes an output-only field.


Defining an Array

g

of

fll

The default line data for the new array displays, includinthe following information.

❍ Sequence: Sequence of the key or composite keythe array in either ascending or descending order.The default for this field is ASCEND.

❍ Unique: Defines if the keys in the array must beunique or non-unique. Unique is the default.

❍ Elements: Defines the maximum number (9999) oelements that this array can hold. An element is a fuarray entry and not a field within that entry. Thedefault is 100.

The following array sample could be used to accumulateOrder Totals for each State/Branch combination.

Selecting Field and Key Details for Your Array

4. Zoom into the array. TypeZ next to the selected arrayand pressEnter.

The Edit Array Details panel displays. This panel iswhere you specify the files and fields that are used todefine the layout of the array entry.

Customer Customer no.Customer nameState code

Order Header Order no.Customer no.Branch no.Order value

Order Value by State/Branch

File (1) Access Path (1) Fields (2) Key (3)

Customer Retrieval Index State code 1

Order Retrieval Index Branch no. 2

Order value

(1) This definition comes form the Edit Array Details panel(2) This definition comes form the Edit Array Entries panel(3) This definition comes form the Edit Array Key Entries panel


Defining an Array

dr

5. Specify the layout.Specify the file or field that definesthis part of the array entry layout.

6. Define source.Define the source of the field definitions.This source may specify file or *field.

7. Specify the field.If the source of the field is *FIELD,specify the actual field in the next column (or select byentering?).

8. Specify the access path.If the source of the field is a file,specify the access path of the file (or *NONE for all fieldsfor the file) in the second column.

a. TypeZ next to the line and pressEnter to select therequired fields from the access path.

The Edit Array Entries panel displays with a list offields for the selected access path or file.

b. Type+ (plus) next to the fields you want to add to thearray and pressEnter .

c. Type– (minus) next to selected fields you want todrop from the array and pressEnter .

9. Exit. PressF3 to exit panel.

The Edit Array Details panel redisplays with a list ofselected fields.

10. Select keys.PressF7 to select the keys for an array.

The Edit Array Key Entries panel displays.

Note that you must define a key for an array even if thearray holds a single element.

11. Select the key order for the fields.Type a number in theKey no. column that defines the relative order of the fielin the composite key list. The lowest value (1) is the majokey or first dimension of an array.

You have created and defined your array.


Editing an Array

t

Editing an ArrayTo edit an array, use the steps in the preceding Defining AnArray topic to determine where to make the following typesof changes to your array.

Array Details:

● sequence status

● unique key status

● elements

Fields Definitions:

● selected files

● selected access paths

● selected fields

Key Order:

● key and composite key

Type– (minus) next to any selected+ (plus) field you want toremove from the array on the Display All Fields panel.

In addition, use the following instructions to examine arrayusage and change the array name.

Viewing Function ReferencesAt the Edit Array panel, typeF next to the selected array toexamine the usage.

The Display Model Usages panel displays the functions thause the selected array.

Changing the Name of an ArrayFollow these steps to change the name of an array.

1. View the list of files. At the Edit Database Relationspanel, type* a or * ARRAY in the positioner field on thetop line of the panel and pressEnter .

The list of reserved files displays.

2. Zoom into the array file . Typev next to the Arrays file.


Deleting an Array

t

n.

The Edit Arrays panel displays with a list of the arrays inyour model.

3. Zoom into the array. TypeZ next to the array you wantto rename.

The Edit Array Details panel displays with the name ofthe array and the array details.

4. Change output field to input field. PressF8.

The output-only field, Array Name, is changed to aninput-capable field.

5. Rename the array.Type the new name of the array andpressEnter to accept the change.

The panel redisplays with the new array name.

� Note: The array name must be unique; COOL:2E does noaccept duplicate names.

Deleting an ArrayThe COOL:2E Delete Array feature allows you to delete anexisting array.

1. View the list of files. At the Edit Database Relationspanel, type*a or * ARRAY in the positioner field on thetop line of the panel and pressEnter .

The list of the reserved files displays.

2. Zoom into the array file. TypeZ next to the Arrays file.

The Edit Arrays panel displays with a list of the arrays inyour model.

3. Delete the array.TypeD next to the array you want todelete and pressEnter .

A Delete Array window displays at the top of the panelthat confirms the delete array request.

� Note: You cannot delete an array if it is used by any functio


Deleting an Array

� For more information:on how to determine array usage, refer to this chapter,Editing an Array topic, Viewing Function Referencessubtopic.


pevides

s.

theon

ted

re

e

s

Generating and Comspiling 7This chapter contains information on the results of generating a specific tyof access path, depending on the generation mode you selected, and proinstructions on how to generate and compile an access path.

You must first generate the HLL source code needed to implement accespaths you created. Instructions for this are provided earlier in this moduleAfter you generate the access paths, you compile the source to produceexecutable OS/400 objects, files, and tables.

ImplementingAn access path closely corresponds to the OS/400 use ofterm. You can specify an access path to various generatimodes, including values such as DDS and SQL. DDSgenerates physical and logical file and SQL generatesindices and table.

You must first generate the source members for thedatabase files to implement the access paths. The generasource needs to be compiled. You can generate sourceeither interactively or in batch.

OS/400 Index Versus COOL:2E IndexThe type of index generated is determined by the sourceyou select in the model value. COOL:2E access paths agenerated as OS/400 objects. OS/400 access paths aregenerated as indices and views.

Setting Your OptionsYou can specify various implementation options for eachaccess path such as the OS/400 object name used for thlogical file and whether the access path maintenance isRebuild, Delay or Immediate. COOL:2E provides defaultfor these options.


Implementing

le

is

Changing Compiler Overrides from DDS to SQLIf you change your model from DDS to SQL, verify that the*MESSAGE shipped file contains the COOL:2E shippedcompiler options. Any DDS overrides in effect duringgeneration for an SQL implementation will cause the compito fail.

Identifying the Implementation AttributesThe following table shows the OS/400 implementationattributes for each of the access paths.

For SQL, static selection is implemented via SQL DataDefinition Language (DDL) statements. Dynamic selectionimplemented by Data Manipulation Language (DML)statements.

Access path type(1) (2)Unique orDup keysequence(DDSonly)

(3)Accesspathmaint.

(4)AltCol(DDSonly)

(5)Sel-ection

SQLImplementation

DDSImplementation

PHY PhysicalUPD Update (default)UPD UpdateRTV Retrieval (default)RTV RetrievalRSQ ResequenceQRY Query

SPN Span

-UU/L/F/ /CUU/L/F/ /CU/L/F/ /CF

U/L/F/ /C

-II/D/RII/D/RI,D,RI/D/R (6)

I,D,R

-----Yes-

Yes

---S,DS,DS,DD

S,D

TableView and IndexView and IndexView and IndexView and IndexView and IndexView and Index

Two indicesand two views

Physical FileLogical FileLogical FileLogical FileLogical FileLogical FilePhysical FileLogical FileCL ProgramLogical File

The following legend applies for the access path types:(1) Unique key status (DDS unique keyword or SQL unique keyword with createindex statement). U indicates unique; if not unique, see note (2). The default UPDand RTV access paths must be unique.(2) Duplicate key sequence for DDS only (L=LIFO, F=FIFO,' '=undefined,C=FCFO).(3) OS/400 access path maintenance (I=*IMMED,R=*REBLD, D=*DLY). For QRYaccess paths, see item (6).(4) Alternative collating sequence table for DDS only (DDS ALTCOL keyword).(5) Selection type (S=static, D=dynamic) (DDS DYNSLT keyword).(6) Causes the OS/400 OPNQRYF command to be called with the OPTIMIZEoption equal to *FIRSTIO, *MINWAIT, or *ALLIO, respectively.


Implementing

it

ue

ur

r

f

e

s.

� Note: If an SQL-generated RSQ access path has select/omcriteria and is defined as Unique with Staticmaintenance, the key defined as unique must be uniqover the entire file and not just with a subset of that file(as defined by the select/omit criteria).

Generating an Access PathYou must generate and compile the source members for yoaccess paths before you can run your application. Thefollowing steps provide you with instructions to generate youaccess path.

1. Go to the Services Menu.At the Edit Database Relationspanel, pressF17.

The Display Services Menu appears.

2. Select access paths.Type8 at the bottom of the screenand pressEnter.

The Display All Access Paths panel appears with a list oall of the access paths in your model.

3. Generate the access path.TypeJ next to each of theaccess paths you want to generate and pressEnter .

The Display All Access Paths panel reappears withmessages at the bottom of the panel that say the sourcgeneration requests have been accepted.

� Note: Selecting eitherJ for batch generation orG forinteractive generation generates your access pathHowever, selectingG has an impact on systemperformance. Generating interactively negativelyimpacts other interactive users.

4. PressF3 to return to the Services Menu panel.

� Note: An alternative to this procedure is to use options14(generate in batch) or15 (generate interactively) fromthe Edit Model Object List panel.


Implementing

� For more information:on the Edit Model Object List panel, refer toGenerating andImplementing Applications, Chapter 1, “Managing ModelObjects,” Editing Model Object Lists topic.

on the following topics, refer toGenerating and ImplementingApplications:

Generating Request Panels/Displays

Generating Access Paths

Changing Generation Mode

Verifying Results

Checking Code Generation Errors

Identifying Common Errors


s.

ioneiral

t and

cte

t

xt

u

Documenting Access Paths 8This chapter contains procedures on how to document your access pathCOOL:2E includes a number of commands to produce hard copydocumentation of your design model. For access paths, this documentatidentifies the access paths in your model and provides a complete list of thdetails. This documentation consists of COOL:2E functional text. Functiontext is entered by the designer to describe the purpose of the design objecany restrictions and notes on the reason for design decisions.

Documenting an Access PathThere are two types of narrative text allowed for each objeentry: functional text, used to describe the purpose of thdesign object; and operational text, used to describe thefunction of an object to an end user. If no operational texis available, functional text is used in the generated helppanels.

All the documentation commands have a PRTTEXTparameter that allows you to specify whether you want teto be included in the listing and, if so, which type of text.

A maximum of ten pages of text of each type can beassociated with each COOL:2E object to explain thepurpose of the object within the design.

Creating the DocumentationUse the following method to document an access path:

1. Go to the Display Services Menu.At the EditDatabase Relations panel, pressF17.

The Display Services Menu panel displays.

2. Display Documentation Menu.From the ModelDocumentation options on the Display Services Menpanel, select the option and pressEnter .

The Display Documentation Menu panel displays.


Documenting an Access Path

3. Select access paths.Select the option to document theaccess paths.

The Document Model Access Paths (YDOCMDLACP )panel displays.

4. Select type of documentation.Choose thedocumentation option you want from the following list ofchoices.

Model files

Application area code

Print text

Print access path details

Access path type

Begin new page

COOL:2E creates a print file that contains yourdocumentation.


totem

00ding

Tailoring for Performance 9When building access paths within your model, you should pay attentioncertain aspects of system design that will enable you to obtain the best sysperformance. Some issues regarding access paths could affect theperformance of your application. This chapter explains the issues for OS/4logical files and relates them to the default values for access paths. Depenon your design, you might want to consider the following topics.

● Considering the Types of Data in the Physical File

● Minimizing the Number of Active Indices

● Maintaining Access Paths (Immediate, Delay, Rebuild)

● Using Select/Omit Criteria

● Using Virtual Fields (Join Logical Files)

● Multi-format Access Paths

● Using Open Data Paths

● Creating Default Retrieval Access Paths

� For more information:on system performance considerations, refer toCOOL:Xtras Performance Expert User GuideandIBM AS/400Database Guide.


Considering the Types of Data in the Physical File

nad

chle,ing

ve

s

t bet

n

to

y.er

n

l

e

Considering the Types of Data in the Physical FileAn access path is a view of the data in a physical file, in a givekey sequence. In terms of performance, some of the overheof access paths has to do with the amount of work that theoperating system (OS/400) does to maintain those views. Eatime a record is added, deleted, or changed in the physical fior when the data in the key of a record changes, the operatsystem may have to update each COOL:2E access pathbelonging to the PHY file. Consequently, the more accesspaths you build, the more work the operating system may hato do for each record change.

For example, with non-volatile data files (master or table fileof relatively unchanging data), the number of access pathsbuilt over them is not as important as it is for the number oflogical files built over volatile files (transaction files ofconstantly changing data) because their access paths musconstantly updated. This implies that master files should nocontain a mix of master and volatile data. For example,balance-related information (volatile) should not be held in aItem Master file (non-volatile).

� For more information:on the data modeling and normalization process, referDefining a Data Model,Chapter 2, “Developing aConceptual Model.”

You can show the difference between the non-volatile andvolatile data files using REF and CPT file types respectivelThe only difference between the REF and CPT file types is thautomatic creation of an edit file and select record function foREF files.

Minimizing the Number of Active IndicesAn access path is defined with key fields specified in a giveorder and/or with dynamic or static selection maintenancespecified. Together the keys and selection maintenancespecify which records on a file are implemented as a logicafile. However, the operating system implements logical filesby automatically creating what is called an active index. Th


Minimizing the Number of Active Indices

nof

ivey

rent

tive

edoD

active index is part of the operating system's implementatioof logical files. There is a separate active index for each setkey and static selection maintenance.

Where possible, the operating system tries to share an actindex between logical files. If logical files have the same kefields and static selection maintenance, they may share anactive index. If two similar logical files (same keys) havedynamic select/omit maintenance, they may be able to shathe same active index. However, if one (or both) has differestatic select/omit maintenance, they cannot share an activeindex, and the operating system always creates separate acindices.

The Active IndexThe following example shows separate active indices.

It is important to minimize the number of active indicesbecause active indices cause extra system overhead. Activindices sharing multiple access paths in the design modelnot always equate to multiple indices. For example, the UPand RTV access paths have the same active indices.

Access Path 1Keys ABC

Access Path 2Keys AB

Access Path 3Keys A

Access Path 4Keys B

INDEX 2Key B

INDEX 1Key ABC

PhysicalFile

Separate index required for new key sequence


Access Path Maintenance (Immediate, Delay, or Rebuild)

,

n

L2

:

mta in

thto

a

Sharing Active IndicesThe following example shows a shared active index.

The compilation sequence can affect the number of activeindices required.

In the above example, if the compilation sequence is LGL1LGL2, LGL3, one active index is created. Since the keysequence for LGL2 and LGL3 are subsets of LGL1, they cashare the same active index.

If the compilation sequence is LGL3, LGL2, LGL1, threeactive indices are created because the key sequence for LGand LGL1 are not subsets of LGL3.

Access Path Maintenance (Immediate, Delay, orRebuild)

There are three types of access path maintenance optionsimmediate (IMMED), delay (DLY), and rebuild (REBLD).These options determine how the operating system applieschanges to the access paths. While a file is open, the systemaintains the access paths as changes are made to the dathe file. However, when the file is closed, the access pathmaintenance option specifies to OS/400 how the access pashould be maintained. It is important to pay close attentionaccess paths in the design stage.

● IMMED maintenance means that the active index ismaintained as changes are made to its associated datregardless of whether the file is open.

Example:

PHY LGL 1Key AKey BKey C

LGL 2Key AKey B

LGL 2Key A

Compilation Sequence:

LGL1, LGL2, LGL3LGL3, LGL2, LGL1

1 Active Index3 " "



d

is

eath

,

Nith

.se

en

o

thn.es

ns

● DLY maintenance means that any maintenance for theactive index is done after the file member is opened anwhile it remains open. Updates to the access path arecollected from the time the access path is closed until itopened again. When it is opened, only the collectedchanges are merged into the access path.

● REBLD maintenance means that the active index ismaintained only when the file is open, not when the fileis closed; the access path is rebuilt the next time the filis opened. When the file is opened again, the access pis totally rebuilt. If one or more programs has opened aspecific file member with rebuild maintenance specifiedthe system maintains the access path for that memberuntil the last user closes the file member.

The use of maintenance options applies only to RSQ and SPaccess paths. The UPD and RTV access paths are defined wa UNIQUE key; as a result, maintenance has to be IMMEDFor QRY access paths, maintenance does not apply becauthe access path is rebuilt at execution.

There are considerations with each type of maintenanceoption. When you change a file, indices with IMMEDmaintenance are updated. However, when programs that opDLY and REBLD maintenance access paths are invoked,changes are applied that then make the programs slower tload.

Use DLY maintenance with caution. If more thanapproximately 10% of the number of entries in the access paare changed, the whole index will be rebuilt at the next opeThis rebuild could occur during the use of a program that donot use that index.

If the file records are non-volatile, you can always take thedefault IMMED maintenance. If the data is likely to changefor infrequently used access paths, you may use DLY orREBLD maintenance. However, keep in mind that for eachdifferent type of maintenance, you will get a separate activeindex. Specify a REBLD access path if you already have aIMMED maintenance access path with the same set of keyand select/omit sets.



n

cee

The following is a comparison of IMMED, DLY, and REBLDmaintenance as they affect opening and processing files:

� For more information:on the access path maintenance options, refer to thismodule, Chapter 4, “Modifying Access Paths,” EditingAccess Path Details and Chapter 7, “Generating andCompiling,” Identifying the Implementation Attributes.

on the effect of the access path maintenance options operformance, refer toIBM AS/400 Database Guide.

Maintenance for Query (QRY) Access PathsFor Query (QRY) access paths, the access path maintenanoption is approximated using the OPTIMIZE parameter on thOS/400 Open Query FileOPNQRYF command. TheOPTIMIZE parameter indicates the optimization goal thesystem is to use when satisfying the QRY access pathspecifications.

Immediate Delay Rebuild

Fast open becausethe access path iscurrent.

Moderately fast openbecause the accesspath does not have tobe rebuilt, but it muststill be changed. Slowopen if extensivechanges are needed.

Slow open becauseaccess path must berebuilt.

Slowerupdate/outputoperations whenmany accesspaths withimmediatemaintenance arebuilt over changingdata (the systemmust maintain theaccess paths).

Moderately fastupdate/outputoperations whenmany access pathswith delayedmaintenance are builtover changing dataand are not open (thesystem records thechanges, but theaccess path itself isnot maintained).

Faster update/outputoperations whenmany access pathswith rebuildmaintenance arebuilt over changingdata and are notopen (the systemdoes not have tomaintain the accesspaths).


Using Select/Omit Maintenance

ss

a

o

sbyce

ss

The following table gives a brief description of eachOPTIMIZE parameter value and shows the correspondingaccess path maintenance option.

� For more information:on QRY access paths, refer to this module, Chapter 1, “AccePaths: An Introduction,” Recognizing the Basic Properties ofAccess Paths and Chapter 3, “Adding Access Paths,” AddingQuery (QRY) Access Path.

on theOPNQRYF command's OPTIMIZE parameter,refer toIBM AS/400 Control Language Reference.

Using Select/Omit MaintenanceSelect/omit maintenance filters records that match thespecified selection or omission maintenance. There are twtypes of select/omit maintenance: static and dynamic.

If the select/omit maintenance is dynamic, all records,regardless of the select/omit set, are included in the accespath. The records are filtered by the system as they are reada program. Only those that match the select/omit maintenanare actually returned to the program.

If the select/omit criteria is static, only those records thatsatisfy the select/omit maintenance are included in the accepath. As each record is added or changed, the system

OPNQRYF CommandOPTIMIZE Parameter Values

(for QRY Access Paths)

CorrespondingAccess PathMaintenance

Option

*FIRSTIO The system attempts to improvethe time required to open the fileand to retrieve the first buffer ofrecords from the file.

*IMMED

*MINWAIT The system attempts to minimizedelays when reading records fromthe file.

*DLY

*ALLIO The system attempts to improvethe total time to process the wholequery, assuming that all queryrecords are read from the file.

*REBLD


Using Join Logicals

en

ex,

e

it

,cehe

)al

he

l

eed

ly

l.

determines if it should be included in the access path. As thdata is read, no filtering is required since it has already beeperformed by the access path maintenance.

Because of this difference, any access path with staticselect/omit criteria usually has a separate internal active indwhereas any access path with dynamic select/omitmaintenance can share an active index with other similarlykeyed access paths even if the select/omit criteria differ. Thprovision and use of dynamic select/omits increases thepossibilities of sharing active indices.

� Note: For join logical files in COOL:2E, (files with virtualfields) with select/omit criteria, static select/omitmaintenance cannot be used. Use dynamic select/ommaintenance.

The type of data file is again important. For non-volatile(master or table) data files the logical files should, if possiblehave static select/omit criteria. Static select/omit maintenandoes require that an extra active index be maintained. But tfrequency of change to the data is low and thereforemaintenance does not occur often. For volatile (transactiondata files, the type of select/omit criteria depends on the actunumber of records being read and the frequency of use of tactive index.

If the active index is used infrequently or in batch, theoverhead of having dynamic select/omit criteria may beacceptable.

Using Join LogicalsA join logical file is a logical view of the physical files uponwhich it is based. It also enables data from another physicafile or a related (or joined-to) physical file to be read. The joinis performed when the records in the based-on physical arread. One or more fields in the based-on physical are matchwith fields in each joined-to physical and data from eachmatched record is read. The join logical is composed of onone record format, which contains fields from the based-onfile and the joined-to physical files. The join fields are read-only capable and cannot be updated through the join logica


Using Join Logicals

erehe

s

s

not

se

s

ng

d

An access path generates and compiles as a join logical if thare virtual field entries on the access path format entries. Tphysical file that contains the virtual fields is joined to theprimary files using the keys of the file-to-file relations toprovide the match. These relations can beOwned by , Refersto , or Extended by .

The operating system does the work. The join (matchingrecords through common fields) is implemented using amachine interface (I/O) routine to read from the joined-tophysical files. You can define join logicals that join throughseveral physical files. The maximum number of physical fileallowed in a join file definition (direct joins or chained joins)is 32. A field that is brought across more than six (or as few athree or four) chained joins actually loses the performancebenefit because it requires many I/O routines to obtain thedata. Consequently, obtaining data across several joins isrecommended.

The use of join logicals is efficient only when the data that ibeing read is actually needed. If the data is not required, thoperating system is doing unnecessary I/O to other files. Interms of internal active indices, the join logical shares theactive indices of the based-on file just as with access pathtypes.

Maintenance can be specified as IMMED, DLY, or REBLD.Only dynamic select/omit maintenance can be specified onCOOL:2E join logical files. In terms of performance, this hasome significant consequences:

● Where it may be better to have static select/omitmaintenance, you can drop the virtual field so that it cabe specified. The additional data can be retrieved usinyour own reads to the secondary file.

● The operating system reads the joined-to data beforeapplying the selection because the selection itself coulbe on a joined-to virtual field. This compounds theperformance problem particularly where there is I/O toseveral different physical files.


Using Multi-Format Access Paths

neile

e a

eiedct

th

ifs.

sut

unt

edtitith

ets

s.

Using Multi-Format Access PathsMulti-format access paths are access paths with more than orecord format. They are based on more than one physical fand can read/write to several physical files.

The multi-format can be treated as though each format werseparate access path. The use of the physical files for eachformat should collectively determine the type of maintenancfor the access path. A select/omit maintenance can be applto each format that is best suited for the physical file, the effeon performance (hit-rate), and the number of records beingread. In terms of active indices, each multi-format access pacan share an active index. However, in practice, this isunlikely. Therefore, treat each multi-format access path asit creates an extra active index over each of the physical fileCOOL:2E supports the multi-format logicals for the SPNaccess path.

Using Open Data PathsAn open data path (ODP) is the path through which allinput/output (I/O) operations for the file are performed. ODPcan be shared by more than one program in the same job bnot between jobs.

The object is to be able to share ODPs and still have theapplications work as before. Sharing the ODP reduces theamount of main memory the job needs and reduces the amoof time it takes to open and close the file.

The amount of work the operating system does can be reducby sharing the ODP among all the programs in the jobs thause it. When a file is used more than once in the same job,can be shared. Sharing an ODP should be done with care. Weach access path the position of the current record (the filecursor) is held only once on the ODP. It is possible that oneprogram accessing a file with a shared ODP can change thposition in the file inadvertently, causing unpredictable resulin other programs in the job.

Sharing an ODP is not defined as a default for access pathYou must specify share ODP on the compiler override for agiven access path.


Creating Default Retrieval Access Paths

g

is

,s

s.

ssng

Creating Default Retrieval Access PathsTo improve the performance of your application, try droppinall of thevirtual fields from the default RTV access path. Youcan use this standard with every file you implement inCOOL:2E that contains virtuals.

The idea is to create an access path that can be used forvalidation and that does not have any virtual fields. To do thuse the following steps:



2. Rename the default retrieval.Rename the default RTVaccess path for your file to the name Validation View.

3. Create a new RTV access pathif you require one whichcontains virtuals.

4. Rename.Name the new RTV access path RetrievalIndex.

5. Use the new RTV.Base any functions for the file overthe new RTV access path that requires those virtual field

6. Create the validation viewwith a compiler override ofSHARE (*YES).

� For more information:on compiler overrides, refer toGenerating andImplementing Applications, Chapter 4, “Generating andCompiling Your Application.”

COOL:2E uses the default RTV Index Validation View for allfile validations. This view also uses the index to determinewhich fields in the file can be virtualized. The fields availablefor virtualization will default to only those fields present in thefile itself. Although it is not generally a good performancetechnique, you can virtualize fields that are themselvesvirtualized. You can do this by adjusting the referenced accepath of the relation to point to an untrimmed access path usithe Edit Access Path Relations panel.


Creating Default Retrieval Access Paths


Index

Symbols*ARRAYS 6-3*DSNR User type6-3

Aaccess path1-1

adding3-1associated1-7auxiliaries1-9, 4-33, 4-34characteristics1-7default retrieval9-1, 9-11deleting5-1details1-8documenting8-1editing 4-7, 4-9entry 4-17format 4-17format entries4-16, 4-17format keys4-16format text4-16generating7-3holding 4-2, 4-22maintenance4-9, 4-10, 9-4modifying 4-1multi-format 9-1, 9-10naming1-7performance9-1physical (PHY)1-2, 3-3, 3-4query (QRY)1-5, 3-3, 3-5, 4-7, 4-11,

4-33, 7-2, 9-6referenced4-30relations4-20, 4-24required relations4-20resequence (RSQ)1-4, 3-3, 3-5retrieval (RTV)1-3, 3-3span (SPN)1-6, 3-3, 3-6tailoring 4-27trimming 4-4types1-2, 4-12update (UPD)1-3, 3-3

usages5-3virtual field 4-4, 4-23

active indices9-1, 9-2minimizing number9-2sharing9-3

adding3-1access paths3-4based-on access paths4-31query access paths3-5resequence access paths3-5span access paths3-6

allocating names2-1, 2-3alternate collating sequence4-9, 4-11alternating collating table4-12ANDed 4-27array6-1

*CVTVAR function 6-2as data structure6-2changing names6-6Closedown Programs6-3COBOL arrays6-3deleting6-7details6-6editing 6-6ELM context field6-2field definitions 6-6field details6-4key details6-4key order6-6sample6-4

assimilated files4-18assimilated physical files4-18associated access path4-31auxiliaries1-9

Bbased-on access path4-31basic properties1-2built-in functions

convert variable6-2

Building Access Paths Index-1

C to F

Cchanging

array name6-6key sequence4-16referenced access path4-30

CHGOBJ6-2CL program3-6COBOL arrays6-3compilation

overview7-1compiler overrides2-7, 7-2

changing2-7components1-8context

ELM (array element)6-2Copy Model Objects (YCPYMDLOBJ)

SQL access path4-14Create Logical File2-7Create Object6-2Create Physical File2-7Create Table4-12CRTLF 2-7CRTOBJ6-2CRTPF OS/400 command2-7CRTTBL 4-12

Ddata area4-5data definition language4-13database file generation2-5DDS 1-10, 2-5, 3-5, 4-7, 4-13, 4-33,

7-1, 7-2*Unique keyword4-7implementation attributes7-2joins 4-13

defaultaccess paths3-1model values2-1options2-1retrieval access paths9-1, 9-11

definingarray 6-1

delayDLY 9-4

delay maintenance4-7delete

access path5-1array6-7confirmation5-2

designer user type (*DSNR)6-3arrays6-1, 6-2

device design4-3Display Documentation Menu8-1Display Services Menu7-3, 8-1displaying references4-5distributed flag4-6DLTOBJ 6-2DLY 9-4documentation

access paths8-1functional text8-1operational text8-1type 8-2

Documentation Model Access Pathspanel8-2

DRDA 4-6distributed flag4-6

duplicate sequence4-10options4-10

dynamic selection9-7

EEdit File Details panel3-2editing

access path auxiliaries4-34access path details4-9arrays6-6format entries4-17physical file format entries4-18

ELM context 6-2entry 4-17Extended by relation4-24

FF4 prompt

function 4-30FCFO 4-10, 7-2FIFO 4-10, 7-2

Index-2 Building Access Paths

G to M

file and access path relations4-24file-to-file relation 4-20format 4-17format entries1-8, 4-17format keys4-16format text4-16function references6-6functional text8-1

Ggeneration7-1, 7-3

objects2-1, 7-1generation mode2-5, 4-9, 4-13

changing2-6DDS 4-13options4-13SQL 4-13

generation options7-1

Hheld access paths4-21hidden fields4-3, 4-21high level language (HLL)

source code7-1HLL

high level language (HLL)7-1holding 4-2

II/O 4-27, 9-9, 9-10IBMsarchitecturalframework'4-6identifying 1-2

format keys4-16format text4-16

immediate maintenance4-7implementation attributes7-2

SQL-generated RSQ7-3table 4-9

input fields4-3input/output4-27, 9-10item master file9-2

Jjoin logicals9-1, 9-8

Kkey sequence3-5, 4-16Known by relation4-20

LLIFO 4-10, 7-2locks

permanent4-5temporary4-5

Mmaintenance9-1, 9-4

dynamic9-7select/omit9-7static 9-7

maintenance options4-11, 7-2, 9-4D, delay4-11I, immediate4-11R, rebuild4-11

master files9-2MDLVAL 2-6minimizing number

active indices9-2model values2-1, 4-1, 4-13

changing2-3last used file prefix (YFILPFX)2-1YALCVNM 2-1YDBFGEN 2-2YFILPFX 2-1YOBJPFX 2-1YSQLLIB 2-2

modifying 4-1access path auxiliaries4-33access path details4-7access path format entries4-16access path relations4-20access paths4-1virtual field entries4-23

multi-format 9-1, 9-10


N to T

Nnaming1-7narrative text1-9non-volatile9-2

Oobjects

prefixes2-1ODP 9-1, 9-10

sharing9-10omit set4-27open data path (ODP)9-1, 9-10Open Query File (OPNQRYF)3-6, 4-8,

4-11, 4-33, 7-2, 9-6operational text8-1ORed4-27OS/400 access path4-10OS/400 index7-1Owned by relation4-20

Pparameters2-5, 2-7

PRTTEXT 8-1SQLLIB 2-5

performance considerationsaccess paths9-1

permanent locks4-5PHY (physical) access path1-2, 3-3, 3-4physical file

format entries4-18types of data9-2

programmer user type (*PGMR)arrays6-1, 6-2

QQCASE2564-12QRY (query) access path1-5, 3-3, 3-5,

3-6, 4-7, 4-11, 4-33, 7-2, 9-6adding3-5auxiliaries2-4

QSYSTRNTBL 4-12Qualified by relation4-20query (QRY) access path2-4, 4-7, 4-11,

4-33, 7-2, 9-6

Rrebuild maintenance4-7, 9-4referenced access path4-30Refers to relation4-20relation1-8, 4-20, 9-9

file-to-file 4-20required relations4-20RSQ (resequence) access path1-4, 3-3,

3-5, 7-3adding3-5

RTV (retrieval) access path1-3, 3-3RTVOBJ 6-2

Sselect/omit4-27, 9-1, 9-7

criteria 4-9, 4-12, 4-27dynamic4-12maintenance9-7sets4-28static 4-12

Services MenuDisplay Services Menu8-1

sharing active indices9-3source generation type2-2source member name2-3, 4-9source member text4-9SPN (span) access path1-6, 3-3, 3-6

adding3-6SQL 1-10, 2-5, 4-13, 7-1, 7-2, 7-3

access path7-3copying4-14creating an environment2-5environment2-5implementation7-2joins 4-13resequence (RSQ) access path7-3SQLLIB model value2-2

static selection9-7Synon/2E index7-1

Ttable files9-2

Index-4 Building Access Paths

U to Y

-

tailoring for performance4-27, 9-1tailoring virtual fields4-27temporary locks4-5translate table4-12type of maintenance4-10types of access paths1-2

physical1-2, 3-3query1-5, 3-3resequence1-4, 3-3retrieval1-3, 3-3span1-6, 3-3update1-3, 3-3

types of data9-1, 9-2

Uunique/duplicate key sequence4-9, 4-10

options4-10UPD (update) access path1-3, 3-3UPD (update) physical path1-3upper/lower case discrepancies4-12usages4-5, 5-3

impact analysis5-3user-added text1-9

Vvirtual fields 4-4, 4-23, 4-27, 9-1

auto add to access path4-2entries4-23

volatile 9-2

YYALCVNM (Allocate Name) model

value2-1YCHGMDLVAL (Change Model Val-

ue) 2-3YCPYMDLOBJ (Copy Model Object)

SQL access path4-14YCRTMDLLIB (Create Model Library)

2-5YCRTSQLLIB (Create SQL Library)

2-5YDBFGEN (Database Generation) mod

el value2-2, 2-5YFILPFX (last used file prefix) model

value2-1YOBJPFX (Object Prefix)2-1YSQLLIB (SQL Library) model value

2-2


Documents

Building Access Path