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 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.
|
LIGHT |
Anticipated usage is light. The process will not be used repeatedly and continuously. Most processes are considered to be LIGHT usage. |
|
HEAVY |
Anticipated usage is heavy. The process will be used repeatedly and continuously. This option is normally only used in repetitive data entry applications. |
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:
|
SAA/CUA |
All menus and screen formats used by this process and any of its associated functions are to conform to the SAA (Systems Application Architecture) and/or CUA (Common User Access) standards defined for the partition in which the process is being defined. Refer to SAA/CUA Partitions in IBM i SAA/CUA Implementation in the for more details of what the SAA/CUA standards are for a partition and how they apply. |
|
ACT/BAR |
The process is to act as an "Action bar" as defined by the CUA (Common User Access) standards defined by IBM and for this partition. To use this option the following prerequisites must be satisfied: - The current partition must be SAA/CUA enabled. - You must read all relevant information in the and the LANSA Application Design Guide and the IBM supplied CUA 1989 Basic Interface Design Guide. - You must be totally committed to the CUA 1989 standard for the "look" and "feel" of your application software. |
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.
|
CURSOR |
Entries are to be selected from the process menu by positioning the screen cursor on the same line as the entry. |
|
NUMBER |
Each entry on the menu is to be assigned a number. An entry is selected by entering the number associated with the entry into a field at the bottom of the screen. This is the "traditional" style of menu and is the most commonly used in other IBM i application systems. |
|
FUNCTION |
Entries on the menu are to be displayed with their associated function name. An entry is selected by entering the name of the associated function into a field at the bottom of the screen. This style of menu processing is called "next function" processing and allows the users to go from function to function without having to return to the process menu. Refer to 4.18 Function Control Table for more details. |
Optimize for Remote Communications?
Specifies whether remote communications are optimized for all functions within this process.
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, 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:
|
N |
The Web will not be enabled for all functions within this process. |
|
Y |
LANSA for the Web will be enabled for all functions within this process. When functions within this process are compiled, graphical HTML pages will be generated for the screens in the functions. These functions may then be deployed on the IBM i (5250 emulation) or on the Internet. Refer to for more information. |
Enable XML Generation?
Specifies whether XML Generation is enabled for all functions within this process. Allowable values are:
|
N |
XML generation will not be enabled for all functions within this process. |
|
Y |
XML generation will be enabled for all functions within this process. When functions within this process are compiled, XML will be generated for the screens in the functions. These functions may then be deployed on the IBM i (5250 emulation) or over HTTP to XML enabled devices. Refer to for more information |
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).