4 23 2 Miscellaneous Process Details Maintenance

4.23.2 Miscellaneous Process Details Maintenance

When the option to define review or change miscellaneous process details is chosen from the process definition menu a screen similar to the following example will result:

From the Basic Process Options screen it is possible to:

• Review the miscellaneous process details.

• Change the miscellaneous process details. Use the CHANGE key to place the screen in change mode and make the desired changes.

Input Options

The following input options apply to changing miscellaneous process details.

Process Description

Specifies the description to be associated with the process. A brief description must be specified for every process created The description aids other users of this process in identifying what it can be used for. See selecting required processes earlier in this chapter.

Anticipated Usage

Specifies what amount of usage of the process in anticipated.

In technical terms this value indicates whether or not the RPG programs created for the functions in this process should set on the LR (last record) indicator and close all files when terminating.

This value can be changed dynamically (without having to recompile any programs) so it may be worthwhile experimenting with it to modify system performance/throughput.

Process/Menu Style

Specifies the "style" of the process that is being reviewed. Allowable values are:

Note: The following list of menu styles are now considered to be obsolete and their use is not recommended for new systems. They are supplied purely to allow compatibility with existing systems.

Optimize for Remote Communications?

Specifies whether remote communications are optimized for all functions within this process.

Allowable values are:

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

• Compiled process menu display files are created with RSTDSP(*NO) to stop the IBM i 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 IBM i 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. See the following points for more details.

• The use of this option can also adversely effect the ":" (full colon) or "." (period) that are used on the end of automatically generated field descriptions (identification method *DESC) in some situations where the screen mode is automatically changed. This is a minor cosmetic problem that may occur in some applications, but it will not effect the application in any other way.

• The use of this option can also affect the automatic display of column headings on a browse list. When a display of an empty list is (re)displayed with a list containing data, the column headings may not appear. The reverse of this is also true, when a display of a list containing data is (re)displayed with an empty list the column headings may still be displayed. Again, this minor cosmetic effect can be corrected by making reference to the OA@LSQ field.

• The use of this option with POP_UP commands that then invoke other external routines such as help, messages, prompt key processing or calls to other functions or 3GL programs may be cosmetically effected by this option.
  Although the (re)display of the original POP_UP window is fully completed, the "background" may disappear because the RSTDSP(*YES) option is required to put back any part of the screen panel that was not created by the POP_UP command.

• Field OA@LSQ is accessible at the RDML program level. Simply define field OA@LSQ in your data dictionary as a packed decimal field of length 7, with 0 decimals, and you alter its value at the RDML level.
  The most common change to this field is to set its value to zero to "trigger" a complete resend of an entire screen panel that is being (re)displayed on the display device.
  
  Some actions automatically reset this field to cause a complete resend of all screen data. These include:

• A CALL to another RDML function or 3GL program.

• Executing a BROWSE command.

• Executing a MESSAGE TYPE(*WINDOW) command

• Executing a different DISPLAY, REQUEST or POP_UP command within the same function.

• Using the help function key (usually F1). Note also that using this option prevents the use of the actual engraved help key, because screen data could be lost.

• Using the Messages function key.

• Using the Prompt function key.

     Access to this "trigger" field allows you to specifically handle situations that require a complete resend of all information to the display device.

     For instance, because the generated code is unaware that the IBM i command DSPWTR has overwritten its current screen panel, the following RDML logic will not work correctly when the remote communications option is used:

              BEGIN_LOOP

               REQUEST    FIELDS(#PRINTER) IDENTIFY(*DESC)

               EXEC_OS400 CMD('DSPWTR #PRINTER')

              END_LOOP

     When the REQUEST command is (re)executed it will only send the field #PRINTER, and not send any identifying text such as the panel title or the field description.

     To correct this problem, and to make the (re)execution of the REQUEST command send the complete screen panel to the display device, simply add the reference to #OA@LSQ like this:

              BEGIN_LOOP

               REQUEST    FIELDS(#PRINTER) IDENTIFY(*DESC)

               EXEC_OS400 CMD('DSPWTR #PRINTER')

               CHANGE     FIELD(#OA@LSQ) TO(*NULL)

              END_LOOP

• Note that 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 minimisation of the amount of information shown on, and therefore sent to and/or received from, the remote display device.

Enabled for the Web?

Specifies whether LANSA for the WEB is enabled for all functions within this process. Allowable values are:

Enable XML Generation?

Specifies whether XML Generation is enabled for all functions within this process. Allowable values are:

Function Keys

Specifies the assignment of function keys to functions within this process.

This information only appears on the screen when reviewing a process in a non-SAA/CUA partition, or when specifically reviewing a non-SAA/CUA process. In an SAA/CUA style process all function key assignments exactly follow those defined for the associated partition.

If desired, change the function key number assigned to the function. Function key numbers specified for any of the functions must be in the range 1 - 24. The same function key cannot be assigned to more than one function.

Function key assignments can be changed dynamically (without having to recompile any programs).