EDTTRN - Device Function
The Edit Transaction (EDTTRN) function defines a program to maintain the records on a specified pair of header and detail files.
The files must be connected by a file-to-file relation.
The relation that connects the files must be an Owned by or a Refers to relation.
The EDTTRN function has two distinct record formats: a header, or master record format that corresponds to the owning or referred to file and is in the subfile control portion of the panel; and a detail record format that corresponds to the owned by, or referring file, and appears as a subfile.
The EDTTRN function loads the entire subfile, and is suitable for using SUM, MIN, CNT, and MAX function fields.
The EDTTRN function has the following default function logic: · In *ADD mode, the header keys are accepted as parameters, if provided.
By specifying the keys as restrictor (RST) parameters, the key fields will be output only on the panel.
The panel appears with blank input-capable fields in the header master file and detail subfile record formats.
You can then enter data in the header record format and the detail record format subfile for validation.
· In *CHANGE mode, the header keys are accepted as parameters.
If no key, or a partial key is supplied to the EDTTRN function, the key fields from the header format will be displayed to prompt for the remainder of the key. If the parameter list contains a fully restricted key, this step will not occur.
· All detail records matching the header record keys will be loaded into the subfile.
The panel will display the header record file and the first page of the detail file as a subfile. You can add, change, or delete subfile records as you desire, and after successful validation the file is updated.
An EDTTRN function includes calls to the CRTOBJ, DLTOBJ, and CHGOBJ functions by default for both header and detail formats.These default functions will be included in the action diagram for the function.To remove this default processing, you change the function options.
These functions use the associated Update (UPD) access path update.
There can be six separate calls to these internal functions: three calls for the header format file; three calls for the detail format file.
The EDTTRN function must be attached to a Span (SPN) access path.
The SPN access path connects two record formats with a common partial key.
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.
· The SPN access path must be created over the owning file or the referred to file.
· The access path formats must be added explicitly to the SPN access paths.
The typical use of an EDTTRN is to display an Order Header at the top of the panel with a subfile of the associated Order Detail below.
The EDTTRN function differs from the EDTFIL function in that the EDTTRN function loads an entire subfile.
The EDTFIL function only loads one page of a subfile at a time.
The following is an example of an Edit Transaction panel.
EXCEXTFUN - User Function
The Execute External Function (EXCEXTFUN) allows you to specify a high-level program using an action diagram.
The function is implemented as a separate program and has its own action diagram.
The function can be created with an access path of *NONE. The EXCEXTFUN has no default logic.
It presents an empty action diagram.
Any function or set of functions of any type can be included in an EXCEXTFUN and compiled so that it can be executed as a program.
For documentation purposes, the EXCEXTFUN can be optionally attached to Retrieval (RTV), Resequence (RSQ), or Update (UPD) access paths.
A good practice is to have only a single action diagram construct with an EXCEXTFUN.
This single construct is a call to an internal function (EXCINTFUN) which contains all the functionality required.
Both functions define the same parameters.
This way, you can choose to reference an EXCEXTFUN (function you can call) or EXCINTFUN without duplicating the action diagram constructs.
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.
The EXCINTFUN is implemented as inline source code (or a macro function) within the source code of the calling function.
That is, whenever you make a call to this function type, it will be embedded in the source code of the calling function at the point where you made the call.
You cannot attach an EXCINTFUN to any particular access path. When defining this function type specify *NONE for the access path.
You might use the EXCINTFUN to perform a calculation routine that would be used repeatedly within a function or several functions.
Example An example of EXCINTFUN could be in performing a calculation, such as working out a percentage, which you want to call several times in different functions.
You could:
1. Define an EXCINTFUN, attached to a database file, with access path *NONE.
2. Define the input parameters of the function, such as Number and Total and the output parameters, such as Percentages.
3. Define the actions required in the supplied action diagram.
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.
You enter the request string in the second-level text of the message function.
The command can be executed in either the AS/400 native environment or the System/38 environment.
The EXCMSG function is attached to a special Synon/2E shipped system file called *Messages. To implement the EXCMSG function, you define an EXC type message function.
Once you define the command to be executed, you insert a call to the EXCMSG function from a user point within the action diagram of a calling function.
The EXCMSG function is then implemented as a call to a CL program that is supplied by Synon/2E
We have to use message types of type EXC.
EXCUSRPGM - User Function
The Execute User Program (EXCUSRPGM) function allows you to specify the connection to a user-written high-level language program that will be called by Synon/2E functions.
You can specify parameters on the call to this function.
You can attach the EXCUSRPGM function to any access path or you can specify *NONE for the access path.
You should normally attach the EXCUSRPGM function to a file containing some or all of the function parameters.
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.
There are no action diagrams, device designs, or function options associated with this function type.
When you create an EXCUSRPGM function, Synon/2E assigns a source member name for the program.
You can override this to be the name of the HLL program that you want to call.
You will need to do this if the program already exists and you are now defining it to the model.
You should declare all the parameters required by your EXCUSRPGM function.
Parameters can be declared in the normal fashion using the Edit Function Parameters panel.
Take E to see source
EXCUSRSRC - User Function
The Execute User Source (EXCUSRSRC) function specifies that user-written high-level language source code is to be included within the source code generated by a calling function.
The HLL source code of the EXCUSRSRC function must be the same as that of the calling function; that is, a function implemented in RPG can only call an EXCUSRSRC function that is RPG.
You can attach the EXCUSRSRC function to any access path, or you can specify *NONE for the access path. You should normally attach the EXCUSRSRC function to a file containing some or all of the function parameters.
If there are no suitable files, it may be worth considering defining a dummy file using a Defined as relation.
For example: FIL User source REF Defined as FIL User source REF
No action diagram, device design, or function options are associated with this function type.
Although the EXCUSRSRC function provides flexibility, for ease of maintenance, you should use action diagram programming whenever possible.
The files are as follows:
· For RPG functions, the source member must reside in the file QRPGSRC.
· For COBOL functions, the source member must reside in the file QCBLSRC or QLBLSRC.
Parameter fields are only recognized in the factor one, factor two, and result positions of the RPG calculation specifications that form part of the instance code.
Parameters must be of the form #UMMMM where U is the parameter usage defined on the function (I, O, or B), and MMMM is the mnemonic name (DDS name) of the formal parameter.
For example: C #IORVL ADD #BLNVL #OTLVL
Synon/2E checks usage of parameters within the instance code both for correspondence with the formal parameter and for use within the user RPG code.
For example if field ORCD is alphanumeric, Synon/2E would not allow the following:
C Z-ADD ZERO #BORCD
The letter U is reserved as the initial letter for user-specified field names and subroutine names in user-written source.
If you use other prefixes, you may find they conflict with Synon/2E generated names in certain instances.
PMTRCD - Device Function
The Prompt Record (PMTRCD ) function defines a program to prompt for a list of fields defined by a specified access path.
There is no default action for this function type. If you want to call another function once you have validated the PMTRCD fields, you must specify this in the action diagram.
The fields which appear, by default, on PMTRCD are based on the file/access path over which the function is built.
You can drop all panel format relations and fields and use your own function fields and subsequent validation on the function as an alternative to validating fields with file relations.
You can attach a PMTRCD function to a Retrieval (RTV) or a Resequence (RSQ) access path.
There is no update processing for this function unless you specifically include it in the action diagram.
A Prompt Record function does not validate the existence of a particular record from the underlying access path.
It will, however, validate panel level relations and date and time fields.
The following is an example of Prompt and Record panel.
PRTFIL - Device Function T
he Print File (PRTFIL) function defines a program to print the records from a specified access path.
The PRTFIL function prints all records in a single file hierarchy of the based-on access path and provides header and total formats for key fields.
Most considerations that affect PRTFIL also affect Print Object (PRTOBJ).
· You can specify up to 13 levels of totalling.
· You can print records from more than one access path by embedding Print Object functions within this function type. You can view the overall structure of the report in the Edit Device Structure panel.
· You can attach a PRTFIL function to a Retrieval (RTV), a Resequence (RSQ), or a Query (QRY) access path. The Query access path allows you to specify virtuals as key fields. You can omit certain records from printing by setting the *Record Selected Program field to No.
The default design for a PRTFIL function includes standard header, top of page, first page, detail final totals, and footer formats.
· If there is more than one key field, Synon/2E creates a header and total format for each additional key level. By using the Edit Report Formats panel, you can drop unwanted formats except detail standard header/footer formats.
· The formats belonging to any embedded PRTOBJ functions are present on the PRTFIL device design; however, you cannot alter them. You can only specify the indentation level of the embedded PRTOBJ formats within the report structure.
You can add a maximum of 13 PRTOBJ functions to one PRTFIL function.
The following is an example of a Print File.
PRTOBJ - Device Function
The Print Object (PRTOBJ) function defines an embedded report that prints the records from a specified access path at any point within a PRTFIL function.
You also can embed PRTOBJ functions within other PRTOBJ functions.
A PRTOBJ function is an internal function, much like the EXCINTFUN, RTVOBJ, CHGOBJ, or (DLTOBJ) functions, in that the high level language source code generated to implement the function is included as source code within the Print File function that calls it.
You can attach a PRTOBJ function to a Retrieval (RTV), a Resequence (RSQ), or a Query (QRY) access path.
The default device design for a PRTOBJ report design includes first page, detail, and final total formats. The standard header and footer formats and the external features of the report (for example, page size, compiler overrides) are determined by the embedding PRTFIL function. · If there is more than one key field, Synon/2E creates header and total formats for each additional key level. You can drop unwanted formats using the Edit Report Formats panel.
The PRTOBJ function reads one, several, or many records according to the entry parameters that you specify for it.
The same parameter considerations that apply to PRTFIL functions also apply to this function type. ·
You can specify totalling with a PRTOBJ function in the same manner as for PRTFIL function types (from the CUR context to the NXT context).
If you want to return a total to the calling function, you must return it as a parameter.
The following is an example of a Print Object.
