System Contexts
JOB
The Job (JOB) context contains system fields that supply execution time information about the job that executes the HLL program implementing a function. You cannot add additional fields to the JOB context.
You would use this context primarily to define system data to a particular field, such as job date, user name, or job execution start time. You can only use JOB context fields for input to other functions.
They cannot be changed.
The fields that appear in the JOB context are provided in a shipped file called *Job Data.
The JOB context is available in the action diagrams of all function types.
If you want to update a field on a file automatically with the current date, you could use the value from the *Job date field;
for example: DB1. Transaction date = JOB. *Job date <<<
PGM
he Program context (PGM) contains system fields that control the execution of a function.
An example of a PGM field would be *Program Mode which determines the program mode in which a program executes.
The fields that appear in the PGM context are defined in a system file called *Program Data.
The PGM fields are:
The Display value can be translated to other national languages if appropriate. You can use the fields in the PGM context to control processing within function. Each field is discussed briefly below:
*Program Mode
The *Program Mode field specifies the current mode of a program. This field can be used to provide an override to the default initial mode of Synon/2E functions and to condition processing according to the current mode.
For example, when you first enter an Edit File or Edit Record function, the program will be in *CHANGE Mode unless there are no records in the file to be edited. In this case the program will be in *ADD Mode.
If you want the end user to be in *ADD Mode regardless of the presence of records in the file, you can override the default in the User Initialization part of the action diagram for the Edit function using the built-in *MOVE function such as:
PGM. *Program mode = CND.*ADD
*Return Code
The *Return Code field contains a return code that is passed between all standard functions. This field may be used to communicate with the calling and called functions. You can add extra conditions to the *Return Code field.
A special facility is provided on the Edit Field Conditions panel for this field which allows you to define conditions by selecting from existing message functions.
The conditions created have the same name as the selected message function (for example, user quit requested) and have the message identifier used to implement the message (USR0156) as a condition value.
If you want to specify a fast exit (for example, pressing F15 when using a function that is called by another function exits you from both functions), the *Return Code field would be used in the PGM context as follows:
1. In the called program you would use the *Exit Program built-in function to specify an exit from the program when F15 is pressed. The parameter for this function is the *Return code field which you would specify as the condition *User QUIT requested:
- CASE <<<
| - CTL. *CMD key is CF15 <<<
| Add new records function <<<
| *Exit program - return code CND. *User QUIT requested <<<
’-ENDCASE <<<
2. In the calling program you would specify, immediately after the call to the subsidiary function, that if the return code returned corresponds to the condition *User QUIT requested, quit the (calling) program:
Execute subsidiary function
.- CASE <<<
| -PGM. *Return code is *User QUIT requested <<<
| *Exit program - return code CND. *User QUIT requested <<<
’-ENDCASE <<<
*Reload Subfile
The *Reload Subfile field specifies that a subfile is to be reloaded before redisplay. Synon standard functions normally only reload subfiles if it is required by the default processing.
You can use this field if you want to force a subfile reload. For example, if a Display File function calls a subsidiary function that adds records to the database, you may want the subfile to be reloaded on return so that the new records are included in the display.
To force a subfile reload, you should move the condition *YES to the *Reload subfile field immediately after the call to the subsidiary function; this will cause the subfile to be reloaded on return to the Display File function.
- CASE < < <
| - CTL. *CMD key is CF09 < < <
| Add new records function < < <
| *PGM. *Reload Subfile = CND. *YES < < <
’-ENDCASE < < <
*Record Data Changed
The *Record Data Changed PGM context field specifies whether the data for the current record has changed. The value *Yes means the record data has changed; the value *No means that the record data has not changed.
The database record is updated only when the value of this field is *Yes.
You can access the *Record Data Changed field from all functions that contain an embedded CHGOBJ function, such as EDTFIL and EDTTRN. It is valid only at the ’Processing before Data update’ user point in the CHGOBJ function action diagram; other uses give invalid results.
Two ways to use this field are:
· You can test its value to conditionally perform actions that depend on whether data has been changed as shown in the example below. · You can manually set this field to conditionally force or suppress a database record update.
> USER: Processing before Data update
.__ < < <
.> Only set the Timestamp field if other data has changed < < <
. - CASE < < <
.| -PGM. *Record Data Changed is *YES < < <
.| DB1.Timestamp = JOB.*Job date < < <
.| DB1.Timestamp = JOB.*Job time < < <
|.-ENDCASE < < <
*Record Selected
The *Record Selected field specifies that a record read from the database is to be processed.
In Synon standard functions that read multiple records from the database, for instance to load a subfile, you can add user-defined processing to specify which records are to be included.
The record selected field allows you to indicate whether a record is to be included or omitted.
*Scan Limit
The *Scan Limit field specifies a limit to the number of records that are to be read at a time.
If additional selection is applied when reading records from the database (for instance, on the *Record selected field as above), then a limit can be specified on the number of records that can be unsuccessfully read.
The default value for the Scan Limit is 500. For example, to specify that the Scan Limit is to be 100, use the built-in function *MOVE to set the *Scan Limit field to this value in the USER: Initialization exit point of an action diagram:
PGM. *Scan limit = CON. 100
*Defer Confirm
The *Defer Confirm field only applies to functions where a confirm prompt is available.
In such functions there are likely to be occasions when you want to suppress the confirm prompt and subsequent processing.
On these occasions, *Defer Confirm causes the panel to be redisplayed as if the user had replied No to the confirm prompt.
The effect is the same, even if the confirm prompt option is not specified on the Edit Function Options panel.
For example, in an Edit File function, if a line is selected with a Z, you would probably not want to display the confirm prompt on returning to the Edit file display.
To prevent the program from displaying the confirm prompt, move the condition *Defer Confirm to the *Defer Confirm field.
This will cause the confirm and update part of the processing to be skipped.
.- CASE <<<
| - RCD. *SFLSEL is *Zoom <<<
| Display details function <<<
| PGM. *Defer confirm = CND. *Defer confirm <<<
’-ENDCASE <<<
*Print Format
The Print Format field specifies whether a format from a report is to be printed. The *Print Format option only applies to Print File and Print Object functions.
There may be instances when you want to select more records from the database file for processing by the function (controlled with the *Record Selected field) than you want to be printed.
For example, if you want a Print File function to print either a detailed or a summary report, depending on the value of an input parameter to the function, you can control which formats are printed in the two reports by means of the *Print Format field.
> USER: On print of detail formal <<<
: - - <<<
: .-CASE <<<
: | - PAR. Report type is Summary <<<
: | - PGM. *Print format = CND. *Do not print format <<<
: ’-ENDCASE <<<
*Continue Transaction
The *Continue Transaction field is applicable for transaction functions such as EDTTRN and DSPTRN that have input restricted key fields. This field can be used to perform the equivalent of reload subfile for these two functions without returning to the key panel.
This can be done within the action diagram of the function by inserting the following code in the *EXIT PROGRAM user point:
This piece of action diagram logic enables the subfile of an EDTTRN or DSPTRN to be reloaded and the subfile redisplayed without having to return to the key panel.
> USER: Exit program processing <<<
: - - <<<
: - CASE <<<
: | -CTL. *CMD key is *Exit <<<
: | - *OTHERWISE <<<
: | PGM *Continue transaction = CND.No <<<
: | <---- *QUIT <<<
: ’-ENDCASE <<<
*Next RDB
The *Next RDB field is applicable for functions with distributed functionality.
If the value of *Next RDB is not blank, the value will be used to establish a connection prior to performing database access.
*Cursor Field
The *Cursor Field will always contain the name (DDS name, for example Z1ABCD) of the field where the cursor is currently positioned.
IS Comparison Operator
You can use the IS comparison operator to determine whether the cursor is positioned on a specific field on the panel by comparing the PGM *Cursor Field to the field.
You can use the IS comparison operator in any condition statement.
The following is an example of the IS comparison operator. This example shows a test that determines if the cursor is positioned on the Customer Status field.
Use the PGM *Cursor Field to test for cursor position on subfile fields with the RCD context.
In this case, both the field and the subfile record must match the cursor position for the test to be true.
This is implemented automatically by Synon/2E. When testing for cursor position on subfile records, the logical place to insert the CASE statement in the action diagram would be USER: Process subfile record (or equivalent user point.)
There is some additional logic that will be required to test for a cursor position in the DSPFIL, EDTFIL, and SELRCD function types.
This is discussed under the example for PGM *Re-read subfile record field. PGM *Cursor Field is available for reference only.
For example, you will not be able to move conditions or values into this field.
*Cursor Row and *Cursor Column
The *Cursor Row and *Cursor Column Field will always contain the relative numeric row and column that the cursor is currently on. As with *Cursor Field, these fields are available as reference fields only.
*Re-read Subfile Record
The *Re-read Subfile Record field can be used to force the re-processing of subfile records whether or not they have been changed. This is particularly useful when testing for cursor position on a subfile within the DSPFIL, EDTFIL, and SELRCD function types.
*Synon Work field (15,0) to (17,9)
These fields are available as numeric fields and have the lengths as specified in their description. These fields can be used as computational work fields.
*Synon Work field (17,7) is the default value intermediate result field that will be used when a compute expression is initially created.
*Initial Call
The *Initial Call field allows you to detect whether the function is being invoked for the first or subsequent times.
This field will only be of use if the function option Closedown Program has been set to *No in which case the value of PGM *Initial Call will be *Yes.
For subsequent calls to this function the value will be *No.
In order to execute logic that will only be performed once when a function is first invoked, the following action diagram logic can be inserted:
>USER: Initialize program
CASE
| - PGM.*Initial Call is *Yes
| Load Product info array - Product
_ENDCASE
’ - -