SYNON Tutorial

Extracted from CA 2E Tutorial r8.5

• This tutorial provides a navigational guide to
the new CA 2E® user. It will guide you through
the steps required to develop an application
using CA 2E. After completing this tutorial, you
will have designed an CA 2E working
application. The tutorial includes all of the
basic facilities of CA 2E as well as some
advanced features.
• Introduction
• This chapter describes the organization of the tutorial,
sources for additional information about CA 2E,
conventions used in the tutorial, the application
development life cycle, guidelines for getting started with
the tutorial, and a glossary of terms introduced in the
tutorial.
• Note: Be sure to read this chapter before beginning the
tutorial.
• The following sections summarize each chapter of the
tutorial.
• Chapter 2 Defining Requirements
• Determines the business requirements of the
application to be developed. Describes how to
determine the data required from the
business requirements. Applies the rules of
normalization and generalization to the list of
data elements to develop an entity
relationship diagram.
• Chapter 3 Data Modeling
• Describes how to translate the entity
relationship diagram into an CA 2E data model
diagram. Describes how to enter files and field
details, field validation, and default access
paths created by CA 2E. Introduces involution.
Describes how to create alternate access paths
that use selection criteria and how to join files
together.
• Chapter 4 Designing Functions
• Introduces CA 2E functions (Edit File, Select
Record) and how to design these in CA 2E.
• Chapter 5 Generating, Compiling, and
Executing
• Describes how to generate source to
implement the access paths and functions
created in the first four chapters and how to
compile the source to produce executable i OS
objects - files and programs.
• Chapter 6 Maintaining Your Application
• Presents tools to help you maintain an CA 2E
generated application, including prototyping,
working with model object lists, and creating
function versions.
• Chapter 7 Advanced Functions
• Describes the use of the Edit Transaction
function using the Span access path.
• Chapter 8 Report Functions
• Describes how to produce a basic report
program from the CA 2E design model.
• Related Information
• This module provides only the information about
CA 2E that is necessary to complete the Tutorial.
Additional information can be found in the
following list of CA 2E manuals.
• Note: CA 2E panels provide extensive online help;
simply press the Help key on your keyboard to
display more information for the current panel.
Be sure to use this facility as you do the tutorial.
• Note: The word ‘Panel’ used throughout the
tutorial is another word for display. Panels are
IBM-generated screens that automatically
supply much of the programming effort when
lists and menus are used.
 The 5 Main Modules
• Getting Started
• This module describes the libraries that make
up CA 2E and the development environment.
This module also outlines the installation and
upgrade process.
• Defining a Data Model
• This module provides instructions on using CA
2E to design and maintain a data model.
• Building Access Paths
• This module provides instruction on how to
build, modify, delete and document access
paths and how to create arrays.
• Building Applications
• This module provides instructions on building
functions in CA 2E. The module tells you how
to set up system default values, build
functions, edit device designs and action
diagrams, and how to generate and compile
functions.
• Generating and Implementing Applications
• This module describes model objects, model
object lists, and impact analysis and provides
instructions and recommendations to
successfully generate, compile and implement
an CA 2E application.
CA 2E and the Application Development Life
Cycle
• CA 2E supports the use of a top down,
structured, data-driven application
development life cycle. The application
development life cycle is illustrated in the
following diagram.
• The application development life cycle provides direction
during the design and generation of an CA 2E application.
This tutorial provides instructions to complete each of the
stages listed in the diagram.
• 1. Determine the application requirements.
• 2. Describe data in the form of an CA 2E data model. The
data model is the basis for everything designed within CA
2E.
• 3. Design the functions that will operate on your data.
• 4. Prototype your functions to test your design.
• 5. Return to your design model to specify additional
functionality.
• 6. Generate and compile your application.
 PREREQUISITES

• Library List
• Your library list must include certain libraries before you can
create an CA 2E design model; for example, the CA 2E and
Toolkit product libraries. Refer to the worksheet that was
filled out when CA 2E was installed at your company for a list
of the required libraries. The worksheet is in the Installation
Guide. You can add any missing libraries using the i OS Add
Library List Entry (ADDLIBLE) command. For example,
• ADDLIBLE Y2SY
• ADDLIBLE Y1SY
• Creating an CA 2E Design Model
• You must have an CA 2E design model library in which to store
your CA 2E design model. If you do not already have a design
model you may create a new one using the CA 2E Create
Model Library (YCRTMDLLIB) command as follows:
• YCRTMDLLIB MDLLIB(MYMDL) OBJPFX(MY)+
• SYSTEXT(‘My Model’) DSNSTD(*CUATEXT)
• This command allows you to create your model interactively.
You can also do this as a batch process. In this example the
design standard, *CUATEXT, has been specified so that all
functions that include interactive panel displays will be
presented with either Action Bars or Windows. The normal
default for the design standard is *CUAENTRY.
• The message “Model library MYMDL created” should appear
following successful completion of the command. The use of this
command is only necessary when you are creating a new CA 2E
design model. The next topic discusses how to access an existing
CA 2E design model.
• The YCRTMDLLIB command also creates a library to contain the
source and application objects that you will generate from your
CA 2E design model. The name of this library is given by the
GENLIB parameter, which in this case defaults to the name
MYGEN. Furthermore it creates a Toolkit Library list with the
same name as the CA 2E design model library.

• NOTE: The “Y” beginning each command is SYNON’s identifier to

distinguish their command set from the native OS commands.
• Entering the CA 2E Design Model
• To enter CA 2E, type the Start CA 2E (YSTRY2)
command, specifying the name of your CA 2E
design model as the LIBLST parameter from
any i OS Command Entry line:
• YSTRY2 MYMDL
• Type the command as shown.
• Press Enter.
• The CA 2E Main menu appears. The first panel
of the CA 2E Main Menu provides a set of
Design Model options and access to CA 2E
commands grouped according to function.
Type 1 in the command entry line as shown to display the CA 2E Designer (*DSNR) Menu.
 Press Enter.
The first panel of the CA 2E Designer (*DSNR) Menu displays. This menu provides a list of tasks available to users with
*DSNR authority. Type 1 in the command entry line as shown to enter your CA 2E design model for editing.
• Press Enter.
• Your CA 2E design model will now be loaded.
An CA 2E window with the message Starting
CA 2E Session appears. The load process may
take several seconds.
• Other Methods of Entering Your Design Model
• Following are two alternative methods of entering your design
model.
– – Go directly to the CA 2E Designer (*DSNR) Menu using the Menu
parameter on the Start CA 2E (YSTRY2) command from any i OS Command
Entry line as follows:
– YSTRY2 MYMDL MENU(DSNR)
– – Bypass the Designer (*DSNR) Menu and directly enter your model for
editing using the Toolkit Change Library List (YCHGLIBL) command and the
Edit Model (YEDTMDL) command from any i OS Command Entry line.
– YCHGLIBL MYMDL
– YEDTMDL
– The Y2 command is a short form of the YEDTMDL command.
– YCHGLIBL MYMDL
– Y2
• Leaving the CA 2E Design Model
• It is unlikely that you will complete the tutorial
in a single session. If at any time you want to
leave your CA 2E design model, you can do so
by pressing F3 repeatedly until you return to
the Edit Database Relations panel
• Setting Your Model Profile to Log Changes to Your Model
• Your model profile establishes the basic working environment
for your interactive session. CA 2E automatically creates a
model profile for each user that is granted access to a model.
Before beginning work on your CA 2E model, you need to
check, and possibly override, the default settings in your
model profile.
• Note: You need to do this step before you enter any
information for your tutorial design model and you only need
to do it once.
• This process assumes that the Edit Database Relations panel is
displayed on your screen. If not, re-enter your model as
explained previously using the Start CA 2E (YSTRY2) command.
• Accessing the Display Services Menu
• One way to access your model profile is by using
the Display Services Menu. This menu is an
important CA 2E tool that gives you access to many
CA 2E support functions while you are working on a
model. From the Edit Database Relations panel,
press F17 to access the Display Services Menu This
function key is available from many CA 2E panels.
• Understanding a Session List
• The basic components of an CA 2E model are called model objects. CA 2E
provides a model object list tool that lets you manipulate logical groups of
model objects. One example of a model object list is the session list. When
the Log changed objects field in your model profile is Y, CA 2E automatically
keeps track of each change you make to your CA 2E model and adds the
changed model object to your session list. The session list is cumulative and
therefore it persists across your interactive sessions.
• Notice the Edit model list (YEDTMDLLST *SESSION), option on the Display
Services Menu. You can use this option at any time to view and work with
the contents of your session list; in other words, you can use this option to
view the model objects you changed in your CA 2E model.
• You will use the session list again later in the Maintaining Your Application
chapter of this tutorial.
• Exiting the Display Services Menu
• When you finish using the tasks on the Display Services Menu, exit by
pressing F3 to return to the Edit Database Relations panel.
• Deleting User-defined Data from your CA 2E Design
Model
• This step applies only if you wish to delete the data you
entered from your CA 2E design model. To do so use
the CA 2E Clear Model (YCLRMDL) command as follows:
• YCLRMDL MDLLIB(MYMDL) GENLIB(*GENLIB)
• If you run this command, your CA 2E design model will
still exist, but everything you have added to the design
model will be deleted.
Chapter 2: Defining Requirements
• For the purpose of this tutorial, a Horse
Racing application will be used.
 Introduction to Defining Requirements

• This tutorial will demonstrate how to use CA

2E to address all phases of the life cycle in the
development and maintenance of a horse race
application. A sample horse racing form is
illustrated below.
 Requirements Definition
• Initial requirements for the application
illustrated in this tutorial include the form from
the preceding page. Management requires a
system that tracks the horses and jockeys
entered in races. In addition, they want to
track the parentage and racing results of each
horse and require certain reports.
• Requirements are divided into Business and
Data
 Business Requirements
• After analysis of the form and further discussion with management,
it is determined that the application requires the following:
• The business objects or entities: Course, Horse, Jockey, and Race.
These will become files.
• A record of the Dam (mother) for each horse to ensure that it is
female and older than the horse.
• A record of the Sire (father) for each horse to ensure that it is male
and older than the horse.
• A record of horses entered in each race.
• The following two reports:
– – A list of all horses including a count and total value
– – A list of the races each horse has entered
 Data Requirements
• Having identified the business requirements, it
is necessary to examine them and determine
the data needed to meet the requirements.
• Analyze the form carefully to make a list of all
the data needed to create the form. Do not be
concerned about defining the data as a
grouping of data (entity/file) or a property of
the group (attribute/field). Some examples are
shown here:
• Jockey
• Horse name
• Horse code
• Entry number
• Finishing position
• Race name
• Race distance
• Courses
• Course name
• Race time
• Going conditions
• Prize money
• Race date
• Dam (Horse’s mother)
• Sire (Horse’s father)
• Horse’s date of birth
 Chapter 3 – Data Modeling
• This chapter introduces the following topics:
• Data Model
• CA 2E Relations
• Field Details and Conditions
• Extending Relations
• Virtual Fields
• Access Paths
 Data Model
• In this topic you will build the CA 2E data model that supports the
requirements of the horse race application.
• New terms introduced:
• Entity
• Relationship
• Entity Relationship Diagram
• Attribute
• Unique Identifier
• Primary key
• Foreign key
• Normalization
• Generalization
• CA 2E Relation
• CA 2E Data Model Diagram
 Objectives
• Use an Entity Relationship Diagram (ERD) to
design the horse race application data model.
Normalize and generalize the entities to refine
the ERD. Translate the ERD into CA 2E
relations. The following steps explain how to
achieve these objectives.
 Identify Application Entities
• The first step in entity relationship modeling is
to identify the entities (files) that are present
in your application using the data elements
you identified during your requirements
analysis. An entity is a thing or object of
significance for which you need to gather and
store information.
• Each entity must be uniquely identifiable. This
means that each instance (occurrence) of an
entity must be separate and distinctly
identifiable from all other instances of that
entity. For example, for the entity, Horse, each
individual horse (instance) must be uniquely
identifiable in the data model.
Each entity can be represented in a diagram by a box containing
the name of the entity. The name is in singular and shown in all
uppercase letters. This tutorial includes the following entities:
 Identify Business Relationships Between
Entities
• The second step in entity relationship
modeling is to identify the business
relationships that exist between the entities. A
business relationship (or relationship for short)
is a named, significant association between
two entities.
• The relationships present in the CA 2E data
model at this point can be represented as
shown.
 Identify Attributes and Unique Identifiers
for the Entities
• The third step of entity relationship modeling involves the
following:
• Identifying the attributes (fields) that belong to each entity
• Selecting the attributes that serve as a unique identifier for
each entity
• This unique identifier is also known as the primary key for the
entity.
• Normalizing the entities
• Generalizing the entities

The following sections discuss each of these in more detail.

 Identify the Attributes for Each Entity
• An attribute is any detail that serves to qualify,
identify, classify, quantify, or express the state of an
entity. An attribute can also be any description of a
thing of significance. The attributes must describe
the entity against which they are shown.
• Reviewing the data elements you identified during
requirements analysis, and taking into consideration
the entities you have already identified, it is possible
to identify the attributes. List the attributes beside
the appropriate entity as in the following table:
Entity Attribute
COURSE Course Code
Course Name
HORSE Horse Code
Horse Name
Horse Gender
Horse Date Of Birth
JOCKEY Jockey Code
Jockey Name
Jockey Gender
SIRE Sire Code
Sire Name
Sire Date Of Birth
DAM Dame Code
Dam Name
Dam Date Of Birth
RACE Course Code / Course Name / Race Date / Race Time / Race Name
(read left-to-right Going Conditions / Distance / Prize Money / Horse Code
order as up-to- Horse Name / Horse Gender / Date Of Birth / Jockey Code
down) Jockey Name / Finishing Position / Handicap / Entry Position
Select Each Entity’s Unique Identifier
• Each entity must be uniquely identifiable so
that each instance of the entity is separate
and distinctly recognizable from all other
instances of that entity. The unique identifier,
also known as the primary key, can be any of
the following:
• An attribute
• A combination of attributes
• A combination of relationships
• A combination of attributes and relationships
• A primary key should consist of the fewest
number of attributes necessary to make every
instance of the entity unique. Review the
attributes of each entity and select the
primary key for each entity. Primary keys are
identified in the following table:
Entity Attribute Primary Key
COURSE Course Code Course Code
Course Name
HORSE Horse Code Horse Code
Horse Name
Horse Gender
Horse Date Of Birth
JOCKEY Jockey Code Jockey Code
Jockey Name
Jockey Gender
SIRE Sire Code Sire Code
Sire Name
Sire Date Of Birth
DAM Dame Code Dam Code
Dam Name
Dam Date Of Birth
RACE Course Code… Course Code
Race Date……. Race Date
Race Time……… Race Time
 Identify Foreign Keys
• Note that the RACE entity contains the primary keys of
the HORSE (Horse code) and JOCKEY (Jockey code)
entities. The Horse code and Jockey code are needed as
attributes in the RACE entity to identify the horses and
jockeys that competed in each race. However, neither
the Horse code nor the Jockey code are needed to
identify the RACE entity; in other words, neither Horse
code nor Jockey code are primary keys of RACE. Such
non-key attributes of an entity that are primary keys of
another entity are known as foreign keys.
Entity Attribute Primary Key

COURSE Course Code

Course Name
H Course Code

HORSE Horse Code Horse Code

Horse Name
Horse Gender
Horse Date Of Birth
JOCKEY Jockey Code Jockey Code
Jockey Name
Jockey Gender
SIRE Sire Code Sire Code
Sire Name
Sire Date Of Birth
DAM Dame Code Dam Code
Dam Name
Dam Date Of Birth
RACE Course Code/Course Name/Race Course Code
Date/Race Time/… Race Date
Horse Code/Jockey Code… Race Time
 Normalize the Entities
• Normalization of data is a procedure that ensures that a data
model conforms to some useful standards.
• For data and entity relationship models, the following
standards have been defined to minimize duplication of data,
to provide the flexibility necessary to support different
functional requirements, and to enable the data model to be
mapped onto a relational database design effectively.
• Eliminate repeating data groups
• Eliminate partial key dependencies
• Eliminate non-key dependencies (attributes that depend
upon another non-key attribute in the entity)
• Applying these steps causes the entities and
attributes to be redefined as follows:
• This process has resulted in the creation of
another entity named RACE ENTRY. Now our
Entity Relationship Diagram looks like this.
Note that K indicates a key attribute and A
indicates a foreign key (non-key attribute).
 Generalize The Entities
• At this point, there is another source of
redundant data, namely, the HORSE, DAM,
and SIRE entities. A horse could appear in two
of these three entities since a horse could
both compete in races and also be a Dam or
Sire. This situation can be resolved by
combining these three entities into just one:
HORSE. This process is called entity
generalization.
 Data Model Diagram
• The relationships that are identified in the
entity relationship diagram can be translated
to CA 2E relations. There are eight different CA
2E relations, four of which are commonly
required. The purpose of the basic relations
will be explained in the course of this tutorial,
and more details may be obtained from the CA
2E manuals. The CA 2E Data Model Diagram
for this horse race application looks like this:
• Having identified the entities (files), attributes
(fields), and relationships (relations), we are
ready to specify and define them within the
data model. This process is illustrated in the
following topics.
 Relations
• In this topic you will enter simple relations, define new CA 2E objects
for use in the relations, and display the CA 2E entries arising from the
relations.
• New terms introduced:
• CA 2E relation
• Has relation
• Known by relation
• Owned by relation
• Refers to relation
• CA 2E model object
• file, file attribute
• field, field attribute (data type)
• file entry
• New screens are introduced:
• Edit Database Relations
• Define Objects
• Edit File Entries
• You will specify relations to define the HORSE,
COURSE, JOCKEY, RACE, and RACE ENTRY
entities.
 Overview
• The first step in using CA 2E is to define your basic data model. Do
this by typing a number of relation statements to define the entities
in your data model.
• Relation statements have the form:
• Object + Relation + Object
• where:
• Object is an CA 2E model object. Model objects are used to
represent real world entities, such as COURSE, HORSE, or RACE.
There are several different types of CA 2E model objects. Initially we
need only consider two types: fields (items of data) and files. In
general, the entities we identified will become files and the
attributes we identified will become fields.
• Relation is an CA 2E relation type. The CA 2E relations establish the
relationships between fields and files, and files and other files.
The Edit Database Relations Panel
• When you enter your data model, the first panel you see is the
Edit Database Relations panel. This panel is the top-level panel in
CA 2E.
• Note: If you have not already entered your model you can do so
now by entering the following command on any i OS Command
Entry line.
• YSTRY2 MYMDL
• Using the Edit Database Relations panel, you may enter relation
statements that declare the entities in your data model. The
panel has three main columns in which the relations are entered.
These columns are labeled Object, Relation, and Referenced
object.
 Entering Relation Statements
• Working top down, define the most basic entities in
your data model: COURSE and RACE.
• To do this you will use three different CA 2E relations:
• Known by Declares a field that is part of the primary
key that uniquely identifies a file
• Has Declares a non-key field (attribute) on a file
• Owned by Specifies a relationship between two files;
the primary key of the owning file becomes part of
the primary key of the owned file
• For example, in the tutorial model, RACE is
Owned by COURSE. COURSE is uniquely
identified by a Course code. Since RACE is
Owned by COURSE, each RACE is uniquely
identified by a combination of the COURSE at
which it is run, a date, and a time. As a result,
the primary key for RACE consists of Course
code, Race Date, and Race Time.
• You can use the DUP key (indicated by the string of ∗‘s in
the above panel) to reduce the amount of typing. When the
cursor is in a field and you press the DUP key, values from
the previous line will be duplicated on the line below when
you press Enter.
• You only need to type the first letter of a relation; for
example, you can type K or O in place of Known by or Owned
by, respectively.

• Press Enter after entering all the relations shown.

Validation of Relation Statements
 Define Objects

•In addition, fields can be assigned as:

•CDE - Key Fields
•ATR - Non Key Fields.
 Specifying Object Attributes
• Using the Define Objects panel, you must specify an object attribute for
each new object. You can view a list of the available object attributes by
typing ? in the object attribute field. Object attributes enable CA 2E to take
design defaults.
• For files, the object attribute specifies a file type, which will be one of the
following in this tutorial:
– – Reference file (REF) for relatively static master files
– – Capture file (CPT) for transaction files
– In the example, COURSE and RACE are Reference (REF) files.
• For fields, the object attribute specifies a data type. (Another term for data
type is field type.) For example, Course code is of type CDE, and Course
name is of type TXT.
– The data type causes CA 2E to automatically assign default characteristics to a field;
for example, length and display format. You can override these defaults later.
 Specifying Object Attributes
(Continued)

• In this tutorial you will use the following data types:

• CDE—Alphanumeric code field
• TXT—Descriptive text
• VAL—Monetary value
• DT#—ISO date
• TM#—ISO time
• STS—Status
• QTY—Quantity
• NBR—Pure numeric field value
Specifying Object Attributes
(Continued)
 File Entries
• CA 2E automatically resolves each relation you entered on the Edit
Database Relations panel into one or more file entries. A file entry
indicates the presence of a field on a file. In other words, each CA 2E
relation causes one or more fields to be created on a file.
• Some examples are:
• The Known by relation causes a key field to be created on the named file
• The Has relation causes an attribute to be created on the named file
• The Owned by relation causes one or more key fields to be created on
the owned file.

• You can view how CA 2E has resolved your relations by displaying the
entries for the file.
 File Entries for COURSE
• You can view the entries on the COURSE file
using the Edit File Entries panel. From the Edit
Database Relations panel, type E next to any
of the relations for the COURSE file.
File Entries for RACE
 Adding More Relations
• You may now add other files to the data
model.
 Declaring More Files
• You can define the RACE ENTRY, HORSE, and JOCKEY files
using the Known by, Has, and Owned by relations as you
did for the COURSE and RACE files.
• In addition, since RACE ENTRY requires references to the
HORSE and JOCKEY files, you will also use the Refers to
relation. The Refers to relation specifies a relationship
between two files. It causes the key entries of the
referenced file (HORSE and JOCKEY) to become foreign keys
of the referencing file (RACE ENTRY).
• Note that a file may reference another file more than once,
as shown later in this tutorial.
 Defining Objects
• Press F10 to define the new objects.
• The Define Objects panel displays with the
object attribute column blank.
• File Attributes
– Specify the appropriate object attributes, in order
to define the new objects to CA 2E. This requires
the following two additional attributes:
• CPT—Database capture file
• NBR—Pure numeric field value
Defining Objects
(Continued)
 Deleting Relations
• You can delete a relation from the data model
by typing D against the relation. Once deleted,
retyping them can reinstate relations.
 Documenting Relations
• To obtain a listing of the relations that you have entered, use the
Document Model Relations (YDOCMDLREL) command. First press
F17 from the Edit Database Relations panel to display the Display
Services Menu. Then do either of the following.
• Press F9 to display a command entry line, type the YDOCMDLREL
command, and press Enter
• Select the Documentation menu option to display a list of
documentation commands and select Document model relations

• When you finish, press F3 until you return to the Edit Database
Relations panel.
 Field Details and Conditions
• Having entered relations to define your data
model, you must now add more detailed
information about the fields. This includes defining
simple validation rules and specifying any required
overrides to the defaults CA 2E assigned for field
properties; for example, field length.
• This topic describes the field details and how to
add field condition information to your data model.
 Field Details and Conditions
(Continued)
• New terms introduced:
– field condition
– VAL condition type
– LST condition
– check condition
– selection line
• New panels introduced:
– Edit Field Details
– Edit Field Conditions
– Edit Field Condition Details
 Field Details and Conditions
(Continued)
• Overview of Field Details
• Field details specify the properties of a given field, such as length, text,
validation, and implementation name.
• Overview of Field Conditions
• Field conditions define allowed values for fields. Conditions record both
the values that a field may take and the meaning that the values
represent.
• Conditions can be used in a number of ways. The most common uses of
conditions are:
• Validating the entry of data
• Specifying selection or omission of data from a logical view of the data
• Specifying the processing conditions in a program that operates on the
data
 Field Details and Conditions
(Continued)
• Field Details
• To obtain the field details for a field, select the
appropriate relation statement line on the Edit
Database Relations panel and type Z2 against
this object. The details of the referenced
object will be displayed. Note that the Subfile
selector options, Z1 and Z, both give details of
the first object in the relation.
Field Details and Conditions
(Continued)