A Synon context is a grouping of the fields that are available for use at a particular processing step in an action diagram.
A context specifies which instance of a particular field is to be used. Fields can be referenced for use as parameters in functions and in conditions to control functions.
Different contexts are available at different points of the action diagram depending on the function type, the stage of processing, and the particular nature of the user point; that is, whether a subfile control format or a record detail format is being processed.
Each type of context is identified by a three-letter Synon code. For example, PAR for parameter fields, CON for constant fields, and WRK for work fields.
The following pages describe the context types and their usage.
Database Contexts
DB1
The Database One (DB1) context contains the fields that are in the first, or only, format of the access path to which a function is attached. Any field in the access path format is available for processing in the DB1 context.
The DB1 context is available to all function types that perform update or read functions on a database file after reading and before writing to the database file. Those functions are CRTOBJ, CHGOBJ, DLTOBJ, and RTVOBJ.
In the generated source code, the generated names of fields from the DB1 context will be prefixed by the format prefix of the appropriate DBF file.
For example, if the following relations are present in an access path for the Company file:
FIL Company REF Known by FLD Company code CDE
FIL Company REF Has FLD Company name TXT
Company name will be present in the DB1 context of functions using that access path and can be used in action diagrams (where access to the database is allowed), for example:
WRK. Company name = DB1. Company name <<<
DB2
The Database Two (DB2) context contains the fields that are in the second format of the access path to which a function is attached.
Any field in the second access path format is available for processing in the DB2 context.
The DB2 context is available only to functions that are attached to a Span (SPN) access path; the DB2 context applies to the detail file (or second format) in the SPN access path.
The DB2 context is available only within an EDTTRN function to access the secondary format. In the generated source code, the generated names of fields from the DB2 context will be prefixed by the format of the appropriate DBF file. Consider the following example.
A Span (SPN) access path is created for Order and Order Detail and the second (detail) format for Order Detail contains the following relations:
FIL Order detail CPT Owned by FIL Order CPT
FIL Order detail CPT Refers to FIL Product REF
FIL Order detail CPT Has FLD Order quantity QTY
Order Quantity will be present in the DB2 context of functions using that access path. It may be used in the action diagram where access to the database is allowed,
for example: WRK. Order quantity = DB2. Order quantity <<<
ELM
The ELM context contains the fields defined for the last-accessed element of a specified array.
This context is valid only in the *CVTVAR built-in function and may be specified for either the input or output parameter. Since a single element of an array is equivalent to a data structure you can use the ELM context
· to decompose a field into a structure. A move of an element of an array to a field constitutes a move of the array’s structure to the field.
· to group a set of fields into a single field. Note that you must define a key for an array even if the array holds a single element.
Following is more information on these two usages.
Move From a Field to a Structure
· The array is the output of the *CVTVAR function.
· To ensure that the array index is not corrupted by the move, the array must be defined as a single-element array.
· The *CVTVAR function is implemented as a MOVEL operation from the field to the data structure (array). Blanks are moved to the array element before the data is moved.
Here is an example of how this operation might look in an action diagram.
Move From a Structure to a Field
· The array is the input of the *CVTVAR function.
· The *CVTVAR function moves the last accessed array element of the named array to the named field. In this case, the array may contain multiple elements.
· The *CVTVAR function is implemented as a MOVEL operation from the associated data structure (array) to the field.
Here is an example of how this operation might look in an action diagram.
Device Contexts
KEY
The Key (KEY) context contains the fields that are on the key panel display of the device functions that have key panels.
These keys apply to the record functions: Edit Record (EDTRCD 1,2,3) and Display Record (DSPRCD 1,2,3).
All the key fields on the access path to which the function is attached are available in this context, along with any associated virtual fields.
If you map parameters to the device panel (as mapped or restrictor parameters), they will also be available in this context. The shipped field *CMD key is present in this context only in the exit program user point. It is also present in the detail format.
You cannot add function fields to a key panel.
Consider the following example.
An Edit Record function is defined for an Employee file, using an access path which has keys defined as follows:
FIL Company REF Known by FIL Company code CDE
FIL Company REF Has FLD Company name TXT
FIL Employee REF Owned by FIL Company REF
FIL Employee REF Known by FLD Employee code CDE
FIL Employee REF Has FLD Employee name TXT
Company name is a virtual field on the Employee file through the Owned by relation.
The fields available in the KEY context of the action diagram for the function will be:
*CMD key
Company code
Company name
Employee code
DTL
The Detail (DTL) context contains fields on the display panels of device functions that have single, non-subfile detail panels such as EDTRCD, or multiple, non-subfile panels such as EDTRCD2.
All of the fields from the access path to which the function is attached are available in the DTL context.
If you map parameters to the device panel as mapped or restrictor parameters, they will also be available in this context.
The shipped field, *CMD key, is present in this context. If you add any function fields to the detail panel display, these fields will be available in the DTL context.
The DTL context is available in the action diagrams of PMTRCD, EDTRCD, and DSPRCD. This context is only available after the key has been successfully validated.
Consider the following example. An Edit Record function is defined on a Stock Item file using an access path which includes the following relations:
FIL Stock item REF Known by FLD Stock item code CDE
FIL Stock item REF Has FLD Stock item qty QTY
FIL Stock item REF Has FLD Item price PRC
Stock Item, Qty field and Item Price Field will be present in the DTL context for that function and could be used in the action diagram;
for instance: WRK. Stock value = DTL. Stock item * DTL. Item price <<<
2ND
The Second Detail panel (2ND) context contains the fields that are on the second detail panel display of a device function that has a multi-part panel design attached to it, such as EDTRCD2 and DSPRCD2.
All of the fields from the access path to which the function is attached are available in the 2ND context.
If you map parameters to the device panel as mapped or restrictor parameters, they also are available in this context.
The 2ND context will only be available in the action diagrams of the following function types:
· Edit Record 2 panels · Edit Record 3 panels · Display Record 2 panels · Display Record 3 panels
3RD
The Third Detail panel (3RD) context contains the fields that are on the third detail panel display of a device function that has a multi-part panel design attached to it, such as EDTRCD3 and DSPRCD3.
All of the fields from the access path to which the function is attached are available in the 3RD context. If you map parameters to the device panel as mapped or restrictor parameters, they also are available in this context.
The 3RD context is only available in the action diagrams of the following function types:
· Edit Record 3 panels
· Display Record 3 panels.
CTL
The Subfile Control (CTL) context contains the fields that are in the subfile control record of the device functions that have a subfile panel display such as Display File or Edit Transaction.
The fields available in the CTL context depend on the function type, the access path used by the function, and whether you have specified restrictor parameters for the function.
The *CMD key shipped field and any parameters specified as mapped or restrictor parameters are present on the CTL context.
If the function is attached to a SPN access path, the CTL context contains all of the fields from the header format on the access path.
If the access path is a RTV or a RSQ and the function is: · Display type (Display File or Select Record), all of the fields on the access path will be available in the CTL context.
The CTL context is available in the action diagrams of all functions that have a subfile panel display:
· Display File (DSPFIL) · Display Transaction (DSPTRN) · Edit File (EDTFIL) · Edit Transactions (EDTTRN) · Select Record (SELRCD)
The Synon shipped field *CMD key provides the means of specifying that a specific piece of logic is to be executed whenever the user presses a particular function key.
The *CMD key is a status (STS) field and already has defined conditions for many possible function or control key combinations.
Consider the following example of the use of the *CMD key. To specify the use of a function key to call another program, you should insert the relevant processing at the appropriate point in the action diagram, for example:
> USER: Process command keys
. ----
: CASE <<<
: | -CTL. *CMD key is CF06 <<<
: | Print detailed report <<<
: ENDCASE
:----
RCD
The Subfile Record (RCD) context contains the fields that are in the subfile record of device functions that have a subfile panel display such as Display File or Edit Transaction.
The fields available in the RCD context depend on the function type and the access path used by the function. The *SFLSEL shipped field will be present on the RCD context.
Mapped parameters specified as mapped or restrictor parameters are present on the RCD context.
If you have a SPN access path, the RCD context will contain all of the fields from the detail format on the based-on access path.
If you have a RTV or RSQ access path, all of the fields from the based-on access path will be available in the RCD context.
The RCD context is available in the action diagrams of all functions that have a subfile panel display:
· Display File (DSPFIL) · Display Transaction (DSPTRN) · Edit File (EDTFIL) · Edit Transaction (EDTTRN) · Select Record (SELRCD)
The shipped *SFLSEL (subfile selector) field provides a selection column field for subfiles.
You can optionally remove this field from the panel design using the Edit Function Options panel.
The *SFLSEL field is a status (STS) field and is shipped with some pre-defined conditions.
CUR
The Current Report Format (CUR) context contains all of the fields that are in a report format of a Print File or Print Object function.
The report functions have header and total formats for each key level in the based-on access path, except for the lowest level key, as well as a final total format.
The CUR context is only available in the action diagrams of the following function types:
· Print File (PRTFIL)
· Print Object (PRTOBJ)
> USER: Process detail record
:- -
: CUR.Order line val= CUR. Order qty * CUR. Product price
’- -
NXT
The Next Report Format (NXT) context defines a context relative to the CUR context for report functions.
The NXT context contains fields that are in the next active report format (not dropped format) that is one level break lower.
The NXT context is only available in the action diagrams of the following function types:
· Print File (PRTFIL)
· Print Object (PRTOBJ)
Literal Contexts
CND
The Synon Condition (CND) context enables you to specify that a particular field condition value is to be supplied as a field value in one of the following ways:
· as a parameter to a function.
· as the condition that controls a conditional or iterative construct in the action diagram.
All field conditions that are attached to a field are available in the CND context for that particular field.
CON
The Constant (CON) context contains any constant or literal values that you want to specify.
You only use CON context values to specify input values to fields.
There are also some restrictions associated with the usage of this context:
· You cannot use the CON context with status (STS) fields. You should use the CND context with STS fields.
· Numeric constants must be less than or equal to ten characters in length, including the decimal point and sign. A maximum of five characters is allowed after the decimal point.
· Alphanumeric constants must be less than or equal to twenty characters in length.
The CON context is available in the action diagrams of all function types. To specify that a numeric field Order Quantity is to be set to a value of 15:
