7.63.1 FUNCTION Parameters

OPTIONS

RCV_DS

RCV_LIST

TRIGGER

Allows up to 9 different options to be specified. Values that may be specified in this parameter include:

*NOMESSAGES

Specifies that the program will never be required to route messages in from its caller, nor route messages back to its caller (unless it fails). By using this option the entry and exit resources used by a compiled RDML function can be reduced.

When this option is used, outstanding developer messages are not checked for. This can benefit performance of heavily used / called functions in a production environment where developer services is on.

*DEFERWRITE

...

Any program that uses a POP_UP command, or communicates to remotely attached devices, should use this option.

*HEAVYUSAGE and *LIGHTUSAGE

Specify that the compiled RDML function should use the HEAVY usage option or the LIGHT usage option regardless of what option the associated process uses.

...

Note that RDMLX functions will, by default, retain their state between invocations. If the state is not to be retained, then use components that are *DYNAMIC.

*DBOPTIMIZE or *DBOPTIMISE

...

It is strongly recommended that  you read Using *DBOPTIMIZE / *DBOPTIMIZE_Batch in the LANSA for i User Guide before attempting to use this option.

*DBOPTIMIZE_BATCH or *DBOPTIMISE_BATCH

...

It is strongly recommended that you read Using *DBOPTIMIZE / *DBOPTIMIZE_Batch in the LANSA for i User Guide before attempting to use this option.

*PGMCOMMIT

...

Using *PGMCOMMIT implies the use of *DBOPTIMIZE, regardless of whether or not the *DBOPTIMIZE option is actually specified.

*NOPGMCOMMIT

...

Using *NOPGMCOMMIT implies the use of *DBOPTIMIZE, regardless of whether or not the *DBOPTIMIZE option is actually specified.

*NOIGCCNV

...

Using this option suppresses the automatic enabling of the IGCCNV keyword in all display file DDS generated for this function.

*NO_RLTB_MIRROR

Specifies that the automatic "mirroring" of field positions on screen panels and report layouts should not be enabled in this function, regardless of whether or not the function is being compiled under a right-to-left language.

The automatic "mirroring" facility, and this parameter value, only apply to functions being compiled under right-to-left languages. This parameter is ignored for all other language groups.

*DIRECT

Specifies that this function should be made eligible for potential direct calling from another function, or to directly service a prompt key request.

By using this option you are indicating that this function may be directly invoked by another caller function, or to directly service a prompt key request.

...

Refer to the CALL command for more details of how a direct mode call is made and the restrictions that exist when using this type of call operation.

*CLOSE_DISPLAY

...

If this option is used, ensure that all browse lists are specifically cleared (CLR_LIST command) at each entry or (re)entry to the function. This ensures that any counter fields are reset to zero to match the current number of entries in the list, which will be zero because the display file was closed on any previous termination.

*MLOPTIMIZE or *MLOPTIMISE

...

Use of *MLOPTIMIZE in any situation where these conditions are not all met does no harm. A warning message is issued and the *MLOPTIMIZE request is ignored.

*ALP_SYSTEM_VARIABLE

Specifies that this function is to be a system variable evaluation function (for alphanumeric variables only).
Option *DIRECT must also be used when this option is used.

*NUM_SYSTEM_VARIABLE

Specifies that this function is to be a system variable evaluation function (for numeric system variables only).
Option *DIRECT must also be used when this option is used.

*ALP_FIELD_VALIDATE

Specifies that this function is to be a complex logic check function (for alphanumeric fields only).

Refer to the Complex Logic Rule in the LANSA for i User Guide for further information. Option *DIRECT must also be used when this option is used.

*NUM_FIELD_VALIDATE

Specifies that this function is to be a complex logic check function (for numeric fields only).

...

• No DISPLAY, REQUEST or POP_UP command can be used within a complex logic validation function.

• No CALL can exist to another process/function within a complex logic validation function. However, a call to a 3GL program can exist.

• Complex logic validation functions cannot exist within an action bar process. This is not to say that they cannot be referenced from within an action bar, it just means that a complex logic function cannot be defined as part of a process that is of action bar type.

• Complex logic validation functions cannot have options of RCV_DS or RCV_LIST.

• The associated process must not have parameters.

• The exchange list may not be used. This restriction ensures insulated modularity in the validation check.

• Recursive implementations may be defined, but will fail to execute correctly. For instance, a validation checker function invoked during an insert to file A could attempt to insert data into file B, possibly causing itself to be invoked in a recursive situation, and thus to fail.

• Use of options *DBOPTIMIZE and *NOMESSAGES are recommended for complex logic validation functions. The use of *HEAVYUSAGE may also be considered in heavily used validation functions.

• The use of option *MLOPTIMIZE is strongly recommended in all multilingual applications of this facility.

*MINI_SCREEN

...

• No borders are presented.

• The window can be located left as far as row 1, column 1.

• The borderless window produces a representation of a "mini" full screen panel, rather than of a typical pop-up window.

• Browselists presented within a pop-up window where all field column headings have been overridden to blanks values will not be spaced/separated from the header area by the normal separation line.
  
  This means that manually defined text can be effectively specified for "apparent" column headings. This facility is only used where all fields in the browselist have their column headings overridden to blanks. It also means that it is hard to insert a whole new line of text into the design via the screen painter because the normal separation line cannot be used as a target position to "push" the browselist down the screen panel. To insert a new line of text return to the RDML editor and define a "dummy" field into the header area at the end of the FIELDS list and then re-invoke the screen painter. The dummy field should be positioned so as to "push" the browselist further down the screen panel. Add/move the necessary text and/or field onto the new line created and then optionally delete the "dummy" field.
  
  Where large scale use of this feature is being made it is strongly recommended that an Application Template be constructed for invocation by the "ET" (Execute Template) editor action. This template can be used to construct a "standard layout" for every "mini-screen" including one or more initial "dummy" fields to push the browselist portion onto the required starting line and leave sufficient space for the insertion of fields and/or text into the header area.

*OS400_EXT_PRINT

...

More information on User Defined Reporting Attributes and External Printer files, is supplied in User Defined Reporting Attributes in the LANSA for i User Guide.

*BUILTIN

Specifies that this function is to be a Built-In Function.

Refer to Create your Own Built-In Functions in the LANSA Application Design Guide for more details. *DIRECT must also be used when this option is used.

*STRICT_NULL_ASSIGN

Specifies that it is an error to assign an *SQLNULL into a non-nullable field.

...

Refer to Assignment, Conditions, and Expressions with Fields allowing SQL Null for full details on strict null assignment versus the default behaviour.

Allows up to 20 different data structure names to be specified which can be received by the function. The following points should be noted when using this parameter:

...

• Only functions that use RCV_DS(*EXCHANGE .....) will search, clear and alter the exchange area. Functions that do not use this option have no impact at all on the exchange area.

• The maximum length of the exchange area is 9999 bytes. Attempting to use a set of data structures with an aggregate length exceeding this limit will cause an application failure.

• The actual storage of the exchange area is performed by a shipped program called M@EXCHDS. To optimize performance under the IBM i operating system and prevent PAG (Process Access Group) "holes" this program has an "open" and "close" option that can be used before LANSA is invoked (e.g.: during system sign on). The "open" and "close" option uses the LANSA convention of CALL M@EXCHDS (X'00') to open and CALL M@EXCHDS (X'FF') to close. Obviously the close operation clears the exchange area. Do not call M@EXCHDS from within LANSA RDML functions. These types of calls are not required to actually use this facility, only to OPTIMIZE its use.

• Using RCV_DS(*EXCHANGE ....) is less efficient than using a normal RCV_DS(.....) parameter, but more efficient than using an EXCHANGE command with many fields.

Allows up to 20 different working list names to be specified. The following points should be noted when using this parameter:

...

It is also important to note that the order in which the working lists are specified on the PASS_LST parameter of the calling function and the order in which they are specified on the RCV_LIST of the called function is significant - the working lists must appear in the same order in the called and calling functions, otherwise errors could occur.

is used to specify that this function is to act as a "trigger" for a data dictionary field or a database file.

...