Using "Optimize for Remote Communications"

Date: Archived
Product/Release: LANSA for the AS/400
Abstract: Functions compiled on a process with the "Optimize for Remote Communications" flag set to 'Y' can cause unexpected results
Submitted By: LANSA Technical Support

The "Optimize for Remote Communications" flag (specified on the Process "Miscellaneous" option), when set to Y, is used to minimize the amount of data sent when a DISPLAY, REQUEST, or POP_UP command is executed. It is recommended only for very slow communication lines

Allowable values are:

"N" Remote communications will not be optimized for all functions within this process. This is the default value used for all new processes created.

"Y" Remote communications will be optimized for all functions within this process.

When "Y" is used, and a process menu and its associated functions are (re)compiled, be aware of the following things that may affect your application:

Compiled process menu display files are created with RSTDSP(*NO) to stop the OS/400 restore display "flash" from occurring when a process menu is (re)presented after executing a function. Additionally the compiled process itself uses slightly modified logic to cater for this change.

Compiled RDML function display files are created with RSTDSP(*NO) to stop the OS/400 restore display "flash" from occurring when returning from a call to another RDML function or 3GL program.

The generated DDS statements make use of the special keywords PUTOVR (put overrides), OVRATR (override attributes) and OVRDTA (override data) to significantly reduce the amount of information (re)sent to the display device on (re)displays of the same screen panel. Generally only fields and their display attributes are (re)sent on a (re)display of the same screen panel. Textual information such as panel titles, field identification details, etc., are not re-sent.

The screen panel handling code generated for an RDML function is changed to make use of the PUTOVR, OVRATR and OVRDTA key- words. This logic involves a special field called OA@LSQ that is used to track the last screen panel that was presented. Whenever a screen panel is to be presented this value is examined. If it matches the sequence number of the current screen panel command, the PUTOVR keywords are used to reduce the amount of information being (re)sent to the device.

The fact that textual information is not re-sent can have a detrimental effect on screen panels that use the DEF_COND command to alter the fields and identification details that are visible between subsequent (re)displays of the same screen panel. This effect is immediately apparent, and can be easily corrected by altering the value in field OA@LSQ. Refer to the LANSA for the AS/400 User Guide for more details.

Note: This change affects compiled process menus only. It does not affect the way interpretive mode process menus are (re)presented on a display device.

This option only aids when the same screen panel is being redisplayed. It cannot aid in any way when the screen panel is not already present on the display device.

The preceding point indicates that when an application is being designed for frequent and heavy usage on remotely attached display devices, there is no better performance aid than the minimization of the amount of information shown on, and therefore sent to and/or received from, the remote display device.

Note: "Optimize for Remote Communications" flag meaningless in LANSA for the Web and LANSA for Windows generated applications.