COOL:2E

COOL:2E previously known as SYNON has been

taken over by Computer Associates.
We will use the word SYNON from here onwards.
Synon is basically a Code generator.
It generates code depending on the language set
while installing Synon.
It runs on AS/400 machine.
Without AS/400 it is not going to work.
As the language in the background is either
RPG/COBOL/RPGLE, that is why it needs the
corresponding compiler.

SYNON Commands
Any command in Synon starts with Y. e.g.
YSTRY2, Y2, YEDTMDLLIB,
YDSPMSLVAL,YBLDLIBLST , YHLLGENetc.
Synon objects are not AS/400 objects e.g. Files,
Fields, Relations etc.
Synon follows RPM & not Waterfall
methodology.
Synon is a Data driven approach and not process
driven approach. Here you first define the data and
process is based on it.

RPM-An Iterative Approach

Requirement
Design
Data Modeling
Designing Function
Prototyping

Generating / Compiling

SYNON
Data Model contains Files, Fields and their
relations.
Design Model contains data model and all
other functional specifications.

SYNON
ADDLIBLE Y2SY
ADDLIBLE Y1SY
YCRTMDLLIB
MDLLIB(XXX)
SYSTEXT(My Model)
YSTRY2
XXX

SYNON
Modes available:
Designer, Programmer
Till version 6.0 , at one time only one Designer
can go into the Data Model. At that time no body
else should be using the model. This is to
synchronies the model.
In version 7.0 any no. of people can go as a
Designer. It depends on the setting in the model
value. There is a data area in which this
information is kept. After making changes in the
model , the model has to be synchronized.
Otherwise it will not be reflected to other
programmers.

Objects

Files
:
Entity
Fields
:
Attribute
Key Field:
CDE
NonKey :
ATR
First thing required is to Define your Entity and
Attributes.
DFN----Defined as for any Entity
Here you mention whether the Entity is REF or CPT.
Also mention whether the Attribute is KEY or
NonKey Field.

SYNON FILES

REF----- Master File

CPT-----Transaction File
RCD-----Flat File (PF only)
STR------Audit Log (no PF)
Synon Shipped files :
*Message, *Array, *Pgm, *Job, etc.

SYNON RELATIONS

File to File Relations

Owned By
O
Refers to
R
Extended By
E
Includes
I

Key Field
Non Key Field
Virtual Field
Audit fields

SYNON RELATIONS

File to Field Relations

Known By
Key fields
Has
Attributes
Qualified By
Key Fields
for Date, Time

SYNON DataTypes
Different data types are available for attributes:
Key field
CDE
NonKey
ATR
For fields:

CDE
TXT
NBR
STS
DTE
TME
VAL

Referenced Field

An attribute can refer to other attribute as

well. This is called Referred field.

SYNON A/C PATHS

PHY
UPD
RTV
QRY
SPN
RSQ

Physical A/C path

Update A/C path
Retrieve A/C path
Query A/C path
Span A/C path
Re-sequence A/C path

Physical A/C path

Once the Entity is defined along with the

attributes and all its relations are resolved ,
either the access path can be created from
the designer mode or from the programmer
mode.
Access paths can be created over files that
have been defined, but before the functions
associated with the access paths are created.

Physical A/C path

The application uses A/C paths to retrieve,
sequence or update data from the physical file.
Synon 2/E creates defaults A/C paths for files
when it has been defined.
A/C paths defines the physical file and/or the
logical views of that file.
Following can be specified for Entity:
The order in which record should be retrieved from file
Which fields will be present
Select/omit criteria for retrieving data from files

Physical A/C path

A single format file containing the fields derived
from the resolution of all the relations on a file. It
is
Unkeyed
Has no virtual fields
Is created automatically by Synon2/E for every defined
REF or CPT file
Is not referenced directly by functions
No additional PHY is allowed
Is created in a model if an existing physical file is
retrieved into the model through assimilation
YRTVPFMDL

Update A/C path

A uniquely keyed, single format a/c path that
describes a view to the function for updating the
file.
Is always keyed on the fields that identify the file. Those entries
arise from the resolution of the key relations
Has no virtual fields
Is created automatically
Additional UPD can be created. But which have a subset of the
fields defined by the relations. It is very seldom required.
Additional UPD required in functions that update only some fields
from a file
Not associated with PHY

Retrieve A/C path

A uniquely keyed, single format a/c path that functions can use to
retrieve records from a file.
Is always keyed in exactly the same way as the UPD a/c path using
the relations of the based on file
Allows virtual fields on the a/c path
Is automatically created
Is associated with UPD. Done by Synon.
Can be edited or trimmed to drop some or all non-key fields from
the record layout
Select/omit criteria
Can be set not to pickup virtual fields
Additional

Resequence A/C path

A uniquely or non-uniquely keyed, single format a/c path.
It must be created explicitly.
Defaults to those keys defined by the key relations for
the based-on file, but allows them to be overridden to
an alternative key sequence that does not need to be
unique
allows virtual fields to be specified on the a/c path
Is associated with a RTV a/c path that points to an
associated UPD a/c path
Additional RSQ allowed with any key sequence, any
virtual fields, select/omit criteria

Query A/C path

It specifies a keyed, single format access path to describe to functions
how records are to be retrieved from a file.
Must be created explicitly

allows virtual fields to be specified as key and non-key fields on

the a/c path

Can use virtual fields as key fields
Is used with DSPFIL, SELRCD, RTVOBJ, PRTOBJ & PRTFIL
Alternate Key sequence
Is associated with RTV which inturns is associated with UPD
Additional QRY allowed. Each can contain a different
combination of data fields and virtual fields, a different set of
select/omit criteria, and an alternative key sequence
Has PF, LF, CLP

Query A/C path

Logical file, which is based on the physical

file whose data is being referenced
Physical file which never contains data and
is used to define a record format and keys to
any HLL generated for a function based on
this a/c path
CL programs which executes OPNQRYF

SPAN A/C path

It specifies a keyed multi-format. It can be used to describe to the
EDTTRN,DSPTRN how records are to be retrieved from a pair of
related files. These files posses a common foreign key. These files
must be related by an Owned by or Refers to relation. It must be
created over the owning or referred to file
Defaults to those keys defined by the key relations of the based on files
but can be overridden to an alternative key sequence
Must be created explicitly
Is associated with a RTV a/c path which in turn is associated with an UPD
Allows explicit selection of multiple access paths formats
Additional SPN can be created
Two files should have common keys and the second file can have more
keys but the sequence of common keys should be same

Virtual Field
To be a virtual field, 2 files should have either Owned by
or Refers to or Extended By relation.
Virtual field is only for output.
Virtualization is done only when a field is declared
somewhere and it is required for display.
It can also be used in case of adding a new field in the
Entity.
Virtualization doesn't mean it is going to be added in the
access path. It has to be added explicitly in the A/C path.
Virtual not allowed for UPD and RTV.

A/C path maintenance

A/C path can be Unique(U),FIFO, LIFO,

FCFO or Undefined
I-IMMED, D-DLY, R-RBLD
DDS or SQL can be set in the model to
generate A/C path.

Generation/Compilation
Once the A/C path is defined or created, either by the
system or programmer/designer, it has to be generated. J/G
is the compilation option where J is for batch compilation
and G is for interactive compilation. Before compiling if
you try to see the DDS there will be nothing . As soon as
you select J for batch generation, a member will be created
by the system and spool file is generated by the name
YGENSRC. After that the system will automatically create
an object by the same name . And now it becomes AS/400
objects. In case of interactive compilation, system will
create the member and the object in one shot. If any error
then check the spool file.
Every Access path should be compiled or it should be an
object.

Example
A defined as(DFN)
A
If you don't define it at the beginning you can do it later as
well. After entering all relations for files, system says not
defined.
A
Known By(K)
B(Key field)
A
Has
C(Non key field)
A
Has
D(Non key field)
A
Owned By(O)
Z(Key field)
A
Refers to
X(Non key field)
A
Includes
J(Non key field)
A
Qualified By
X(Key field)

Example
Take F10 to define objects. Once it is done then define
data types for attributes.
F3 to exit and then system asks for whether model has to
be synchronized. It is preferred to synchronize the model
so that this can be seen by others.
Now Z into file which will generate 3 A/C paths i.e.
PHY,UPD,RTV by default . J for batch generation.
F into file will generate functions .

Locking on Access Path

Synon supports 2 types of object locks:
Temporary Lock
are imposed automatically by Synon2/E to prevent 2
users from working on the same object at the same
time. Lock is cleared by the system when object is no
longer in use. This lock now prevents from accessing
the object. L to check for lock.
In case of abnormal termination, lock remains on the
object

Locking on Access Path

Permanent Lock:
Can be placed by the designer on any object to prevent any
modification or generation of that object. It stays in effect even if
the object and model are not used. It can be removed by the
designer. For designer to add and remove permanent locks, they
must have *OBJOWN rights to the YMDLLIBRFA data area.
This data area is also used to check how many people are
accessing the model

Access Path Details

These are the various implementation

options specified for a/c paths. These
options include changing source names and
text, allowing selection and omission
criteria, and specifying generation mode i.e.
DDS , SQL (which can be controlled by the
Database File Generation YDBFGEN),
Unique Key sequence, access path
maintenance etc.

Access Path Format Entries

It shows which fields are present on the

access path, which of those fields are key
fields and the order of those keys. SPN will
have at least 2 formats. Other access paths
will have only one format.

Access Path Relations

It is set or subset of a files relations that

apply to the access path. It will have Key
field relations, non key field relations and
virtual field relations.

Access Path Auxiliaries

These are 3 different OS/400 objects used to

implement a query access path for DDS
object. It includes LF, PF, CLP.

SYNON FUNCTIONS
F into file will generate functions for that particular entity.
REF file will have 5 functions generated by the system and CPT will
have 3 functions by the system .
Functions are nothing but programs. These programs are generated in
the language depending on the model setting i.e. YHLLGEN.
There are different types of functions
EXTERNAL FUNCTION
INTERNAL FUNCTION
MESSAGE FUNCTION

External Function is nothing but a Separate program.

Internal Function is a subroutine.

SYNON FUNCTIONS

DSPFIL
DSPTRN
DSPRCD
EDTFIL
EDTRCD
EDTTRN
PMTRCD
SELRCD
PRTFIL
EXCEXTFUN
EXCUSRPGM

RTVOBJ
CHGOBJ
CRTOBJ
DLTOBJ
PRTOBJ
EXCINTFUN
EXCUSRSRC

FUNCTIONS
DSPFIL,DSPRCD,DSPTRN,EDTFIL,EDTTRN,EDTRCD
,PMTRCD,SELRCD are display functions.
PRTFIL,PRTOBJ are print function.
RTVOBJ,CRTOBJ,CHGOBJ,DLTOBJ are database
functions.
EXCUSRPGM is a user written program in any language.
EXCUSRSRC is an internal function written by user. But
is has to be with same language in which it is written or
called.
EXCEXTFUN is mostly used for Batch processing.
EXCINTFUN is used for LDA processing or date
validation.

FUNCTIONS
CRTOBJ,CHGOBJ,DLTOBJ use only UPD A/C path.

RTVOBJ can use any A/C path but UPD.

Display File Functions use any A/C path but UPD.
Print function can use any A/C path but UPD.
Query A/C path is only used with DSPFIL, SELRCD, PRTFIL AND
PRTOBJ.
PMTRCD , SELRCD can use any A/C path but UPD.
EXCEXTFUN / EXCINTFUN doesn't use any A/C path. If A/C path
is used in EXCEXTFUN then it is only used for documentation
purpose. An A/C path can be passed as a parameter to any function.
EXCUSRSRC / EXCUSRPGM does not need any A/C path.

FUNCTION OPTIONS
Many Function Options are available depending on the Function e.g.
Database function, Display Function, Print Function, External
Function, Internal Function.
These function options are required to manage the function.

Commitment Control Env.

Master , Slave, None
Subfile Option END, MORE, +
Reclaim Resource
Closedown program
Duplicate parameter (only allowed with EXCINTFUN / EXCEXTFUN)
Create Record, Change Record, Delete Record, Create Transaction, Delete
Transaction
Prompt
Exit after Add

Function Parameter
There can be a maximum of 9 parameters passed to any
function. If you want to pass more than 9 then use Array.
Role

Input(I)
Output(O)
Both(B)
Neither(N)
Neither parameter is not allowed with EXCUSRSRC /
EXCUSRPGM.
It is used in case of changing only certain fields from the database
It is used as an output field on the display screen
It can be used as a WRK Context.

Function Parameter

Parameter can be passed as

RST Restrict
Key Field
POS Position
Read from that
record(SETLL)
MAP Map
pass the value as it is (
used in case of date)
VRY Vary
change the length while
receiving

Function Parameter

A parameter can be passed as a FILE or

FIELD.
If File then mention the file name along
with the A/C path name.
If field then *FIELD with the field name.

CONTEXT
A context is nothing but the location of a field. There are
several contexts available here.
DB1
DTL
DB2
PAR
RCD
NLL only for output
CTL
WRK
LCL
JOB
PGM

ARRAY
Array is same like what we use in RPG.
It is a shipped file.
It has maximum of 1000 elements . The default is
100. It has to have a key . Default is Ascending. It
could be Unique or No unique.
It has RTVOBJ, CRTOBJ, CHGOBJ, DLTOBJ.
Functions can be created on *Array file.

Features
To retrieve an existing application on
AS/400 to Synon, use YRTVPFMDL which
will copy the DDS into the model.
Commitment Control is taken care by
Synon.
Inter-dependency among all objects
Uses native Configuration Management
Object Reference *PRIVATE/*PUBLIC

LIMITATIONS
Mathematical Calculation
Cannot change the Action diagram
Etc.