SYNON

File Type
The file type must be one of the Synon/2E valid file types. Depending on how it is intended to be
used, a file can have a type of capture (CPT), reference (REF), or structure (STR).
Capture and reference files are database files; structure files are non-database files. Whether a file is
capture or reference depends on the role of the fields that make up that file.

Capture Files
Capture files should contain regularly recorded transactional data that your application uses. You
should select a CPT file type for files that have a high volume of transactions and require constant
update. An example of a CPT type file is an Order file. An order file has many orders that are
processed daily.
Synon/2E provides three types of default functions for capture files. When you specify a file as a CPT
type file, three internal functions are created to allow you to create, change, or delete the records in
the file. They are Create Object (CRTOBJ), Change Object (CHGOBJ), and Delete Object (DLTOBJ).

Reference Files
Reference files are master files containing basic data that your application uses. You should select a
REF file type for files that contain nonvolatile information; for example, a Customer file. A customer
file contains detailed information about a customer such as name, address, telephone.
In addition to the three default functions created for a capture file, a reference file has two other
functions which allow you to maintain a file or select a record from a list. They are Select Record
(SELRCD) and Edit File (EDTFIL).

Structure Files
A structure file contains a group of fields. These fields can be incorporated into other files by the use
of the Includes relation.

File to File Relation :

Relation Description
Defined as Declares that the file exists
Owned by specifies that the keys of the owning file are to become major
key fields of the owned by file.
Extended by declares the file to have a one-to-one or oneto- none
relationship with another file.
Refers to causes the key fields of the referenced file to be included as
non-key fields on the referring file.
Includes causes fields from the referenced file or included structures to
be included as attributes in the referencing file.

File to Field Relation :

Relation Description
Known by declares the field to be present as a key field on the file.
Qualified by declares a field to be present on a file as a key field; is used
with continuous variables.
Has declares the field as a data field on the file

Relation Usage Groups:

Usage Type Relation Used for
Definition Defined as File-to-file relationship
Key Owned by File-to-file relationship
Known by File-to-field relationship
Qualified by File-to-field relationship
Attribute Refers to File-to-file relationship
Includes File-to-file relationship
Has File-to-field relationship

1
Other Extended by File-to-file relationship
Owned by Relation
The Owned by relation denotes a parent-child relationship. The primary key(s) of the owning file
become part of the primary key of the owned by file. For instance, if Order Detail is Owned by Order,
the key of Order, Order code, is the high order key of Order Detail.
The file of an Owned by relation must be of type REF or CPT. All the key fields of the owning file are
incorporated as high order keys in the owned file. A file can have more than one Owned by relation.
A file can have only Owned by relations to define its keys. It is not necessary to have other key
relations, such as Known by or Qualified by.
The Owned by relation allows you access to any of the fields on the owning file. If a field is accessed
on the owning file, it creates a virtual field on the owned file. Virtual field values
can be used but cannot be updated. An Owned by relation can have its description clarified by using
the For text extension.

Examples of Using Owned by Relations

Example 1: Orders within Company. The Owned by relation may be used to specify the high order
key of a file. Let us say that you operate a multi-company sales ledger and that
all orders are within company.
A Company could be defined as follows:

FIL Company REF Known by FLD Company Code CDE

FIL Company REF Has FLD Company Code TXT

An Order could be defined as follows:

FIL Order REF Owned by FIL Company REF

FIL Order REF Known By FLD Order Code CDE
FIL Order REF Has FLD Order Date DT#

This specifies that the key of the Company file is the high order key of the Order file which would
result in the following entries:

Company Order
K Company Code K Company Code
Company Name K Order Code
Order Date

Example 2: Orders within Company within

Country. Owned by relations may be used to construct a hierarchy. In the example given above, the
Owned by statement asserts that the keys of Company are the high order keys of Order. If you later
decide that a Company is only unique within Country, then adding Country to the Company file with
an Owned by relation will automatically add it to the Order file. The presence of the relation stating
Order is Owned by Company causes the automatic addition. A Country could be defined as follows:

FIL Country REF Known by FLD Country Code CDE

FIL Country REF Has FLD Country Name TXT

FIL Company REF Owned by FIL Country REF

FIL Company REF Known By FLD Country Code CDE
FIL Company REF Has FLD Company Name TXT

The definition of Order requires no change:

FIL Order REF Owned by FIL Compay REF

FIL Order REF Known By FLD Order Code CDE
FIL Order REF Has FLD Order Date DT#

2
 This would result in the following entries. You can see the Country code has been introduced
automatically onto the Order file:

Country File Company File Order File

K Country Code K Country Code
Country Name K Company Code
Company Name
K Country Code
K Company Code
K Order Code
Order Date

Qualified by Relation
The Qualified by relation can be used to qualify a file identifier by one or more variable factors such
as the date, the time, or a sequence number.
The Qualified by relation would typically be used for entities which represent a continuum of values.
An example might be prices or currency rates which come into effect on a given date
and prevail for a while. The identification of such entities might be qualified by a date. Using Relations
Another common usage would be to describe step functions, such as volume discount breaks or tax
ranges, which similarly come into effect at a certain threshold and prevail until the next threshold is
reached.
Qualified by relations are further specified to tell whether the record retrieval is to be *PREVIOUS, to
retrieve the nearest record less than or equal to the search value, or *NEXT, to
retrieve the nearest record greater than or equal to the search value. Note that these values are
mutually exclusive; you cannot specify both on the same file. To specify these values,
type a + in the subfile selector of the Qualified by relation and press F5.
Qualified by relations are similar to Known by relations: they are resolved by adding the named
field as a key field to the file containing the relation. The Qualified by relation, however, has a special
property: a reference to a file containing a Qualified by relation may be redirected. The field usage
required for the field of a Qualified by relation needs to be ATR and not CDE.

Examples of Using Qualified by Relations

Example 1: A Qualified File - Product Prices. Your company has a number of products:

FIL Product REF Known by FLD Product Code CDE

FIL Product REF Has FLD Product Description TXT

Your product prices change from time to time. You might then describe a Product price file as follows:

FIL Product Price REF Owned by FIL Country REF

FIL Product Price REF Qualified By FLD Effective Date DT#
FIL Product Price REF Has FLD Price TXT

Thus for each change of Product price you would have a separate record, a state of affairs represented
by the following entries:
Example 2: Using a Qualified File - Product Prices.
If you now wish to use the Product price in an Order detail file, you could define an Order file as
follows:

FIL Order REF Known by FLD Order Number CDE

FIL Order REF Has FLD Order Date DT#
FIL Order REF Has FLD Order Status STS
FIL Order REF Refers to FIL Customer REF

And, define an Order detail file as follows:

FIL Order Detail REF Owned by FLD Order CDE

FIL Order Detail REF Known by FLD Order Line no DT#

3
FIL Order Detial REF Has FLD Order quantity STS
FIL Order Detail REF Refers to FIL Product Price REF

This would result in the following entries:

Order Detail File

K Order Number
K Order Line Number
Order Quantity
Product Code
Effective Date

The fields on the file are the same as if you had used a Known by relation instead of a Qualified by
relation for the Effective date. However, additional processing logic is created for the Qualified by
relation.
The difference in using a Known by instead of a Qualified by relation is that you will have a code
generated that refers to the correct product price. The code is based not on an exactvalue match of
the effective date but on the closest previous value of the effective date.

Extended by Relation
The Extended by relation declares a file to be an extension of another file. The relation records an
association that is not expressed by any other relation, and is, in particular, a one-toone or one-to-
none association between the identifiers of two files. Using Relations When it is used with an existing
Owned by relation, the Extended by relation has no effect on the entries of the file being extended;
it merely makes the fields from the extended file available for selection as virtual fields on the file
being extended. A virtual field is logically present in a view of a file, though it physically resides in
another file.

For more information:

on virtual fields, refer to this chapter, Adding Virtual Fields to File-to-file Relations topic.
A one-to-none relation denotes a relation where an instance exists in one file and the corresponding
instance does not exist in another file. For example, the Product file could be
extended by the export details file. Some products may be exported and some may not. This would
mean that a product record may or may not have an associated record in the export
detail file.

Note: It is not recommended that you use the Extended by relation unless the extending file is
Owned by the extended file, as unpredictable results may occur during source code generation.
Example of Using Extended by Relations
Your basic Customer information consists of the following fields:

FIL Customer REF Known by FLD Customer Code CDE

FIL Customer REF Has FLD Customer Name TXT
FIL Customer REF Extended by FIL Customer Detail REF

You might place additional details about Customers in another file called Customer detail:

FIL Customer Detail REF Owned by FIL Customer CDE

FIL Customer Detail REF Has FLD Credit Limit VAL
FIL Customer Detail REF Has FLD Managing Director TXT

Customer File Customer Detail

K Customer Code
K Customer Code Credit Limit
Customer Name Managing Director

4
 If you wish to create a function that brings both Customer and Customer detail together, you need to
build an access path that contains fields from both files. If you were doing this on the
Customer detail file, this would not present a problem since you could specify virtual fields on the
Owned by relation:

FIL Customer Detail REF Owned by FIL Customer CDE

VRT Customer Name TXT
FIL Customer Detail REF Has FLD Credit Limit VAL
FIL Customer Detail REF Has FLD Managing Director TXT

However, if you wish to attach your function to the Customer file, you would not be able to obtain the
customer details unless you had an Extended by relation. Using the Extended by relation, you can
specify virtual fields as follows:

FIL Customer REF Known by FLD Customer CDE

FIL Customer REF Has FLD Customer Name TXT
FIL Customer REF Extended by FIL Customer Detail REF
VRT Credit Limit VAL
VRT Managing Director TXT

Each Customer may have only one Customer detail record: there is a one-to-one correspondence
between files. There are two implementation reasons why you might consider using the Extended by
relation rather than simply including the data from the extended file in the basic file: _ To save space.
If some data fields are only present on a minority of records, then it may be desirable to place the
rarely used fields into an Extended by file. _ To avoid recompilation of an existing system. If you
wish to add fields to an existing file that is already used by a large number of programs, you could
avoid level check problems by placing the extra fields in another file owned by the original file. An
Extended by relation would make the new file details available from the based-on file.

- Note: An Extended by relation effectively constrains an Owned by relation, which is normally one-
to-many, to be a one-to-one relationship. It is only appropriate to use the Extended by relation for
cases where a oneto- one or one-to-none relationship holds.

Refers to Relation
The Refers to relation specifies that a file references another file. A Refers to relation is resolved by
including the identifiers (keys) of the referenced file into the referring file as foreign key fields. The
Refers to relation allows access to any of the fields onthe referred to file from the referring file. If a
field is accessed on the referred to file, it creates a virtual field on the referring file. Virtual field values
can be used but cannot be updated. A virtual field is logically present in a view of a file, though it
physically resides in another file.

For more information:

on virtual fields, refer to Chapter 5, “Maintaining Your Data Model,” Adding/Modifying Virtual Fields
topic. A Refers to relation can have a For text extension to further clarify its description.

For more information:

on using For text and Sharing with Refers to relations, refer to this topic, Using For text and
Sharing with Relations subtopic.
The Refers to relation can be contrasted with the Includes relation which includes all fields from the
referenced file, and with the Owned by relation which is resolved into key entries
on the owned file.
- Note: Up to 60 Refers to relations can be placed on a file.

5
 Example of Using Refers to Relations
Where Order detail refers to Product, Product might be defined as follows:

FIL Product REF Known by FLD Product Code CDE

FIL Product REF Has FLD Product Name TXT

The Product could then be referenced elsewhere, for instance by an Order detail file:
FIL Order Detail REF Owned by FIL Order CPT
FIL Order Detail REF Known by FLD Order Line No NBR
FIL Order Detail REF Has FLD Order Quantity QTY
FIL Order Detail REF Refers to FIL Product REF

This would result in the Product code being added to the Order detail file as a foreign key field:

Product File Order Detail File

K Product Code K Order Code
Prodcut Name K Order Line No
Order Quantity
Product Code

Includes Relation
The Includes relation states that a file is to include fields that have already been declared as being
present in a structure file. The Includes relation allows the use of a group of fields or “a
data structure,” in several different files. Specifying an Includes relation causes all of the fields in the
included file to be present as non-key fields in the including file.

For more information:

on structure files, refer to this chapter, Using Files topic. Examples of Using Includes Relations
You have an Audit stamp structure file that is made up of three components:

FIL Audit Stamp STR Has FLD Date DT#

FIL Audit Stamp STR Has FLD Time TM#
FIL Audit Stamp STR Has FLD User ID CDE

You might wish to refer to the Audit stamp in a number of files. For instance, a product file:
FIL Product REF Known by FLD Product Code CDE
FIL Product REF Has FLD Product Name TXT
FIL Product REF Has FLD Product Quantity QTY
FIL Product REF Includes FIL Audit Stamp STR

For instance, an order file:

FIL Order REF Known by FLD Order Number CDE

FIL Order REF Has FLD Order Status STS
FIL Order REF Includes FIL Audit Stamp STR

This would result in the following entries:

Product File Order File

K Product Code K Order
Prodcut Name Number
Product Quantity Order Status
Date Date
Time Time
User ID User ID

6
 Adding Virtual Fields to File-to-file Relations
The fact that a relation exists between two files means that, given a record from one file, it is possible
to look for a corresponding record on the other file in order to obtain Using Relations
related data items. Synon/2E allows you to specify which data items are to be obtained through a file-
to-file relation by allowing you to specify virtual fields. A virtual field is a field which is present logically
in a view of a file although it physically resides in another file. Virtual fields can be specified on the
following relations:
Owned by
Refers to
Extended by

File to File Virtual Field

Relation

File Order Line REF Refers to FIL Product REF

VRT Product Name TXT

Virtual fields can be defined only in one direction on the relation. In Synon/2E, the file that can contain
virtual fields is the file where the relation is defined. For example, Division is Owned by Company.
Fields from the Company (owning file) can be virtualized to the Division (owned file). Fields from
Division cannot be virtualized to Company. Division contains the virtual fields. Division is where the
Owned by relation is defined. A virtual field may itself be a virtual field on the referenced file. You can
specify virtual fields for relations using the Virtual Field Entries panel. The example below shows how
virtual fields are added to a relation:
 On the Order file we could have the Customer name as a virtual field:

FIL Order CPT Known by 1 FLD Order Code REF

FIL Order CPT Has 2 FLD Order Date CDE
FIL Order CPT Has 3 FLD Order Status TXT
FIL Order CPT Refers to 4 FIL Customer
VRT Customer Name

 On the Order Detail file we could have both the Order information, including the Customer name
and the Product name as virtual fields:

FIL Order Detail CPT Owned by 1 FLD Order Code REF

VRT Order Date DT#
VRT Order Status STS#
VRT Customer Code CDE#
VRT Customer Name TXT
FIL Order Detail CPT Known by 2 FLD Order Line No CDE
FIL Order Detail CPT Has 3 FLD Order Quanity QTY
FIL Order Detail CPT Refers to 4 FIL Product REF
VRT Product Name TXT

 This would result in the following entries on the files:

Order File Order Detail

K Order Code K Order Code
Order Date V Order Date
Order Status V Order Status
Customer Code V Customer Code
V Customer Name V Customer Name
K Order Line No
Order Quantity 7
Product Code
V Product Name
Access Paths : An access path defines the physical file and/or the logical views of that file. When you
build one, you specify the following:
 the order in which you want to retrieve records from a file
 which fields will be present
 your select/omit criteria for deciding which records from the file will be retrieved by the access
path

There are 6 types of Accesspaths. They are

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

Physical (PHY) Access Path

A PHY access path is a single-format file containing the fields derived from the resolution of all the
relations on a file. This access path type
 is unkeyed.
 has no virtual fields.
 is created automatically by Synon/2E for every defined REF or CPT file.
 is not referenced directly by functions.
 allows no additional PHY access path to be created for a given Synon/2E file.
 is created in a model if an existing physical file is retrieved into the model through assimilation.

Examples
 Every Synon/2E file has one access path of type PHY, called Physical file by default.

Update (UPD) Access Path

An UPD access path specifies a uniquely keyed, single-format access path that describes a view to the
function for updating the file. This access path type
 is always keyed on the fields that identify the file. These entries arise from the resolution of the
key relations.
 has no virtual fields.
 is created automatically by Synon/2E for every defined REF or CPT file.
You can create additional UPD access paths, with the same keys as specified on the file, but which
have a subset of the fields defined by the relations. Additional UPD access paths are seldom required.
Examples
 Every Synon/2E file has a default Synon/2E UPD access path that will be called Update index by
default.
You can create other Synon/2E UPD access paths for use in functions that update only some fields
from a file, for example:
 Company address update only
 Batch status only

Retrieval (RTV) Access Path

A RTV access path specifies a uniquely keyed, single- format access path that functions can use to
retrieve records from a file. This access path type
 is always keyed in exactly the same way as the UPD access path using the relations of the based-
on file.

8
 allows virtual fields on the access path.
 is automatically created by Synon/2E for every defined REF or CPT file.
 defaults to the virtual fields of the based-on file's relations. These are then present on the access
path's relations.
 is associated with an UPD access path; Synon/2E automatically makes this association.
 can be edited or trimmed to drop some or all non-key fields from the record layout.
 can define select/omit logic to select or omit records from the access path.
 can be set not to pick up virtual fields.
You can create many RTV access paths for a given file. Each can contain a different combination of
fields and/or virtual fields and a different set of selection criteria, but all have the same key fields.
Examples
Every Synon/2E file has a default RTV access path, created for it automatically by Synon/2E, called
Retrieval index bydefault. For example:
 Retrieval index for the Company file You can define other Synon/2E RTV access paths for the
same
Synon/2E file. For example:
 Company active index (selecting active records only)
 Company summary index (with a subset of the file relations)

Resequence (RSQ) Access Path

A RSQ access path specifies a uniquely or non-uniquely keyed, single-format access path you can use
to describe to Synon/2E functions how records are to be retrieved from a file.
This access path type
 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 access path.
 is associated with a RTV access path that points to an associated UPD access path.
 defaults to the virtual fields of the based-on file's relations. These are then present on the access
path's relations.
You can create many RSQ access paths for a given file. Each can contain a different combination of
data fields and/or virtual fields, a different set of selection criteria, or an alternative key order.
Examples
 Company Known by Company code; RSQ by Company name
 Order Known by Order no.; RSQ by Order date
 Person Known by Person code; RSQ by Height

Query (QRY) Access Path

A QRY access path specifies a keyed, single-format access path you can use to describe to functions
how records are to be retrieved from a file. This access path type
 allows virtual fields to be specified as key and non-key fields on the access path.
 can use virtual fields as key fields.
 is available for use with the following function types: Display File, Select Record, Retrieve Object,
Print Object, and Print File.
 defaults to those keys defined by the key relations for the file, but allows them to be overridden to
an alternative key sequence.
 must be created explicitly.
 is associated with a RTV access path that in turn points to an associated UPD access path.
 defaults to the virtual fields of the based-on file's relations. These are then present on the access
path's relations. You can create many QRY access paths for a given file. Each can contain a
different combination of data fields and virtual fields, a different set of selection criteria, and/or an
alternative key sequence.
Examples
 Customer Known by Customer code; Order Refers to Customer and Customer name is a virtual
field on Order. Using a QRY access path, you can retrieve Order records in Customer name order.
 Product Known by Product code; Order line Refers to Product and Product name is a virtual field
on Order line. Using a QRY access path, you can retrieve Order line records in Product name order.

9
  Company Known by Company code; Employee Owned by Company and Company name is a
virtual field on Employee. Using a QRY access path, you can retrieve Employee records in
Company name order.

Span (SPN) Access Path

A SPN access path specifies a keyed multi-format access path. It can be used to describe to the edit
and display transaction functions how records are to be retrieved from a pair of related files. These
files possess a common foreign key. These files must be related by an Owned by or Refers to
relation. The SPN access path must be created over the owning or referred to file. This access path
type
 initially defaults to those keys defined by the key relations of the based-on files but can be
overridden to an alternative key sequence.
 allows virtual fields to be specified on the access path relations.
 must be created explicitly.
 is associated with a RTV access path that points to an associated UPD access path used to carry
out any updates to the based-on file.
 allows explicit selection of multiple access path formats.
 defaults to the virtual fields of the based-on file's relations. These are then present on the access
path's relations.
Examples
 Order and Order details (Order detail Owned by Order)
 Race and Entries (Entry Owned by Race)
 Orders for Customer (Order Refers to Customer) You can create many SPN access paths for a
given file. Each can contain a different combination of formats, a different set of selection criteria,
and/or an alternative key sequence. The RTV access path is used automatically by Synon/2E to tell
functions to retrieve any virtual fields specified for the SPN access path. This is necessary because
OS/400 does not support join logical multi-format files. Each trio of associated SPN, RTV, and UPD
access paths should contain the same access path relations. Otherwise,Synon/2E transaction
functions (EDTTRN and DSPTRN) based on the SPN access path will not operate correctly. EDTTRN
and DSPTRN functions use the first two formats ofa multi-format span access path.

Characteristics of Access Paths

The following table shows characteristics of Synon/2E access paths.

Access path type Real fields Key fields Virtual fields Virtual keys
PHY Physical Yes No No No
UPD Update Yes Relation No No
RTV Retrieval Yes Relation Yes No
RSQ Sesequence Yes User Yes No
QRY Query Yes User Yes Yes
SPN Span Yes User Yes No

Database Relations:-

Understanding Access Path Virtual Field Entries

An access path virtual field is a field that is logically, rather than physically, present on an access path.
Although the field does not reside on the based-on physical file, a view of it is available through the
relations that exist for the access path. It is possible to omit particular virtual fields from a particular
access path. The virtual fields for an access path can be selected only from among fields that have
been specified as virtual fields for the file. For example, if Customer file has five fields (Customer no.,
Branch name, Branch no., Customer name, and Customer address), and if Customer file Refers To
Branch file with only Branch name field as a virtual field, only the Branch name field is available as a
virtual field on all access paths of Customer file.

Arrays
This chapter contains procedures for defining, editing, renaming, and deleting an array. An array is a
structure that stores sets of data within a function. The contents of an array are available only as long
as the function is active. The structure has a defined layout and each entry (element) of the structure

10
has the same layout. Define this layout with any set of fields from the model, such as attribute, code,
and function fields. Use arrays to
 improve performance where a function requires repeated access and use of a finite number of
entries, such as table lookups.
 move between a field and a data structure.
 sequence a finite set of data by a set of unrelated key fields. Programmers (*PGMR) and designers
(*DSNR) can define arrays.

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

Synon/2E does not guarantee the sequence of equally keyed elements in a non-unique array. The key
also is defined as ascending or descending. This definition applies to the complete composite key.
When determining the key sequence, Synon/2E ignores the signs of any numerical fields in the key of
the array.

Arrays can be used only by the *CVTVAR built-in function and the following four standard data
function types:
Create Object (CRTOBJ) to add an element
Change Object (CHGOBJ) to change an element
Delete Object (DLTOBJ) to delete an element
Retrieve Object (RTVOBJ) to read an element or set of elements

There are a number of different function types which fall into the four classes listed below.

1. Standard Functions
i) Database Functions
ii) Device Functions
iii) User Functions
2. Built-in Functions
*ADD
*COMMIT
*COMPUTE
*CONCAT etc
3. Function Fields
Sum
Maximum
Minimum
Count
Derived
User
4. Message Functions
Send Error Message(SNDERRMSG)
Send Information Message(SNDINFMSG)
Send complete Message(SNDCMPMSG)
Send Status Message(SNDSTSMSG)
Retrieve Message(RTVMSG)
Execute Message(EXCMSG)

Basic Properties Of Functions.

1. Function Names
Length of the function can be upto 25charecters
2. Function Components

11
 i) Function Options
ii) Parameters
iii) Device designs
iv) Action Diagrams

The four database functions are:

Create Object (CRTOBJ)
Change Object (CHGOBJ)
Delete Object (DLTOBJ)
Retrieve Object (RTVOBJ)

Array Processing
A DLTOBJ with no parameters clears an array.
Note that you must define a key for an array even if the array holds a single element.

Defining Device Functions

The device standard header device functions are:

Define Screen Format (DFNSCRFMT)
Define Report Format (DFNRPTFMT)
The single-record device functions are:
Prompt Record (PMTRCD)
Display Record (DSPRCD)
Display Record 2 panels (DSPRCD2)
Display Record 3 panels (DSPRCD3)
Edit Record (EDTRCD)
Edit Record 2 panels (EDTRCD2)
Edit Record 3 panels (EDTRCD3)
The multiple-record device functions are:
Display File (DSPFIL)
Select Record (SELRCD)
Edit File (EDTFIL)
The single- and multiple-record device functions are:
Display Transaction (DSPTRN)
Edit Transaction (EDTTRN)
The printer device functions are:
Print File (PRTFIL)
Print Object (PRTOBJ)

Neither
No value is passed into the function for the parameter nor is a value returned for the parameter when
the function ends. Neither parameters are available for use as local variables within the function.

Identifying Default Parameters

CHGOBJ, RTVOBJ, DLTOBJ and CRTOBJ will be defaulted to “I” usage but, SELRCD will be defaulted to
“B”.

Identifying the Return Code

The best way to check for not equal to *NORMAL can be done using a CASE condition with an
*OTHERWISE or by using a compound condition.

Understanding the Role of the Parameter

Map Parameter
This parameter is automatically moved to a corresponding field on the receiving function's panel
design. If the field does not exist on the device design, it will be added to it. Specifying fields as
mapped Neither parameters is a way of adding fields to a panel design without the need to pass them
into the function. The Map option is ignored for reports and functions that do not have an associated
device design.

12
Note: If you make a change to the parameter entry on the Edit Function Parameters Detail panel, the
entry defaults to the Map role.

Restrictor Parameter
This parameter is used to restrict the records from a database file which can be displayed, changed, or
printed by the function. Restrictor parameters must be key fields on the access path to which their
function attaches and can only be used hierarchically; that is, major to minor key sequence. A minor
key can only be a restrictor parameter if all keys major to it are also restrictor parameters. Restrictor
parameters are automatically mapped and default to output on the panel, but may be changed to
input on DSPFIL, SELRCD, and EDTFIL function types.

For example, a function which displays a list of records (such as DSPFIL) could allow the user to select
a particular record with a line selection option. The keys of the selected record could be passed as
restrictors to another function (such as EDTRCD). The called function would then process only the
selected record.

Positioner Parameter
This parameter is used to position a function to start reading records from a database file at a
particular record. Positioner parameters can be used by themselves or in conjunction with restrictor
parameters. They must be key fields on the access path to which their function attaches and can only
be used hierarchically.

For example, a minor key can only be a positioner parameter if all major keys to it are also positioner
or restrictor parameters. Positioner parameters are automatically mapped and can be either Output or
Both on the panel. The following table is an example of the use of positioner parameters.

Vary Parameter
This parameter can have a varying length. The vary parameter is useful when interfacing with user-
written subroutines and programs. Domain checking will be ignored. Vary parameters are valid on
functions that generate an external high-level language program, that is RPG or COBOL. You need to
ensure that the parameters function properly if the domains do not match.

DRV - Function Field

The Derived (DRV) function field usage is a special field used within functions to perform a user-
defined action to derive the result field. An empty action diagram is initially associated with the
function field. A DRV field always has one output parameter: the derived field itself. You can specify as
many additional input parameters as required.

DSPTRN - Device Function

The Display Transaction (DSPTRN) function defines a program to display the records from two
distinct but related database files. The files must connect by a file-to-file relation. The relation that
connects the files must be an Owned by or a Refers to relation. The DSPTRN function has two
distinct record formats:
a header, or master record format that corresponds to the owned by or referred to file and is in
the subfile control portion of the panel
a detail record format that corresponds to the owned by, referred to, or referring file and appears
as a subfile
The DSPTRN function loads the entire subfile, and is suitable for using SUM, MIN, CNT, and MAX
function fields. A typical use of DSPTRN is to display an Order Header at the top of the panel with a
subfile of the associated Order Details below.
The key fields in the header format will be input-capable. All non-key fields in the header format will
be output only, by default.
All fields in the detail format will be output capable, by default. If no key, or a partial key is supplied
to the DSPTRN function, the key fields from header format will appear, prompting you for the
remainder of the key in order to identify the file. The DSPTRN function must be attached to a Span
(SPN) access path. The SPN access path connects two record formats with a common partial key.
There is no default update processing for this function type. In order to be able to create a Span
access path,
 an Owned by or Refers to relation must exist between the header and the detail files

13
 the SPN access path must be created over the owning file or the referred to file
 the access path must be created explicitly to the SPN access path

EXCEXTFUN - User Function

The Execute External Function (EXCEXTFUN) allows you to specify a high-level program using an
action diagram. You can also use an EXCEXTFUN as a user-defined *Notepad function, which can
serve as a repository of standardized action diagram constructs that you can easily copy into the
action diagrams of other functions.

EXCINTFUN - User Function

The Execute Internal Function (EXCINTFUN) allows you to specify a portion of an action diagram
that can be used repeatedly in other functions. You can also use an EXCINTFUN as a user-defined
*Notepad function, which can server as a repository of standardized action diagram constructs that
you can easily copy into the action diagrams of other functions.

EXCMSG - Message Function

The Synon/2E Execute Message (EXCMSG) function allows a request message to be executed by
the calling function. A request message is generally a CL (control language) command. It is not
possible to use the OS/400 override commands:

Override Database File (OVRDBF), Override Display file (OVRDSPF), and Override Print File
(OVRPRTF) with the EXCMSG function because the resulting overrides will only be in effect in the
invocation level of the implementing Synon/2E CL program.

If you use the OS/400 commands OPNDBF and OPNQRYF as the request message text, you must
specify a value of TYPE(*PERM) for these commands in order to prevent the closure of the file upon
return from the implementing Synon/2E CL program.

EXCUSRPGM - User Function

The Execute User Program (EXCUSRPGM) function allows you to specify the connection to a user-
written highlevel language program that will be called by Synon/2E functions. You can specify
parameters on the call to this function. You can also submit an EXCUSRPGM function for batch
processing from within an action diagram. You cannot specify Neither (N) type parameter for this
function type; however, you may specify Varying (VRY) role parameters. There is no *Return Code
parameter for this function type unless you explicitly define it.

EXCUSRSRC - User Function

The Execute User Source (EXCUSRSRC) function specifies either:
 user-written high-level language source code is to be included within the source code generated
by a calling function.
 device language statements, for example, DDS, that can be applied to a device function to
customize the associated device design.

Defining a Field as a Data Area

Before entering your model, create a data area in the appropriate library by using the IBM Create Data
Area (CRTDTAARA) command. You can then add a field defined as a data area to the *Standard
header/footer file. On the Edit Field Details panel, specify the Type as TXT and the Default Condition
as *DTAARA. Modify the four-character data area name in the DATAARA field to match the name of
your data area.

For the *Standard header/footer file, Synon/2E automatically initializes the field with the information
from your data area. The data area must be in your library list when you execute
your application. To use an existing data area within your Synon applications, define an EXCUSRSRC
function with an access path of *NONE. Define a BOTH parameter using a USR work field. This USR
field must have the same attributes and length as the data area. In the EXCUSRSRC, add your own
logic to access the data area and place the contents of the data area into the parameter field.

14