synon training material

TATA CONSULTANCY SERVICES COOL:2E Training 1

AS/400 Group

NOIDA


COOL:2E Training

Contents• Introduction to COOL:2E

• Getting Started

• Data Modeling

• Building Access Paths

• Building Applications

• Generating Applications

• COOL:2E/1E Utilities


Introduction to COOL:2EWhat is COOL:2E?

» An application development tool» Allows efficient design, development, implementation

& maintenance of application software» Better than third generation development methods» Knowledge of programming language not required» Platform independent application design


Introduction to COOL:2ECOOL:2E Objectives

» Design closer to user requirements» Higher quality applications» Ease of maintenance and enhancement» Language independent design» Applications that make effective use of platform» Increased Productivity


Implementation independence» Application design developed as high level business

logic and design» Applications stored as COOL:2E design model» Same application design can generate application to

run on AS/400, IBM mainframes, RS/6000

Introduction to COOL:2ECOOL:2E Design Principles


Data-driven Design» Application design starts with the identification of

business entities and their relationship» Entity-Relationship modeling is used to create the

COOL:2E data model» Functions for the end user are subsequently built on

the data model

Introduction to COOL:2ECOOL:2E Design Principles (contd..)


Object-based Design» Objects are database entities» Actions are COOL:2E functions» Actions and Objects are defined once and reused.

Introduction to COOL:2ECOOL:2E Design Principles (contd..)


COOL:2E Rapid Prototyping Methodology (RPM) is a data-driven, pragmatic approach to Application Development

Rapid Prototyping Methodology» Analyze

– System analysis, E-R diagram, COOL:2E Data model, Primary access paths, function flows and device designs

Introduction to COOL:2EApplication Development


Rapid Prototyping Methodology (contd...)» Design

– Prototype application, review with user, update design, continue functions definition, action diagrams, complete database design

» Construct– Generate final version of application and complete unit testing

» Implement– Complete integration test, system test and user acceptance test

Introduction to COOL:2EApplication Development


» Change design model as necessary» Update the function design for above changes» Regenerate dependant elements

Introduction to COOL:2EApplication Maintenance


» COOL:2EApplication development tool for AS/400

Includes COOL:2E/1E

» COOL:2E/2GProvides PC based GUI for COOL:2E

» COOL:2E/CSG (Client Server Generator)Option to COOL:2E which allows distributed functionality on

multiple platforms

Introduction to COOL:2ECOOL:2E Products


» Entity Relationship Specification– Automatic creation of a data dictionary– Free format text to describe any design object– Automatic documentation of the design model– Specification of domain checks

» Access Paths– Logical views to support functions– Retrieval of existing DB2/400 descriptions (assimilation)

Introduction to COOL:2ECOOL:2E Features


» Functions– Auto creation of action diagram & panel/report design– Modular design

» Panels & Reports– Automatic design of panel & report layouts– Interactive painting facilities– Panel design prototyping facilities

Introduction to COOL:2ECOOL:2E Features (contd…)


» HLL code generation– DDS or SQL for database– DDS for panels & reports– RPG/COBOL for AS/400 stand alone programs– RPG/COBOL for server and COBOL/2 for client– Automatic help text generation



» Other features– Automatic implementation of object naming standards– Automatic implementation of panel design standards– Automated documentation of generated systems– Cross reference facilities– Integration of user source code in generated functions– Regeneration of source code after changes in design– Facilities for commitment control, journalling & error handling– Automatic referential integrity & domain checks



Contain the files and objects needed to use COOL:2E products» Y1SY COOL:2E/1E Products» Y1SYVENG COOL:2E/1E National Language Library» Y2SY COOL:2E Base products» Y2SYVENG COOL:2E National Language Library» Y2SYMDL COOL:2E null model» Y2SYCBL COOL:2E COBOL generators» Y2SYRPG COOL:2E RPG generators» Y2SYSRC COOL:2E source

Getting StartedCOOL:2E Product Libraries


It is the model in which the development team creates an application and in which initial generation takes place.

Objects are tested in the development environment.

Getting StartedDevelopment Environment


Model Library» Library in which the model resides

Generation Library» Associated with each model library» Contains source files, compiled programs, help text,

access paths (created using DDS) and journals SQL Collection

» Exists only if SQL is used for data definition» Contains files, journals, data dictionaries & SQL access

paths

Getting StartedDevelopment Libraries


YCRTMDLLIB command creates a modelYCRTMDLLIB Command Parameters» Model Library Name (MDLLIB)» Generation Library Name (GENLIB)» Design Standard (DSNSTD) like *CUATEXT etc.» File generation method : DDS/SQL» SQL Collection Library (SQLLIB)» Naming Prefixes

– Object Prefix (OBJPFX)– Message Prefix (MSGPFX)

Getting StartedCreating/Using a Model


YCRTMDLLIB Command Parameters (contd…)» Message File Name (MSGVNM)» Default HLL (HLLGEN)» HLL Naming Convention (HLLVNM)

Build Library List using YBLDLIBLST» Change job’s library list to contain COOL:2E

Development Libraries and Product Libraries» Run command YBLDLIBLST <LIBL-Name>

Getting StartedCreating/Using a Model (contd…)


Run command YSTRY2 <LIBL-Name> to display COOL:2E Master Menu

User can Enter/update the COOL:2E/2 model as Designer(*DSNR) or as a Programmer (*PGMR)



MAIN COOL:2E Master menu Level . : 1 System: S1017323 Select one of the following: DESIGN-MODEL 1. Enter/update COOL:2E model as *DSNR. 2. Enter/update COOL:2E model as *PGMR. ? 3. Change current data model. Other menus 4. COOL:2E commands in alphabetical order. 5. Commands to set up or alter a model. 6. Commands to copy a model. 7. Commands to create an application. 8. Commands to document a model. 9. COOL:2E/1 Programmer aids. + Selection or command ===> F3=Exit F6=Messages F9=Prev. request F10=Cmd Entry F14=Submitted jobs



• A Data Model is a structured description of a set of data and its relationships which can be used to represent the business of an organization

• Entity-Relation (E-R) modeling techniques are used to build a conceptual data model

• Conceptual data model is then entered in the COOL:2E/2 to build COOL:2E/2 data model

Data ModelingWhat is a Data Model?


Data ModelingEntity-Relationship (E-R) Modeling

• Identify Primary Entities and their attributes• Identify Relations between Entities and

between Entities and the Attributes• Normalize the Data Model



Identifying Primary Entities» Review the data items from the analysis of business

information» Select objects that are important to the business e.g.

entities important to end users» Select objects about which information must be stored» Identify the business dimensions» Generalize or differentiate Entities



Identifying Primary Entities - example» Sales Order Entry form of ABC Inc. is shown below

ABC Inc. Customer Copy Customer Code: Name: Phone: Address: Order No.: Date: Product Code Description Qty Price Total

________ ____________ ____ ____ ___ ________ ____________ ____ ____ ___

» The following primary entities can be identifieda) Company b) Customer c) Order d) Product



Identifying Primary Entities - example» Further study of business of ABC Inc. revealed that products

are purchased from vendors for which purchase orders are generated. Therefore the following additional entities were identified

a) Vendor b) Purchase Order

Generalize Entities» Combine two entities representing different types of the same

thing into one entity

Differentiate Entities» Differentiate different types of the same thing as two different

entities



Identifying Entity Attributes» Identify informational details of an entity» Each informational detail of an entity can form the

attribute of the entity» Example - Customer has the following attributes

Customer CodeCustomer NameCustomer Address

» Identify Domains which are the possible values of the identified attributes



Identifying Relations» Identify relations between Entity and its attributes and

between different Entities» Categorize relationship types by

– Optional/Mandatory– Cardinality– Involution

» Select Primary Key or Unique Identifier for an Entity



Identifying Relations» Optional/Mandatory - Is the relationship Mandatory

or Optional?» Cardinality - Is the connection one-to-one, one-to-

many or many-to-many?Number of entity instances for a relationship

» Involution - Does the connection exist between two different entities or from the same entity to itself?

e.g. relation between employee and a manager when manager himself is an employee.



Identifying Relations» One-To-One Relation - each instance of one entity is

related to one instance of another entity assigned to

e.g. Salesperson Territoryhas

» One-To-Many Relation - One instance of an entity is related to multiple instances of another entity

placese.g. Customer Order

placed by



Identifying Relations» Many-To-Many Relation - each instance of one entity

is related to more than one instance of another entity and vice versa

orderse.g. Order Product

ordered by



Identifying Relations» Select Primary Key or Unique Identifier

Primary Key - An attribute or group of attributes assigned to an entity to uniquely identify an instance of the entity e.g. Customer

K Customer CodeCustomer NameCustomer Address

Primary Key can be a single attribute, a relationship or a combination of attributes and relationships



Identifying Relations» Implement Entity to Entity Relationship using

Foreign KeyForeign Key - An attribute or group of attributes of an entity

which connects this instance with an instance of another entity

The primary key of one entity when used in another entity is called a Foreign key



Identifying Relations - Foreign Keyexample: One-To-One relation

assigned to

Salesperson Territory has

K Person ID K Person ID Person Name Territory Name

example: One-To-Many relationhas

Company Division Part of

K Company Code K Company Code Company Name Division Code

Division Name



Identifying Relations - Foreign Keyexample: Many-To-Many relation

worked on by

Project Employee works on

worked on by has

Project Project Team Employeeworks on part of

Project EmployeeK Project Code K Employee Code

Project Name Employee NameProject Team

K Project Code K Employee Code


Data ModelingNormalizing the Data Model

Normalization Involves» regrouping attributes» splitting entities» reassigning primary keys

Functionally Dependent Attribute» for each value of the key, there is only one value of

non-key attributeFull Functional Dependent Attribute

» non-key attributes are dependent on all the key attributes of a composite key


Data ModelingNormalizing the Data Model

Process of Normalization» Creating First Normal Form (1NF)

– eliminate repeating data groups– e.g. Order splits into Order Header & Order Detail

» Creating Second Normal Form (2NF)– entity is 1NF– every non-key attribute is fully functionally dependent on primary

key» Creating Third Normal Form (3NF)

– entity is 2NF– each non-key attribute is not dependent on another non-key

attribute


Data ModelingCOOL:2E Data Model

COOL:2E Objects (design elements)» File

– represents an entity e.g. Order» Field

– describes an item of data e.g. Order Number» Condition

– describes the values or set of values (domains)» Relation

– describes connection between two files or between file and field e.g. refers to, owned by



Conceptual Model COOL:2E Data(E-R Model) Model

---------------------------------------------------------------Entity FileAttribute FieldRelationship RelationDomain Field Conditions:

Reference field types



• COOL:2E provides facilities to enter / update the data model

• Model can be accessed as designer (*DSNR) or as programmer (*PGMR)

• Edit Database Relations panel allows the entry of data model to COOL:2E


*DSNR GXMMDL Op: SYNGXM QPADEV0004 21/08/97 17:46:35 EDIT DATABASE RELATIONS GXMMDL => ___ _________________________ Rel lvl: ___ ___ ___ _______________________

? Typ Object Relation Seq Typ Referenced object __ _________________________ ____________ ___ _______________________

__ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________ __ _________________________ ____________ ___ _______________________

+SEL: Z(n)-Details, N(n)-Narr, S(n)-Select, E(n)-Entries, V-Virt.fields, F-Funcs F3=Exit F5=Reload F7=Fields F9=Insert F10=Define obj. F17=Services




COOL:2E Files» Each COOL:2E File has a Name and a File Type» COOL:2E File Naming rules

– must be valid COOL:2E Name– unique within the model– up to 25 characters including embedded blanks– e.g. Purchase Order is a valid COOL:2E file Name

» COOL:2E File TypesFile Attribute Description ExampleDatabase CPT Capture file Order Entry

REF Reference file Company fileNondatabase STR Structure file Audit date & time

stamp



COOL:2E Files» Reference (REF) files

– master files that typically contain non-volatile information– e.g. Customer, Product, Area Code

» Capture (CPT) files– contain transactional data that is recorded regularly– e.g. Order, Ledger Entry

» Structure (STR) files– contain group of fields which can be included in other files

using Includes relation– e.g. Audit Stamp file



COOL:2E Files» Default functions

– standard functions are automatically defined for files– default functions depend on file types

» Default functions for REF files

Function Access PathCRTOBJ - Create Object UPDDLTOBJ - Delete Object UPDCHGOBJ - Change Object UPDSELRCD - Select Record RTVEDTFIL - Edit File RTV



COOL:2E Files» Default functions for CPT files

Function Access PathCRTOBJ - Create Object UPDDLTOBJ - Delete Object UPDCHGOBJ - Change Object UPD



COOL:2E Files» Creating/Defining

– At the Edit Database Relations panel, press F10 to show Define Objects panel

– In the Object type column, enter FIL– Type File Name in Object Name column– Type CPT or REF or STR in Object attr column depending

on the file type– Defined as relation for the file is automatically created



Op: SYNGXM QPADEV0004 22/08/97 15:31:12 DEFINE OBJECTS GXMMDL Object Object Object Referenced Field Edit type name attr field usage field ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ ___ ________________________ ___ ________________________ ___ _ + F3=Exit



COOL:2E Fields» Each COOL:2E Field has a Name and a Field Type» COOL:2E Field Naming rules

– unique within the model– up to 25 characters including embedded blanks– e.g. Customer Code is a valid COOL:2E Field Name– implementation name is different

» COOL:2E Field Types– depends on the type of values – broadly classified as alphanumeric, numeric & special field

types



COOL:2E Fields» COOL:2E Field Types (contd…)

Field Type Name Description Type Length ExampleCDE Code A 6 Stock CodeDTE Date P 7,0 Date of birthIGC Idegraphic text A 20 Kanji nameNAR Narrative text A 30 CommentsNBR Number P 5.0 # of employeesPCT Percentage P 5.2 Profit marginPRC Price or tariff P 7.2 Unit PriceQTY Quantity P 5.0 Stock quantityREF Reference - - Field based on

anotherSGT Surrogate P 7.0 System KeySTS Status A 1 Yes/NoTME Time P 6.0 Change TimeTXT Descriptive name A 25 Product nameVAL Monetary value P 11.2 Stock valueVNM Valid system name A 10 File name



COOL:2E Fields» Field Attribute Values

– Basic attributes: length, implementation name– Text: Left Hand Side (LHS) text, Right Hand Side (RHS)

Text, Column Headings– Validation attributes: upper/lower case checking, Modulus

checking, valid name checking, validation through a check condition



COOL:2E Fields» Field Usage

– Two types: Database fields and Function fields» Database fields

– Code (CDE) fields:- used for key fields e.g. Company Code– Data attribute (ATR) fields: used for non-key fields e.g.

Company Name» Function fields

– fields used only in functions but do not reside in database



COOL:2E Fields» Function fields (contd…)

– fields used only in functions but do not reside in database– fields can be added to data dictionary and accessed in

device designs and action diagrams– 6 function field usage types

CNT (count) DRV (derived)MAX (maximum) MIN (minimum)SUM (sum) USR (user-defined)



COOL:2E Fields» Default Condition

– supplies the default value for a field– *NONE: no default condition– condition name: COOL:2E condition supplies default value– *DTAARA: Default field value is retrieved from data area

specified for the Dataarea field» Defining Field as a Data Area

– specify *DTAARA as default condition



COOL:2E Fields» Creating/Defining

– In the Object type column of Define Objects panel, enter FLD

– Type Field Name in Object Name column– Type COOL:2E field type in the Object attr column– Type Referenced field if the field refers to another field for

domain– In the Field Usage column, type CDE (Code) or ATR

(attribute) or a function field usage


Op: SYNGXM QPADEV0004 22/08/97 15:31:12 DEFINE OBJECTS GXMMDL Object Object Object Referenced Field Edit type name attr field usage field FIL Dealer FIL Dealer group FLD Dealer Code CDE FLD Dealer name ATR FLD Dealer Address 1 ATR FLD Dealer Address 2 ATR FLD Dealer Group Code CDE FLD Dealer Group Name ATR FLD Dealer Group Credit Limit ATR + F3=Exit




COOL:2E Condition» Specifies the values or set of values a field may take» Condition has a Name, a type and an associated

value» Condition Types

– VAL (Value) and LST (Value List) are valid condition types for status fields

– CMP (Compare) and RNG (Range) are valid condition types for non-status fields



COOL:2E Condition» Value (VAL) Condition

– used to specify single values that status field can take– two related values:

internal value - value in the implemented databaseexternal value - value displayed/entered on the screen

– e.g. Premium paid condition has file value “Y”» List (LST) Condition

– used to specify list of values that status field can take– screen functions implement prompt key (F4)– e.g. Invoice Flag can have valid values U, D, P, H, C and the

condition Invoice not due has file value “U”



COOL:2E Condition» Compare (CMP) Condition

– defined in terms of a fixed value and an operator– valid operators: *EQ, *NE, *GT, *LT, *GE, *LE– e.g. Order Quantity field can have an associated condition by

name greater than 10 with operator *GT and value 10» Range (RNG) Condition

– defines range of values that field can take– defined in terms of From and To values– e.g. Stock Quantity field can have an associated condition by

name between 10 and 100 with From value as 10 and To value as 100



COOL:2E Relation» Expresses association between two files or between a file

and a field» Eight relation types

Defined as, Extended by, Has, Includes, Known by, Owned by, Qualified by and Refers to

» 3 different relation usage groupsDefinition relations - declare files to existKey relations - define the keys in filesAttribute relations - declare non-key fields in files

» Database relations can be entered using Edit Database Relations panel



COOL:2E Relation

Usage Type Relation Used forDefinition Defined as File-to-file relationshipKey Owned by File-to-file relationship

Known by File-to-field relationshipQualified by File-to-field relationship

Attribute Refers to File-to-file relationshipIncludes File-to-field relationshipHas File-to-field relationship

Other Extended by File-to-file relationship



COOL:2E Relation» Defined as Relation

– File-to-file relation– declares that a file exists– e.g.

Product Defined as Product

– Defined as relation is automatically created for a file if a reference is made to a non-existing file



COOL:2E Relation» Owned by Relation

– File-to-file relation– denotes a parent-child relationship– primary key(s) of owning file become part of primary key of

the owned by file– keys of owning file are incorporated as high order keys in

the owned file– e.g.

Order Detail Owned by Order



COOL:2E Relation» Known by Relation

– File-to-field relation– specifies the key field(s) for a file– e.g.

FIL Order Known by FLD Order Number FIL Order Has FLD Quantity

» Qualified by Relation– File-to-field relation– to qualify a file identifier by one or more variable factors like

date, time, sequence number etc



COOL:2E Relation» Qualified by Relation

– used for entities which represent continuum of values like currency rates having effective date

– appropriate fields of referring file can be redirected (RDR) to the effective field in referred file with a possibility of specifying *PREVIOUS or *NEXT

– field in the relation must be ATR and not CDE– e.g. Product Price Owned by Product Code

Product Price Qualified by Effective date Product Price Has Product price



COOL:2E Relation» Refers to Relation

– File-to-file relation– specifies that a file refers to another file– Allows access to any of the fields on the referred to file from a

referring file– Primary key of the referred file becomes foreign key in the

referring file– Virtual field is created in the referring file and cannot be

updated from the referring file– e.g. Order Detail Refers to Product



COOL:2E Relation» Includes Relation

– File-to-file relation– file includes all the fields of a structure (STR) file– e.g. Product Includes Audit Stamp

» Has Relation– File-to-field relation– declares a field to be present in a file as an attribute– e.g.

FIL Order Has FLD Quantity



COOL:2E Relation» Extended by Relation

– File-to-file relation– declares a file to be extension of another file– If used with Owned by relation, the fields of the extended file

are available as Virtual Fields in the file being extended– It is recommended to use Extended by relation along with

Owned by relation– e.g. Customer Extended by Customer Detail



COOL:2E Relation» For Text

– For Text clause can be added to a relation to further clarify the description of a relationship

– If a file refers to another file more than once, For Text clause can be used for further clarification

– e.g. Order Refers to Customer

For: Ordering Sharing: *ALL Order Refers to Customer

For: Invoicing Sharing: *ALL



COOL:2E Relation» Creating/Defining

– At the Object column of Edit Database Relations panel, enter the file name

– Type the relationship in Relation column– Type the referenced object (File or Field) in the Referenced

Object column» Edit File Entries

– Type E in front of any relation to display Edit File Entries panel


*DSNR GXMMDL Op: SYNGXM QPADEV0004 22/08/97 15:25:26 EDIT DATABASE RELATIONS GXMMDL => Rel lvl: ? Typ Object Relation Seq Typ Referenced object FIL Dealer Owned by FIL Dealer group FIL Dealer Known by FLD Dealer Code FIL Dealer Has FLD Dealer name FIL Dealer Has FLD Dealer Address 1 FIL Dealer Has FLD Dealer Address 2 FIL Dealer Group Known by FLD Dealer Group Code FIL Dealer Group Has FLD Dealer Group Name FIL Dealer Group Has FLD Dealer Group Credit Limit + SEL: Z(n)-Details, N(n)-Narr, S(n)-Select, E(n)-Entries, V-Virt.fields, F-Funcs F3=Exit F5=Reload F7=Fields F9=Insert F10=Define obj. F17=Services 'Dealer' type FIL not found.



Op: SYNGXM QPADEV0004 22/08/97 16:11:55 EDIT FILE ENTRIES GXMMDL File . . . . . . : Dealer ? Field Type Ocr Et Ksq GEN name Length Renamed Dealer Group Code CDE K 1 AICD 6 Dealer Code CDE K 2 AHCD 6 Dealer name TXT A AJTX 25 Dealer Address 1 TXT A AKTX 25 Dealer Address 2 TXT A ALTX 25 SEL: Z-Details, R-Replace field, U-Usage, M-Mapped field parameters. F3=Exit




COOL:2E Relation» Edit Field Details

– Type E2 in front of the File-field relation to display Edit Field Details panel for the field OR

– Type Z in front of the field entry in the Edit File Details panel


Op: SYNGXM QPADEV0004 22/08/97 16:11:55 EDIT FIELD DETAILS GXMMDL Field name . . . . . : Booking payment status Document’n seq . : Type . . . . . . . . : STS REF: Payment Status Field usage . : ATR Internal length. . . : 1 Data type : A lowercase: GEN name . : BKST

K’bd shift :

Headings . . . . . . : - Text . . . . . . . . : Booking payment status Left hand side . . . : Booking payment status Right hand side. . . : Value Column headings. . . : Booking

: payment : status

Validation . . . . . : - Default condition. . : *NONE Check condition. . . : *NONE Mandatory fill . . . : (Y, ) Valid System name. . : (Y,’ ‘) Translate cnd vlues : Blank (Y,’ ‘)

F3=Exit no update F8=Change name/type F9=Conditions F20=Narrative




COOL:2E Relation» Edit Field Condition

– Field condition can be added/modified using the Edit Field Condition and Edit Field Condition Detail panels

– Press F9 on the Edit Field Details panel to display Edit Field Condition panel

– In the Edit Field Condition panel, type condition name and condition type (VAL, LST, CMP, or RNG) and press Enter to display Edit Field Condition Details panel

– In the Edit Field Condition Details panel, type the appropriate condition details like value, range etc.


Op: SYNGXM QPADEV0004 22/08/97 16:11:55 EDIT FIELD CONDITION DETAILS GXMMDL Field name . . . . . : Credit status Attr: STS Mode: *ADD Length of file . . . : 1 on display. . : 4

Condition. . . . . . : Blue chip Type . . . . . . . . : VAL

File value Display value Status value A A1

F3=Exit F8=Change name F20=Narrative



Building Access PathsIntroduction

» COOL:2E creates default access paths (PHY, RTV & UPD) when a file is defined

» Additional access paths may be created» COOL:2E access paths are implemented as one or

more objects» Access path defines a physical file or the logical view

of that file» Access path can be used to define order, column

selection & record selection


Six types of Access Paths» Physical (PHY) » Update (UPD)» Retrieval (RTV)» Resequence (RSQ)» Query (QRY)» Span (SPN)

Building Access PathsIntroduction


Building Access PathsPhysical (PHY) Access Path

• Single format file containing fields derived from resolution of all relations on the file.» Not keyed» No virtual fields» Created automatically for every REF/CPT file» Not referenced directly by functions» No additional PHY access paths allowed for a file» Created if a PF is retrieved through assimilation


Building Access PathsUpdate (UPD) Access Path

• Uniquely keyed, single format access path which is used by functions for updation» Keyed on the fields that identify the file» No Virtual fields» Created automatically for every REF/CPT file» Additional UPD access paths may be created with the

same key but subset of fields


Building Access PathsRetrieval (RTV) Access Path

• Uniquely keyed, single format access path used by functions to retrieve records» Keyed exactly as the UPD access path» Allows virtual fields» Created automatically for every REF/CPT file» Associated with the UPD access path» Non-key fields can be dropped» Can select/omit records» Possible to define multiple RTV access paths for a given file, but

all should have same key fields


Building Access PathsResequence (RSQ) Access Path

• Uniquely or non-uniquely keyed single format access path used by functions to retrieve records» Must be created explicitly» Defaults to the keys of the based on file» Allows default keys to be changed which need not be

unique» Allows virtual fields» Associated with RTV, which points to a UPD» Many RSQ access paths possible for single file


Building Access PathsQuery (QRY) Access Path

• Keyed single format access path used by functions to retrieve records» Must be created explicitly» Allows virtual fields on key & non-key fields» Available only for Print Object/Print File functions» Defaults to the keys of the based on file» Allows default keys to be changed» Associated with RTV, which points to a UPD» Many QRY access paths possible for single file» Implemented by OPNQRYF or Dynamic SQL


Building Access PathsSpan (SPN) Access Path

• Keyed multi-format access path• Used by Edit & Display transaction functions to

retrieve records from a pair of related files» Must be created explicitly» Defaults to keys of based on files» These keys can be changed» Allows virtual fields» Associated with RTV, which points to a UPD» Many SPN access paths possible for single file


Building Access PathsAccess Path Summary

# AccessPath Type

RealFields

Key Fields VirtualFields

Virtual Keys

1. PHY x x x

2. UPD Relation x x

3. RTV Relation x

4. RSQ User x

5. QRY User

6. SPN User x


Building Access PathsAdding an Access Path

*DSNR SYNGXMMDL Op: SYNGXM QPADEV0007 11/02/98 12:02:11 EDIT DATABASE RELATIONS SYNGXMMDL

=> Rel lvl:

? Typ Object Relation Seq Typ Referenced object

FIL Customer Known by FLD Customer Code

FIL Customer Has FLD Customer Name

FIL Customer Has FLD Customer Address 1



FIL Customer Has FLD Customer Credit Limit

FIL Customer Has FLD Customer Limit Used

FIL Inventory Known by FLD Item Code

FIL Inventory Has FLD Item Name

FIL Inventory Has FLD Item Quantity

FIL Sales Order Header Known by FLD Sales Order Number

FIL Sales Order Header Refers to FIL Customer

FIL Sales Order Header Has FLD Sales Order Date

FIL Sales Order Header Has FLD Shipment Date

FIL Sales Order Lines Owned by FIL Sales Order Header

+

SEL: Z(n)-Details, N(n)-Narr, S(n)-Select, E(n)-Entries, V-Virt.fields, F-Funcs

F3=Exit F5=Reload F7=Fields F9=Insert F10=Define obj. F17=Services



» Type Z against any relation on the Edit Database Relations panel for the file and press Enter

» On the resulting Edit File Details panel, enter Access Path name and type and press Enter

» Type Z to zoom into the new access path and specify details on the Edit Access Path Details panel

» Type Z on the Edit Access Path Details panel to go to Edit Access Path Format Entries panel


Op: SYNGXM QPADEV0007 11/02/98 12:10:57 EDIT FILE DETAILS SYNGXMMDL

File name . . . . . . . . : Customer

Attribute . . . . . . . . : REF Field reference file. : *NONE

Documentation sequence. . : Source library. . . . : SYNGXMGEN

GEN format prefix . . . . : AB Distributed . . . . . : N (Y,N)

Assimilated physical. . . :

Record not found message. : Customer NF Msgid. : USR0001

Record exists message . . : Customer EX Msgid. : USR0002

? Typ Access path Source mbr Key Maint Held

PHY Physical file UUABREP NONE

UPD Update index UUABREL1 UNIQUE IMMED

RTV Retrieval index UUABREL0 UNIQUE IMMED

RSQ Customer by Name

SEL: Z-Details, G/J-Generate, E-STRSEU, D-Delete, N-Narrative,

H-Hold/Release, O-Overrides, U-Usage, F-Function refs., L-Locks.

F3=Exit F5=Reload F7=Functions F8=Change name F17=Services F20=Narrative



Op: SYNGXM QPADEV0007 11/02/98 12:17:29 EDIT ACCESS PATH DETAILS SYNGXMMDL

File name . . . . . . . . : Customer Attribute . : REF

Access path name. . . . . : Customer by Name Type. . . . : RSQ

Unique key. . . . . . . . : (Y, blank)

or Duplicate sequence . . : F (F-FIFO, L-LIFO,

Maintenance . . . . . . . : I (I-IMMED, D-DLY, R-REBLD)

Alternate collating table :

Allow select/omit . . . . : (S-Static, D-Dynamic, ' '-None)

Generation mode . . . : M (M-MDLVAL, D-DDS, E-EXP, S-SQL, X-UNX)

Source member name . . : UUABREL2

Source member text . . : Customer Customer by Name

Format Format text Associated

? Seq name (Based on file) Retrieval access path

1 FABREAO Customer Retrieval index

SEL: Z-Acp.entries, R-Acp.relations, S-Select/omit sets, A-Associated Acps.

F3=Exit F8=Rename F20=Narrative



Op: SYNGXM QPADEV0007 11/02/98 12:19:24 EDIT ACCESS PATH FORMAT ENTRIES SYNGXMMDL

File name . . . . . . . . : Customer Attribute . : REF

Access path name. . . . . : Customer by Name Type. . . . : RSQ

Format text . . . . . . . : Customer

Based on. . . . . . . . . : Customer Format No . : 1

GEN Key Altcol Ref

? Field Name Type no. Dsc seq cnt

Customer Code CDE ABCD K 1 1

Customer Name TXT ABTX A 1

Customer Address 1 TXT ACTX A 1

Customer Address 2 TXT ADTX A 1

Customer Address 3 TXT AETX A 1

Customer Credit Limit VAL AAVA A 1

Customer Limit Used VAL ABVA A 1

SEL: Z-Field details.

F3=Exit F7=Relations



Span (SPN) Access Path» A SPN access path can only be specified over files

with Owned by or Refers to relationships» A SPN access path must be created over an owning

or referred to file» Press F9 on Edit Access Path Details panel to first

select the primary format and then the secondary format



Following may be changed from Edit Access Path Details panel» Unique/Duplicate key sequence» Access Path Maintenance (Immed, Rebld, Dly)» Alternate Collating Sequence» Select/Omit Criteria» Generation Mode (DDS/SQL)» Source member name & text

Building Access PathsModifying an Access Path


Building Access PathsArrays

» Arrays have a defined layout with each element having the same layout

» Must have a defined key that acts as an index» Key is any subset of the fields with a maximum composite

key length of 990» Sequence of equally keyed elements in a non-unique array

is not guaranteed» Each key in the composite key acts as a different array

dimension» Key can be ascending/descending» For key sequence, signs are ignored



Arrays can be used by the following four functions:» CRTOBJ - to add an element» CHGOBJ - to change an element» DLTOBJ - to delete an element» RTVOBJ - to read an element or set of elements



Features» Can be used to define a set of fields to be used as a

parameter entry to a function» Arrays are initialized on the first program call» Subsequent calls will not clear the array


Adding/Changing/Deleting Arrays» Enter *a in the option field or *ARRAYS in the positioner

field of Edit Database Relations panel» Enter Z against *Arrays file in the resulting panel to see a

list of arrays» Type an array name and press Enter» Type Z against the array name and press Enter to define

fields» Type D against an existing array and press Enter to delete



Building Access PathsGenerating & Compiling

» Generate source members and compile the generated source to produce objects, files & tables

» From Edit Database Relations panel, press F17 for services

» On Display Services Menu, type 8 at bottom of screen to display Display All Access Paths panel

» Type J (batch generation) or G (interactive generation) and press Enter


Building ApplicationsCOOL:2E Functions

COOL:2E function is a process that operates on files & fields

COOL:2E Functions can be linked to create larger processes that become the building blocks of an application

Several COOL:2E functions may be implemented in a single HLL program


Building ApplicationsImplementation of Functions

COOL:2E functions are implemented in two ways» External - the function is implemented as a separate

HLL program» Internal - the function is implemented as source code

inside the calling function


Building ApplicationsCOOL:2E Function Types

4 COOL:2E functions types» Standard Functions» Built-In Functions» Functions Fields» Message Functions

Standard functions » specify the entire programs or subroutines» User-defined processing can be specified» Provide building blocks of an application


Standard Functions» Divided into 3 categories

– Database Functions– Device Functions– User Functions

Built-in Functions» Execute functions like arithmetic operations, string

manipulation, control operations like commitment control & program exit



Built-in Functions» Specified within action diagrams» Implemented as in-line source code within calling functions» The Built-in functions are

1) Add 2) Commit

3) Compute 4) CONCAT -Concatenation

5) CVTVAR - Convert Variable

6) DIV - Divide 7) DIV WITH REMAINDER

8) Exit Program 9) Modulo



Built-in Functions» The Built-in functions are (contd…)

10) Move 11) Move All

12) MULT - Multiply 13) Quit

14) RTVCND - Retrieve Condition

15) Rollback 16) Set Cursor

17) Substring 18) SUB - Subtract



Function Fields» A field whose value is not physically stored in the database» Derived from other fields or files» One result parameter - the derived field» Variable number of input parameters used to derive the

value» COOL:2E provides ready-made function fields

1) SUM - Sum 2) MAX - Maximum 3) MIN - Minimum

4) CNT - Count 5) DRV - Derived 6) USR - User




Message Functions» Define workstation messages» Implemented using OS/400 message descriptions» Sent by a call to a CL subroutine» Can make direct references to fields in the data

model



Message Functions» The Message functions are

1) SNDERRMSG - Send Error Message

2) SNDINFMSG - Send Information Message

3) SNDCMPMSG - Send Complete Message

4) SNDSTSMSG - Send Status Message

5) RTVMSG - Retrieve Message

6) EXCMSG - Execute Message


Building ApplicationsStandard Functions

Database Functions» Basic routines for accessing the database» Implemented as part of an external function» Can be used in many different functions» There are 4 database functions

1) CRTOBJ - Create Object

2) CHGOBJ - Change Object

3) DLTOBJ - Delete Object

4) RTVOBJ - Retrieve Object



Device Functions» Used in interactive & report programs» Consist of panel/report design & action diagram» All device functions are external functions except for

PRTOBJ function» Implemented as programs that operate over

databases



Device Functions (contd…)» The Device Functions are

1) DSPRCD - Display Record

2) DSPRCD2 - Display Record 2 panels

3) DSPRCD3 - Display Record 3 panels

4) PMTRCD - Prompt Record

5) EDTRCD - Edit Record

6) EDTRCD2 - Edit Record 2 panels

7) EDTRCD3 - Edit Record 3 panels



Device Functions (contd…)» The Device Functions are

8) DSPFIL - Display File

9) EDTFIL - Edit File

10) SELRCD - Select Record

11) DSPTRN - Display Transaction

12) EDTTRN - Edit Transaction

13) PRTFIL - Print File

14) PRTOBJ - Print Object



User Functions» Means of incorporating user programs or subroutines

into COOL:2E generated applications» Processing steps can be specified with action

diagrams or user-written HLL» Implemented as inline code (internal functions) or call

to programs (external functions)



User Functions» The User Functions are

1) EXCINTFUN - Execute Internal Function

2) EXCEXTFUN - Execute External Function

3) EXCUSRPGM - Execute User Program

4) EXCUSRSRC - Execute User Source


Building ApplicationsBasic Function Properties

Function Name» up to 25 characters long including embedded blanks

& must be unique within a file

Function Components» Function options

– allow the user to customize function features like database changes, display features, exit control, commitment control, exception routines, generation options & environment options



Function Components» Function Parameters

– specify the input and output parameters. Parameters are also used to define local variables for the function

» Device Designs– specify the visual presentation of the 2 types of devices used by

functions: Panels & Reports

» Action Diagrams– specify the processing steps for function logic. This is a combination of

default COOL:2E supplied and optional user defined processing logic



Function class Parameters DeviceDesign

ActionDiagrams

FunctionOptions

Device Functions

Database Functions

User Functions

x

x

x, x1

x, x3

Messages

Function Fields

x

x

x, x2

x

x

Built-In Functions x x x

1 EXCINTFUN & EXCEXTFUN have action diagrams

2 Only DRV (Derived) function fields have action diagrams

3 EXCEXTFUN is the only user function with function options

Function Components



Default Device Function Processing» Default Device functions compile into working

programs with default processing» Additional logic required for business processing


Building ApplicationsFunctions & Access Paths

Functions & Access paths» Functions operating on a file are always attached to it

by an access path» Functions can access many files with access paths

based on several files» A generated program can be made up of several

functions each accessing a different access path» Default panel/report formats are derived from the

function’s access path


Building ApplicationsAdditional Processing

Automatic additional logic for functions» Integrity Checking

– Domain integrity checking for allowed values. Enforced by fields having same reference file.

– Referential Integrity Checking to ensure that relations specified in the model are satisfied

» Field Validation– upper/lower case validation– valid name checking – validation through a check condition.


Building ApplicationsAdditional Processing

Automatic additional logic for functions» Linking Functions

– Automatically links certain functions together

– External update functions like EDTFIL are automatically linked to database function like CHGOBJ

Building Blocks Approach» Functions are building blocks» By linking functions together, required functionality can

be achieved


Building ApplicationsDefining Functions

Accessing Functions» Display All Functions panel

– select option from the Services Menu

» Display File Functions panel– option F on a file in Edit Database Relations panel

Shipped Files Fields» COOL:2E shipped files contain the default data like built-in

functions, messages etc.» Type * in the Object field & DFN in relations field of Edit

Database Relations panel to access


Op: SYNTHS QPADEV0004 18/02/98 13:52:40 DISPLAY ALL FUNCTIONS SYNSXT Application area. : Source library: SYNSXTGEN ? File Function Type GEN name Commodity Change Commodity CHGOBJ *N/A Commodity Create Commodity CRTOBJ *N/A Commodity Delete Commodity DLTOBJ *N/A Commodity Edit Commodity EDTFIL SXACEFR Commodity Select Commodity SELRCD SXABSRR Commodity Price Change Commodity Price CHGOBJ *N/A Commodity Price Create Commodity Price CRTOBJ *N/A Commodity Price Delete Commodity Price DLTOBJ *N/A Commodity Price Edit Commodity Price EDTFIL SXAEEFR Commodity Price Select Commodity Price SELRCD SXADSRR SEL: Z-Dtls, P-Parms, N-Narr., F-Action diagram, S-Device Design, T-Structure, A-Acp, G/J-Gen, E-STRSEU(pgm), L-Locks, D-Delete, U-Where used, 3-Doc. F3=Exit F5=Reload



Op: SYNTHS QPADEV0004 18/02/98 13:48:09 EDIT FUNCTIONS SYNSXT File name. . . : Commodity ** 1ST LEVEL ** ? Function Function type Access path Change Commodity Change object Update index Create Commodity Create object Update index Delete Commodity Delete object Update index Edit Commodity Edit file Retrieval index Select Commodity Select record Retrieval index + SEL: Z-Details, P-Parameters, F-Action diagram, S-Device design, N-Narrative, T-Structure, A-Access path, U-Usage, G/J-Generate, D-Delete, C-Copy, L-Lock. F3=Exit F5=Reload F7=File details F9=Add F17=Services



*DSNR SYNSXT Op: SYNTHS QPADEV0004 18/02/98 13:40:46 EDIT DATABASE RELATIONS SYNSXT => * Rel lvl: DFN ? Typ Object Relation Seq Typ Referenced object FIL *Arrays Defined as FIL *Arrays FIL *Built in functions Defined as FIL *Built in functions FIL *Configuration Table Defined as FIL *Configuration Table FIL *Distributed File Defined as FIL *Distributed File FIL *External Data Access API Defined as FIL *External Data Access API FIL *Field attribute types Defined as FIL *Field attribute types FIL *Job data Defined as FIL *Job data FIL *Messages Defined as FIL *Messages FIL *Program data Defined as FIL *Program data FIL *Standard header/footer Defined as FIL *Standard header/footer FIL *COOL:2E reserved pgm data Defined as FIL *COOL:2E reserved pgm data FIL Audit Information Defined as FIL Audit Information FIL Commodity Defined as FIL Commodity FIL Commodity Price Defined as FIL Commodity Price FIL Company Defined as FIL Company + SEL: Z(n)-Details, N(n)-Narr, S(n)-Select, E(n)-Entries, V-Virt.fields, F-Funcs F3=Exit F5=Reload F7=Fields F9=Insert F10=Define obj. F17=Services



Building ApplicationsDatabase Functions

What are Database functions?» means of performing actions on database» defined as HLL subroutine

4 Database functions1) CRTOBJ - routine to add a record to a file.

2) CHGOBJ - routine to update a record.

3) DLTOBJ - routine to delete a record.

4) RTVOBJ - routine to retrieve one or more records.


Default versions of CRT, CHG and DLT database functions are created for all REF & CPT files.

RTVOBJ must be created if needed.

Additional processing before and after database access may be specified in the action diagram.



Function Purpose Access PathCRTOBJCHGOBJDLTOBJ

Add a single recordUpdate a single recordDelete a single record

UPDUPDUPD

RTVOBJ Read a record or record(s) RTV, RSQ



Array Processing» Even though arrays are not implemented as database

files, the 4 database functions can be defined over an array and used.

» DLTOBJ with no parameter will clear an array



Building ApplicationsDevice Functions

What are Device Functions?» Interactive panels or reports» Panel device functions for interactive user interface

between end user and application» Report device functions for written presentation of

data» All device functions except PRTOBJ function are

implemented as external functions



Interactive device design editor» Allows defining of

– field attributes– positioning– conditioning– user function keys– literals

» Can be accessed from Edit Functions, Edit All Functions, Edit Function Devices, or the Display All Functions panels


Device Standard Header device functions» Define Screen Format (DFNSCRFMT)

– to define standard screen header and footer for use by other functions with attached screen design

» Define Report Format (DFNRPTFMT)– to define standard report header and footer for use by Print

File report functions



Single record device functions» Prompt Record (PMTRCD)

– defines a program to prompt for a list of fields defined by a specified access path

– validated values can be passed to another function

» Display Record (DSPRCD)– defines a program to display a single record from a

specified database file– If no key is specified, a key panel prompts for a key



Single record device functions (contd...)» Display Record 2 panels (DSPRCD2)

– identical to DSPRCD except that it allows the record details to extend into 2 device pages

» Display Record 3 panels (DSPRCD3)– identical to DSPRCD except that it allows the record details

to extend into 3 device pages



Single record device functions (contd…)» Edit Record (EDTRCD)

– defines a program to maintain (add, change or delete) records one at a time.

– If no key is specified, a key panel prompts for a key.

» Edit Record 2 panels (EDTRCD2)– identical to EDTRCD except that it allows the record details to extend

into 2 device pages.

» Edit Record 3 panels (EDTRCD3)– identical to EDTRCD except that it allows the record details to extend

into 3 device pages.



Multiple record device functions» Display File (DSPFIL)

– defines a program to display the records in a file many at a time, using a subfile

– the subfile is loaded one page at a time when the user presses ROLLUP/F8

» Edit File (EDTFIL)– defines a program to maintain the records in a file many at a time,

using a subfile– the subfile is loaded one page at a time when the user presses

ROLLUP/F8.



Multiple record device functions (contd…)» Select Record (SELRCD)

– defines a program to display the records in a file many at a time, using a subfile

– allows the user to select one record which is returned to the calling program

– called from a function that requests a selection list.



Single & multiple record device functions» Display Transaction (DSPTRN)

– defines a program to display the records from a selected pair of database files

– the pair must be connected by an Owned by or Refers to relation

» Edit Transaction (EDTTRN)– defines a program to maintain the records from a selected pair of

database files

– the pair must be connected by an Owned by or Refers to relation.



Printer device functions» Print File (PRTFIL)

– defines a program to print records from a specified access path.

» Print Object (PRTOBJ)– defines a particular report fragment which will print the

records from a specified access path at any point within a PRTFIL function

– can be embedded within other PRTOBJ functions.



Standard Features of Device Functions» Diagnostic messages

– message sent to program’s message queue– message subfile to show the pending messages– allows second level text and substitution variables

» Highlighting of Errors– a field in error is highlighted in reverse image– cursor is positioned at first such field

» On-line Help Text– pressing HELP key or F1 key results in call to a help program



Standard Features of Device Functions» Print Key

– print key is enabled to allow panel prints

– print file is controlled by YPKYVNM model value

» Selection Columns– Selection subfiles have selection column on the left

» Function key Usage– CUA standards are followed e.g. F3 is exit

» Positioning facilities– subfile programs have a positioning field



Standard Features of Device Functions» Single Page Subfile load up

– subfiles are loaded on demand basis– only when F8 or ROLLUP keys are pressed

» Concurrency checking and record locking– updation programs do not hold locks upon database while changes are

entered or validated– includes logic at the point of update to check for record lock by other

users

» Overflow Handling– report functions include handling of page overflow



What are User Functions?» means of implementing additional user processing

within an existing function or as an independent implementation along with an existing function

» e.g. batch functions for updating database having no associated device or a user-written HLL program which has to be integrated to COOL:2E generated application

Building ApplicationsUser Functions


Two types of User Functions» Free-Form User functions

– specify actions that can be used within a function or called from a function

– processing logic is defined through the Action Diagram editor

» User Coded User functions– functions are user-written in HLL– can be called or embedded



Free-Form User Functions» Execute Internal Function (EXCINTFUN)

– allows specification of a section of an action diagram for repeated use in other functions

– implemented as Internal function

» Execute External Function (EXCEXTFUN)– allows specification of an HLL program using an action

diagram– implemented as External function



User Coded User Functions» Execute User Program (EXCUSRPGM)

– describes interface to a user written HLL program– parameters can be specified on the call

» Execute User Source (EXCUSRSRC)– specifies that user-written HLL code be included within the

HLL source generated by COOL:2E for an external function



What are Message Functions?» means of defining messages of various types,

specifying different message files for the message, specifying substitution variables and changing message identifiers

» can be accessed by looking at functions of *MESSAGES file

Building ApplicationsMessage Functions


6 Message Functions» Send Error Message (SNDERRMSG)

– error message to be sent to a calling function– used for diagnostic messages arising from user validation

» Send Information Message (SNDINFMSG)– information message be sent to the message queue of the

calling program

» Send Completion Message (SNDCMPMSG)– completion message to be sent to a calling function



6 Message Functions» Send Status Message (SNDSTSMSG)

– status message to be sent to a calling function– informs of the progress of a long-running process

» Retrieve Message (RTVMSG)– to retrieve message text from message in message file

» Execute Message (EXCMSG)– specifies that a request message has to be executed



What are Function Fields?» Special types of fields that can be used in device

designs and action diagrams» based on other fields» processing can be specified for a function field

Building ApplicationsFunction Fields


Function field Usages» Sum (SUM)

– contains sum of values of another field– Input Parameter is the field whose sum is to be calculated– Result Parameter is the field containing the sum

» Count (CNT)– defines count of a set of records in EDTTRN, DSPTRN, PRTFIL &

PRTOBJ functions– Input Parameter is field on the detail or subfile record– Output field contains the count



Function field Usages» Maximum (MAX)

– contains the highest value of another field

– Input Parameter is the field whose maximum is to be calculated

– Result Parameter is the field containing the maximum

» Minimum (MIN)– contains the lowest value of another field

– Input Parameter is the field whose minimum is to be calculated

– Result Parameter is the field containing the minimum



Function field Usages» Derive (DRV)

– performs user-defined action to derive result– action diagram is attached where processing can be specified for

deriving the result– Multiple input Parameters can be specified– One Resulting Parameter

» User (USR)– reserved for work fields needed in device design or action diagram e.g.

menu options, command string– can be input-capable or output only



What are Function Options?» Function options control the features of functions» Function Options for

– Database Changes– Display Features– Exit Control– Commitment Control– Exception Routine– Generation– Environment

Building ApplicationsFunction Options


Database Changes Function options» determine if program allows add, change or delete capabilities or

a combination

Display Features Function options» Confirmation - function prompts for confirmation» Initial value for Confirmation» Standard Header/Footer selection» Subfile Selection Column» Dynamic Program Mode - function determines initial mode of

execution



Display Features Function options» Exit after Add - for EDTRCD functions» Repeat Prompt - whether prompt (PMTRCD) to be redisplayed

after user processing» Bypass Key Screen - whether key screen to be displayed

before displaying detail screen» Post Confirm Pass - to re-read database file and update subfile

after confirmation» Send All Messages - whether message subfile at bottom of

panel for first or all errors



Exit Control» Determines execution characterstics of programs» Closedown Program - whether program will terminate

or remain invoked but inactive» Reclaim Resources - whether RCLRSC command will

be invoked after program call» CopyBack Messages - whether pending messages in

program message que to be copied to program message queue of calling program



Commitment Control» Determines commitment control regime for a program

namely MASTER, SLAVE or NONE» MASTER - program contains commit points and the

program ensures that commitment is active» SLAVE - program contains commit points but the

program does not ensure that commitment is active» NONE - program does not run under commitment

control



Exception Routine» Generate Exception Routine - specifies whether code

for exception routine (*PSSR) should be generated

Generation Options» Generation Mode - specifies database access used for

functionsD for DDS access method; S for SQL access method

E for External Source Format; M for model value

A if generation value of primary path to be used



Generation Options» Generate Help - specifies whether help is generated» Screen Text Constants

L results in panel literals being hardcoded in source

M results in panel literals to be stored in message file

D means model value to be used



What are Function Parameters?» Specifies the fields passed between functions

Basic properties of function parameters» Name» Usage Type

– Input only, Output only, Both, Neither

» Flag Error Status– specifies error in the called function

– allowed in SNDERRMSG, EXCMSG or any external function

Building ApplicationsFunction Parameters


Neither Parameters» No value passed or returned for a parameter

» Neither parameters are available for use as local variables within the function

Default parameters of functionsFunction Default parameters Usage

CHGOBJ All fields of Update index I

CRTOBJ All fields of Update index I

DLTOBJ Key fields of Update index I

RTVOBJ Key fields of attached acc. path I

SELRCD Key fields of Update index B



Return Code Parameter» Informs the calling program of the state under which

called program was exited» All functions except EXCUSRPGM & EXCUSRSRC

have implicit return code parameter as first parameter» The values of Return Code parameter are

*DBF error; *Normal; *Record already exists;

*Record does not exist; *Substring error;

*User Quit requested



Parameter Roles» Specifies the use of parameter in function» Following are the parameter roles

Map Parameter - the parameter is added automatically to the corresponding field on the receiving function’s panel design. Map Neither parameter adds field to panel design without passing a value

Restrictor Parameter - the parameter restricts the updation of field by making it input only field

Positioner Parameter - the parameter is used to position a function to start reading records from a particular record



Parameter RolesVary Parameter - the parameter can have a varying length. Useful for

interfacing with user-written functions

Defining Function Parameters» in the Edit Functions panel, type P next to the selected

function» specify a field or a set of fields in Edit Function Parameters

panel» Type Z for a parameter to specify Role/Usage through Edit

Function Parameter Details panel




Op: SYNTHS QPADEV0007 19/02/98 10:38:58 EDIT FUNCTION PARAMETERS SYNSXT Function name. . : Delete Commodity Type : Delete object Received by file : Commodity Acpth: Update index Passed ? File/*FIELD Access path/Field as Seq Commodity Update index KEY | Values FLD: One parameter per field RCD: One parameter for all fields KEY: One parameter for key fields only SEL: Z-Details (field selection). F3=Exit F5=Reload



Op: SYNTHS QPADEV0007 19/02/98 10:40:20 EDIT FUNCTION PARAMETER DETAILS SYNSXT Function name. . : Delete Commodity Type : Delete object Received by file : Commodity Acpth: Update index Parameter (file) : Commodity Passed as: KEY ? Field Usage Role Commodity Code I SEL: Usage: I-Input, O-Output, B-Both, N-Neither, D-Drop. Role: R-Restrict, M-Map, V-Vary length, P-Position. F3=Exit


Building ApplicationsDevice Designs

What are Device Designs?» Specifies the layouts of fields and constants on the panels or

report designs for a function

Basic properties of Device Designs» Device Design Standard

– depends on the function type and associated standard header/footer functions

» Device Design Format– Formats are created from the fields of the based-on access path

and their associated text



Basic properties of Device Designs» Device Design Field

– fields come from access path, function parameters and Header/Footer

Editing Device Design» in the Edit Functions panel, type S next to the selected

function to display the device design» use function keys to edit the device design

– F1 moves the field 40 columns

– F3 exits the panel



Editing Device Design» use function keys to edit the device design

– F4 move the field 40 columns to the right– F5 edits device format details– F6 cancels the pending operations– F7 displays Edit Device Design Format Relations– F8 moves the selected field to the cursor position– F9 wraps text onto next line– F10 moves text one column to the right– F11 removes the line– F12 aligns text below cursor position




– F13 fast exits the panel– F15 moves panel window to left margin– F16 moves window to right margin– F17 displays a list of device formats– F18 displays the Edit Field Attributes panel– F19 adds new function field to the device– F20 edits function field on the device– F21 adds a line above cursor– F22 moves text one column to the left




– F23 adds constant field to the device design– F25 aligns all fields under the cursor position


Building ApplicationsAction Diagrams

What are Action Diagrams?» Action Diagrams record the basic constructs that

make up a procedure» the procedural steps encompass a list of actions like

call to another function or a low-level built-in function

Displaying Action Diagram of a function» Type F next to the selected function in the Edit

Functions panel



EDIT ACTION DIAGRAM Edit SYNSXT Commodity FIND=> Edit Commodity > Edit Commodity .-- . ...Initialize <-- . .=REPEAT WHILE . |-*ALWAYS . | ...Load first subfile page <-- . | PGM.*Reload subfile = CND.*NO . | > Conduct screen conversation . | .=REPEAT WHILE . | |-PGM.*Reload subfile is *NO . | | Display screen . | | ...Process response <-- . | '-ENDWHILE . '-ENDWHILE . ...Closedown <-- '-- F3=Exit F5=User points F6=Cancel pending moves F7=Forward F8=Backward F9=Edit parameters F15=Open Functions F16=Toggle Change Date F24=More keys



User Points» COOL:2E/2 functions except EXCUSRSRC &

EXCUSRPGM have default action diagram» some portions of default action diagrams which depict

essential processing are not alterable» areas which can be modified and where business logic

can be entered are called User Points» Press F5 on the action diagram to display user points

for the function



EDIT ACTION DIAGRAM Edit SYNSXT Commodity FIND=> Edit Commodity .............................................................. > Edit : ACTION DIAGRAM EXIT POINTS F3=Exit SEL:X,Z-Select. : .-- : USER: Initialize program : . ...I : USER: Initialize subfile header : <-- . .=RE : USER: Initialize subfile record (existing record) : . |-*A : USER: Initialize subfile record (new record) : . | .. : CALC: Subfile control function fields : <-- . | PG : USER: Validate subfile control : . | > : USER: Validate subfile record fields : . | .= : CALC: Subfile record function fields : . | |- : USER: Validate subfile record relations + : . | | :............................................................: . | | ...Process response <-- . | '-ENDWHILE . '-ENDWHILE . ...Closedown <-- '-- F3=Exit F5=User points F6=Cancel pending moves F7=Forward F8=Backward F9=Edit parameters F15=Open Functions F16=Toggle Change Date F24=More keys



Action Diagram Constructs» Sequential - specify a list of actions or other

constructs that are executed in a sequential order. Denoted by brackets enclosing dotted lines

___

: ….

: ….

:___



Action Diagram Constructs» Conditional - actions are conditionally executed and

are called CASE blocks. Denoted by CASE and ENDCASE statements

_ CASE

: ….

: ….

:_ ENDCASE



Action Diagram Constructs» Iterative - represents repetitive logic. Denoted by

REPEAT WHILE and ENDWHILE statements _ REPEAT WHILE

: ….

: ….

:_ ENDWHILE



Context» instances of a field that are available for use at a particular

processing step

» Database Contexts - instances of same database field available in more than one file

» Device Contexts - instances of same device field available in more than one format

» Literal Contexts - instances of field available from literals like condition etc.

» System Contexts - instances of fields available from various system values



Context» Function Contexts - instances of field available from

function attributes like parameter

Database Contexts» DB1 - fields are in the first or the only format of the

based-on access path» DB2 - fields are from second format of the based on

access path e.g. in SPN access path



Device Contexts» KEY - fields are from the key panel display in case of

EDTRCD or DSPRCD functions» DTL - fields are from the first panel of EDTRCDn or

DSPRCDn functions» 2ND - fields are from the second panel of EDTRCDn or

DSPRCDn functions» 3RD - fields are from the third panel of EDTRCDn or

DSPRCDn functions



Device Contexts» CTL - fields are from the subfile control record format» RCD - fields are from the subfile record format» CUR - fields are from the current report format in

PRTOBJ and PRTFIL functions» NXT - fields are from the next active report format in

PRTOBJ and PRTFIL functions



Literal Contexts» CND - particular field condition is specified as a value» CON - constant context contains a literal value for non-

status type fields

System Contexts» JOB - contains system fields having execution time

information of the job e.g. *USER, *JOB» PGM - contains system fields that control the execution

like *Program Mode, *Return Code



Function Contexts» PAR - parameter fields as field values» WRK - program variables not declared as any context

as field values e.g. any field in data dictionary

Action Diagram Editor» allows modification of Action Diagram» line commands allow the modification



Action Diagram Editor» Line Commands

* Activate/Inactivate construct (Comment out) ** Place block Activate/Inactivate boundary A Place copied or moved construct after this line B Place copied or moved construct before this line C Copy construct to a point indicated by 'A' or 'B' CC Place block Copy boundary D Delete this construct DD Place block Delete boundary F Edit action or condition details for line FF Edit action parameters H Hide construct I+ Insert *ADD built-in function I+F Insert and Prompt *ADD built-in function I* Insert Comment I*F Insert and Prompt Comment




I- Insert *SUB built-in function I-F Insert and Prompt *SUB built-in function I= Insert *MOVE built-in function I=A Insert and Prompt *MOVE ALL built in function I=F Insert and Prompt *MOVE built-in fucntion IA Insert Action IAF Insert and prompt Action IC Insert Case condition ICF Insert and Prompt Case condition II Insert Iteration IIF Insert and Prompt Iteration IM Insert Message function IMF Insert and Prompt Message function IO Insert *OTHERWISE condition IOF Insert and prompt *OTHERWISE condition




IS Insert Sequence ISF Insert and Prompt Sequence IX Insert New condition within Case IXF Insert and Prompt New condition within Case M Move construct to a point indicated by 'A' or 'B' MM Place block Move boundary NA Copy to notepad & append to contents of notepad NAA Place block notepad append boundary NI Insert entire contents of notepad after this line NR Copy to notepad & replace contents of notepad NRR Place block notepad replace boundary S Show construct T Return to top level of action diagram U Unzoom out of construct to previous construct Z Zoom into construct


Generating ApplicationsCOOL:2E Generator

Generation» Data Model is translated into either DDS sources or SQL

collections– Access Paths into Physical and Logical files

» COOL:2E functions are translated into HLL programs - COBOL, RPG or both

» Device designs attached to functions are generated as DDS sources of Display and Printer files

» Compilation of generated code is automatically submitted


Generating ApplicationsCOOL:2E Generator

Generating Code» from the Services Menu, take option for displaying all

access paths or all functions» Take option J(batch) or G(online) for the item that

has to be generated


COOL:2E/1E UtilitiesMenus

COOL:2E/1E Menus» dynamic menu system» removes the need of individual OS/400 display file for

each application menu» Menus stored in special form and displayed using

COOL:2E commands YWRKMNU & YGO» Menus are stored in a database file member» YDSNMNU is the default menu file supplied with

COOL:2E/1E


COOL:2E/1E UtilitiesMenus

COOL:2E/1E Menus» YCRTDSNF command can create a new design file» YADDDSNFM adds new member to design file» 2 types of COOL:2E menus

– Single option– Multiple option

synon training material

Documents

applications cool

2e1e cool

e null model cool

e base products cool

e rpg generators cool

e cobol generators cool

e sourcecool

2e1e products cool