You are here: LANSA for i User Guide > 4. Processes and Functions > 4.23 Miscellaneous Process Details > 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:

 

 DC@P301801                 Basic Process Options                      

                                                                       

 Process : ORDERS . . . INQUIRE AND/OR MAINTAIN COMPANY ORDERS         

                                                                       

 Process description  . . . . . INQUIRE AND/OR MAINTAIN COMPANY ORDERS  

                                                                       

 Anticipated usage  . . . . . . HEAVY                                  

                                                                       

 Process/menu style . . . . . . CURSOR                                

                                                                       

 Optimise for remote comm's .. N  Y=Yes, N=No                          

 

 Enabled for the Web . . . . . N  Y=Yes, N=No                          

                                                                       

 Enabled XML generation. . . . N  Y=Yes, N=No                          

                                                                       

 Function keys:    Exit   Menu  Messages  Add  Change  Delete        

                    1      2       7       9    10      11          

                                                                       

 Fnn=Help  Fnn=Exit  Fnn=Cancel  Fnn=Messages                          

 

 

From the Basic Process Options screen it is possible to:

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 LANSA Application Design Guide 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 Technical Reference Guide 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:

     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

Enabled for the Web?

Specifies whether Web-enable has been selected for all functions within this process. Allowable values are:

N

The Web will not be enabled for any functions within this process.

Y

All functions within this process will be web-enabled. 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 Web Enabling a LANSA Process in the Web Functions Guide 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 any 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 Web Enabling a LANSA Process in the Web Functions Guide 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).