2E - Development Standards (Parameters)

This is Part 4 in a series of articles.

Once again I have decided to focus on development standards and best practices for 2E (Synon) development. You can search this blog for the other posts around performance, defensive programming and general coding considerations.

Today's topic is parameters and how they are used and defined in 2E.

In no particular order my tips and techniques in this are as follows:-

Use Files, Accessss Paths or *Arrays as pick lists. In general try to use ACP (Access Path) RCD (Record) structures as picking lists for parameter definition rather than individual *FIELD entries. This makes it easier to identify the impact arising from future database changes.

Never use the last parameter line. If you find yourself using the last parameter line it is time that you consider re-architecting the functions parameter interface using an array structure or access path picking lists. It is quite selfish to use that last line for when another developer needs to maintain the function. Also if creating a function from scratch and you are using 6 or 7 parameter lines then it would be prudent to consider a parameter array.

Choosing the correct passing method. In general RCD is always preferable to Field (FLD) for normal parameter definition since this has a performance benefit. Only one actual parameter address is passed rather than many. This is the preferred method for program to program calls.

However, if an external function is likely to be called from a CL program, menu, message, command line then it is easier to use FLD. This is because passing values i.e. numeric fields via a command line or CL can get complicated. This is especially true for numeric and date fields.

Pro’s
RCD uses less PAG’s and therefore system memory.
Easier to determine impact of file changes using in-built analysis tools.

Con's
Harder to call programs directly when required.
Complicated CL programming for parameter passing.
Incorrectly declares NEITHERs as parameters and can cause confusion.

Understand the impact of a neither parameter and the generated code. If an ACP definition only contains NEITHER parameters then always use FLD rather than RCD. This ensures that the parameter definitions are not implemented as actual parameters and calling functions do not need to be generated as the definition changes.

This is because Neither Parameters passed as RCD will generate a parameter entry in the RPG. Therefore it is strongly recommended that neither parameters are always passed as FLD.

No harm in using *Arrays to define your parameters. If a suitable ACP is not available, or if more than 9 parameter block lines are needed, than an array may be used for parameter definition. Typically an array is a good choice for bringing together various NEITHER MAP fields on a device design.

Never use *NONE as the ACP definition. It is not possible to track the usage of *NONE for any model file. This has been resolved and now shows *FUNPAR usages in 8.1 and above but I have included it as you may be on an earlier version of the tool.

Tip - MAP = Device Design Only. Only use MAP where it is being used specifically to map a field to a screen design. In all other cases turn the default MAP off. This helps make it clearer to understand where MAP is actually being used. It serves no purpose to have MAP on most other functions other than to confuse a beginner.

Trick - Getting at the CTL context for a SLTRCD. Use neither MAP parameters for placing values on the CTL format of a Select Record function. It is not possible to influence these CTL control fields via the action diagram as there is no Control User point. Instead set to Neither MAP and populate during the initialisation.

You can also use MAP when changing a primary key via a CHGOBJ.

Be explicit with a parameters type and role and also ensure that the parameter field name is meaningful.

Best Practice - Never use BOTH parameters for convenience i.e. Totalling inside a RTVOBJ. I have witnessed far too many functions which have a BOTH parameter for a total which then gets initialised to Zero in the initialise user point. Any developer choosing to use this function will immediately believe that they need to supply a valid value.

This is bad practice. The parameter interface is more important than a developers extra effort inside the function.

Best Practice - Parms not WRK Context. Parameters should always be passed if they are going to be used between functions. DO NOT rely on the fact that WRK fields are global.

Using sequencing to indicate parameter importance. Neither parameters can be sequenced as 999 on the EDIT FUNCTION PARAMETERS screen. This helps identify the actual parameters. If you require Neither and normal parameters i.e. Input, Output or Both then declare the file/access path twice and placing the neither parameters on the second declaration and remembering still to sequence it 999.

The only exception here is you are using duplicate parameters. There is a 2E limitation that these must be sequenced 1 to 9 only.

Thanks for reading.
Lee.