Brief: The new Graphical DDS keywords make it very easy to add menu bars and pulldown menus to your AS/400 programs. But when using these keywords to describe a menu, you have many design choices to make. This two-part article presents a working example which teaches you how to use the new keywords. It also discusses the design choices that you have and guidelines for deciding when to use the various options.
In the July 1993 issue of Midrange Computing, "Pull-down Menus and More" introduced the new Graphical DDS (GDDS) keywords available in V2R2 with PTF SF11703 and officially included in V2R3. As described in the article, the keywords include support for menu bars and pulldown menus, check boxes and radio buttons, cursor control, edit masks and other enhancements-in other words, functions that let you create a graphical look with display files.
These new capabilities work with all types of display devices attached to the AS/400, from the earliest 5250 terminals to PCs running RUMBA in Windows or OS/2 and everything in between (including the new mouse-capable InfoWindow II terminals). As you use a more capable device, the graphical look is enhanced. The greater capabilities are handled by OS/400 and the workstation controller that attaches the device. This extremely valuable feature enables you to take full advantage of device capabilities without having to create different versions of a display file.
As with other software capabilities, there are design and implementation issues that you must understand and address. It is actually quite easy to use the new GDDS keywords to create menu bars and pulldown menus. But within just those two features are many options that you can use. To understand these options, we will use the new GDDS keywords to create a sample display file over the course of two articles. We'll also build an RPG program to drive the display file.
This first installment looks at defining and displaying menu bars and addresses the associated design considerations, with partial DDS and RPG examples to illustrate our progress. In next month's installment, we'll expand the same display file and code fragments into full, operational code. Part 2 will include further discussion of single-choice menus and will introduce multiple- choice and no-choice menus.
With this month's DDS and RPG fragments, we can explore these features:
o Using a variable number of items on the menu bar. o Defining a menu-bar separator. o Using a single-choice, pulldown menu.
As you'll see by working through the example, simply using GDDS does not guarantee an effective user interface. If anything, you need to be even more aware of how you present the interface to your users, since many of them have become familiar with menu bars and pulldowns from PC software. The advances promised by GDDS are not just that we can use the capabilities, but that we can also make use of a great deal of experience developed over the past several years as graphical user interfaces (GUIs) have become widely used.
Creating the Example
The figures contained within this article are actually excerpts from a complete display file and RPG program which will be published next month, in Part 2 of this series. For spatial reasons, I have included only those fragments that illustrate the specific topics covered this month. But you don't have to wait until next month to download the code in its entirety-it's available now on MC-BBS.
Before attempting to incorporate the GDDS keywords in a display file, first make sure that your system is operating at the correct release level. If your machine is running V2R3, you do not have to do anything special to use the GDDS keywords explained here. If you use V2R2, you need to order and apply PTF SF11703 if next month's display file and RPG program (and the excerpts published this month) are to work as presented.
What the Example Does
The display-file excerpt in 1 includes a menu bar, a menu-bar separator and partial definitions for pulldown menus associated with items in the menu bar. When the menu bar appears on-screen, it is displayed over the current display. The current display is not erased by the menu bar. This typical use of a menu bar display shows how you can add a menu bar to existing programs.
The display-file excerpt in Figure 1 includes a menu bar, a menu-bar separator and partial definitions for pulldown menus associated with items in the menu bar. When the menu bar appears on-screen, it is displayed over the current display. The current display is not erased by the menu bar. This typical use of a menu bar display shows how you can add a menu bar to existing programs.
In order to display the menu bar and pulldown menus without erasing the current display, the ASSUME and OVERLAY keywords are used in the DDS. Record format ASSUME contains the ASSUME keyword. The ASSUME keyword requires at least one displayable field defined in this record format (the example uses a single blank space). It is not necessary to actually use the record format in the RPG program. We satisfy the requirement of the display file by simply including this record format in the DDS for the display file.
The OVERLAY keyword is used in the MENUBAR record format. It is required in this format because we are writing the record format to the display and we do not want to replace the entire panel.
The first time it is displayed, the menu bar contains just two items: Menu and Exit. Other items are defined, but they are controlled by indicators which will remain off in this example. Selecting a menu item to display its associated pulldown menu is done differently, depending on the display device you are using. For the examples, I am assuming that the display device is a mouseless, nonprogrammable, non-Enhanced User Interface (EUI) type of device-in other words, your plain-vanilla dumb terminal. To select a menu item, you position the cursor to the immediate left of the item and press Enter.
Defining the Menu Bar
Record format MENUBAR defines the content of the menu bar and the options used. The MNUBAR keyword indicates that this record format is a GDDS menu bar. It is displayed starting on line 1 of the display. The menu-bar items are displayed horizontally across that top line. The MNUBAR record format also includes a menu-bar separator.
In addition to the MNUBAR keyword, the MNUBARDSP keyword is used. This tells DDS that the menu bar is to be displayed when the record format is written. This seems redundant, since the MNUBAR keyword previously defined the record as a menu-bar record. The reason you need MNUBARDSP has to do with how the system processes menu-bars and pulldown-menus.
The MNUBARDSP keyword has two uses; one for records which do not contain the MNUBAR keyword and one for records that do. In the first usage, you specify the keyword on a record that is not a menu-bar record. In this case, there are two required parameters (menu-bar-record and menu-bar choice-field) and one optional parameter (pulldown-menu-selection-field). This format is used if the MNUBARDSP keyword is in a record format that does not include the MNUBAR keyword. For example, you can define your application display and include the MNUBARDSP keyword to associate a menu-bar record with the application display. This concept is similar to the WINDOW keyword, where you can use the keyword either to define the window or to refer to another record format that defines the window.
The result of using MNUBARDSP in an application record format is that when a program displays the application format, the menu bar is also displayed, without the program having to explicitly write the menu-bar record format.
I do not choose to use that form of the MNUBARDSP keyword for the simple reason that I want to keep a separation between the application display and the menu- bar display. The degree of separation goes beyond just keeping the menu-bar and application record formats separate. I prefer to perform the menu-bar processing and to define the application record formats in two different programs.
The primary motivation for this design is that the processing associated with each task is done in its own program. As you will see in next month's installment, the processing for the menu-bar and pulldown options can become complicated. Rather than include that additional level of complexity in the application program, I find it advantageous to process the menu bar independently of the application using it. Instead of including code to process options from the pulldown menus, all I have to do is put a value into a parameter that is passed back to the application program. The application program then chooses the required processing, based upon the parameter value.
This separation simplifies the menu bar and the application program tremendously. It also enables you to test the menu-bar program independently of the application program, since you can plug in the parameter value using either a Change Program Variable (CHGPGMVAR) command in debug mode or a simple screen- input field where you type in the value.
In order to implement my design, I use the second format of the MNUBARDSP keyword. As shown in the excerpted DDS, the keyword is specified in the same record format as the MNUBAR keyword. In this case, you can specify one optional parameter, a numeric field that will contain the value of an item selected from a pulldown menu.
You might wonder why you actually need to specify MNUBARDSP in the same format with MNUBAR. The reason is that the system controls display input/output (I/O) whenever the menu-bar format is displayed. The MNUBAR keyword simply identifies a record format that describes the content of the menu bar. Once you display the menu bar, the system takes care of displaying and removing any pulldown menus that you select. In RPG terms, you never EXFMT a pulldown menu. The system writes and reads a pulldown menu when it is selected from the menu bar. You indicate to the system when you are giving it control by writing a record that contains the MNUBARDSP keyword.
The first field defined in the menu bar record is MNUFLD. Although this field must be defined as shown in the example, it does not appear on the display as a two-byte numeric field on line 1. Instead, the field is used to return a value to a program that indicates the menu-bar item selected. This will be explained in a moment.
The next keyword, MNUBARSEP, is defined as a field-level keyword, although it defines the menu-bar separator that applies to the menu-bar record format. The menu-bar separator is used to delimit the menu-bar items from the rest of your application display.
In the example, I have defined the separator to be a solid underline across the screen. On an 80-column display, the separator (underline) appears in columns 2-79. If you do not specify your own MNUBARSEP, the system displays a default of dash characters as the separator.
This keyword seems to be mistakenly placed at the field level and not the record level. I hope that in future releases IBM will make it a record-level keyword also, since that is where it would logically be specified.
The next several MNUBARCHC keywords define the menu-bar choices or items that you want included in the menu bar. The keyword has four parameters, the first three of which are required.
The first parameter is the choice identifier. This is a value from 1 to 99. Menu items are displayed in ascending numeric order, regardless of their order in the DDS.
The second parameter of MNUBARCHC is the name of the record format in the same display file that defines the pulldown menu associated with the selection. This can be any valid record-format name. The record format must contain the PULLDOWN keyword. Although it is unlikely that you would do so, you can use the same record format on more than one MNUBARCHC keyword.
The third parameter is used to define the text that is displayed in the menu bar. This can be defined as either a text constant, as shown in the example, or as a program-to-system field. A program-to-system field lets you dynamically alter the text of a menu-bar item. This is useful if you are creating an application to be used for different national languages. Using the program-to- system field, you can obtain the required text from a message file and display it in the menu bar.
The example also shows how to specify the optional mnemonic character used for the menu-bar item. You designate the mnemonic by placing the greater than (>) character to the immediate left of the character to be used. On workstations that support it, the mnemonic is displayed as a single-character underline within the menu item. For example, the >Menu item displays as the word Menu on low-function workstations and as Menu on higher-function workstations. Using the mnemonic allows users on higher-function terminals to select the menu-bar choice by simply entering the underlined character anywhere in the menu-bar record. On terminals that do not support the use of mnemonics, the user must tab to the menu bar item, and press Enter.
The rules for mnemonics are simple. The primary rule is that, within a set of mnemonics (for example, in this set of MNUBARCHC keywords), the mnemonics must be unique among all of the selections. The character selected as the mnemonic cannot be a blank. Another rule is that, to use the greater-than sign (>) within the text of an item, you must specify two greater-than signs together.
The optional fourth parameter of the MNUBARCHC keyword is the return field, defined as a hidden numeric field. This parameter indicates that the system should not display the associated pulldown menu, but instead should return to the program that processes the menu-bar choices. Upon returning to this program, the value in the return field is the menu-item identifier.
In the example, when the Exit! menu-bar item is selected, the EXIT pulldown menu format is not displayed. Instead, the program gets control immediately. (The program is excerpted in 2). The value in EXITRF is 99, which is the identifier of the Exit! item. (The exclamation mark in Exit! is used to indicate to the user that the action happens immediately with no pulldown menu. The system does not require that we give any special indication, but you might want to consider using such an option.)
In the example, when the Exit! menu-bar item is selected, the EXIT pulldown menu format is not displayed. Instead, the program gets control immediately. (The program is excerpted in Figure 2). The value in EXITRF is 99, which is the identifier of the Exit! item. (The exclamation mark in Exit! is used to indicate to the user that the action happens immediately with no pulldown menu. The system does not require that we give any special indication, but you might want to consider using such an option.)
There are two uses of the return field. The first use, shown here, is to process a menu-bar item that does not have any items on its associated pulldown menu. A further look into the partial display file shows that you do, in fact, have to define an EXIT record format with the PULLDOWN keyword. That record format does not include any menu items. To process the Exit! selection immediately, we include the return field so that the processing program gets control when the item is selected. When the return field is used, the value of the menu item is not put into the menu-choice field but into the return field itself. When you select the Exit! item, the value of MNUFLD is zero and the value of EXITRF is 99. The program can base its processing upon those values. Looking into the program excerpt in 2, you can see the section where EXITRF is tested. When it has the value 99, meaning that the Exit! option was selected, the program ends.
There are two uses of the return field. The first use, shown here, is to process a menu-bar item that does not have any items on its associated pulldown menu. A further look into the partial display file shows that you do, in fact, have to define an EXIT record format with the PULLDOWN keyword. That record format does not include any menu items. To process the Exit! selection immediately, we include the return field so that the processing program gets control when the item is selected. When the return field is used, the value of the menu item is not put into the menu-choice field but into the return field itself. When you select the Exit! item, the value of MNUFLD is zero and the value of EXITRF is 99. The program can base its processing upon those values. Looking into the program excerpt in Figure 2, you can see the section where EXITRF is tested. When it has the value 99, meaning that the Exit! option was selected, the program ends.
The second use of a return-field option on a menu-bar item is when you want to update pulldown menu selections before the menu is displayed.
This dynamic update capability of pulldown menu selections is useful in situations where you cannot predict when the updates must occur or what the text will be. For example, you can use this to dynamically add pulldown menu items to review your most recently submitted batch jobs, including the qualified job name as part of the selection text. Because you cannot predict ahead of time what the qualified job name will be, you cannot update the pulldown menu before it is requested. Later, we will explore other ways to dynamically format selections.
The final feature to note about menu-bar definition is the use of conditioning indicators on the MNUBARCHC keywords. As with any other DDS keyword, the value is selected if the indicator is on when the record format is displayed. In this example, the User and Options menu-bar items are conditioned. The program controls whether these items are displayed when the menu bar is shown by setting the conditioning indicators on or off.
Displaying the Menu Bar
There are no special considerations for displaying the menu-bar record. The RPG fragment shows the never-ending loop used to process the menu bar. The EXFMT statement displays and reads the record format. Because we have not enabled the conditioning indicators prior to the first EXFMT of the menu bar, only two menu-bar items are initially displayed: "Menu" and "Exit!"
When control returns to the program after the user has selected a pulldown menu and entered a choice from that menu, we have values in the three fields. For MNUBARCHC options that do not include the optional return field, the menu-bar item identifier is in the MNUFLD field-this tells us which pulldown menu the user selected. Looking at the partial RPG program, you can see that each pulldown menu is processed within the SELEC group.
The OPTION field's purpose is to determine which option has been selected from a pulldown menu that only allows a single-choice selection field, as we're assuming here. (We will discuss single-choice selection fields next month.) You would generally set up a SELEC group for the options of a pulldown menu within the SELEC group for the menu-bar item. Once you determine which option has been selected, you can do any processing required for the option. At this point, I usually format a return parameter to indicate which menu option was selected and return to my calling program. We will cover this in more detail next month, along with the discussion of multiple-choice menu options.
The final field, EXITRF, is used only in the event that the EXIT item is selected. You will use this field only if you need to update pulldown menus or if you are working with no-menu items. In the sample program, this field is also processed within the SELEC group that chooses which pulldown menu to process.
Menu-bar Design Considerations
If you use more menu-bar items than the first line of the display can accommodate, the additional items are placed on the second line. This can continue for up to 12 lines of menu-bar items. However, you should design the selections so that your menu bar never exceeds one line. If the selections wrap to another line, you have too many menu-bar items or the text for each item is too lengthy.
When designing a menu bar, you should keep in mind some of the ergonomic factors that cause people to associate GUI with "ease of use." One factor is that people can generally deal with only five to seven different tasks at once. Translated to menu-bar usage, that means you can expect your users to start reaching the limits of their abilities when you have that many menu-bar items. I find this true in my own experience. Even when working with what I consider to be well-designed Windows applications, I frequently have to hunt through several pulldown menus when there are "too many" of them. Unless your menu-bar items are extremely distinctive, you should try to stay within the range of five to seven items.
In terms of text for menu-bar items, the generally accepted practice is to use one word. Although the GDDS implementation will let you use any number of words, that would constitute poor design. On most terminals, apart from the three blank spaces between menu-bar items, nothing indicates to your users that the separate words make up one menu-bar item or represent additional items. A menu bar is not the place to be overly descriptive.
You should also try to follow conventions in terms of the placement of items on the menu bar. In Windows applications, the first items (from left to right) are usually File, Edit and View. A Help item is almost always included as the last (rightmost) item.
This brings up a problem for AS/400 menu design. Based on my experience of implementing a pulldown menu system, picking the menu-bar items is one of the most difficult aspects of creating the menu bar. The typical Windows File-Edit selections do not usually seem to apply. I settled on associating the first item with the underlying screen. For example, in an Order Entry application, if the underlying display is the Order Header, I would probably use either Order or Header as the first menu-bar item. When the user changes to the Customer Master lookup display, I would change the first item to Customer. Under those menu-bar item headers, the pulldown menu would have selections that apply to orders or customers.
After the first item, you can have selections that become more generic as you go across the menu bar. Most AS/400 applications involve more than one display. For example, to process an order, your application may have three or four unique displays, depending upon how far the user has progressed in entering the order. You can create a generic "View" menu item that can be used to select which panel to view. I call this a "generic" item because it will be used on all of the displays within an application. The selections within the View pulldown menu are updated when going to another display. For example, when you are on the Order Header panel, the View menu might include an option to "view order details." When you go to the Order Details panel, you would update the View menu to remove the "view order details" selection.
The most important aspect of menu-bar item selection, as far as your users are concerned, is that you be consistent with your choices and their placement. Consistent choices mean that your users can form an expectation of what selections will appear on the pulldown-menu formats. Consistent placement means that the items are in the same relative order on each display. The actual position of the items is not as important as the ordering. The menu-bar items expand and contract as you show more or fewer items. The position is not constant, but the order is. For more information on menu bars and pull-downs, see the SAA CUA panel design manual listed at the end of this article.
Coming Next Month
IBM provided an excellent upgrade to DDS with the new GDDS keywords. With just a few lines of code in a display file, you can include a fully functional, pulldown-menu interface. But as I've tried to show in this first article, there are many design considerations that apply to the menu bar itself. It makes little sense to implement this type of interface if you ignore the common-sense and customary practices that have evolved over the past several years. Although AS/400 applications contain almost no examples of menu bars and pulldown menus, you can experiment with any Windows or Macintosh application to get a feel for how menu bars are used and study the design factors involved. With GDDS, IBM has made the technical implementation easy. It is up to you to supply an intelligent design.
Next month, we will look at what goes on "under" the menu bar. There are two types of pulldown menus: single-choice and multiple-choice. Practically all implementations of pulldown menus are the single-choice type, but we will review the multiple choice type so that you will understand why it is not the preferred technique. Also included is the full DDS and RPG source code to complete the example
Craig Pelkie can be reached through Midrange Computing.
REFERENCES DDS Reference (SC41-9620, CD-ROM QBKA7402) SAA Common User Access Panel Design and User Interaction (SC26-4351).
Menu Design & Implementation w/ Graphical DDS: #1
Figure 1 DDS for Menu Bar Support
A*===============================================================
A* To compile:
A*
A* CRTDSPF FILE(XXX/GUI004DF) SRCFILE(XXX/QDDSSRC)
A*
A*===============================================================
A CA11
A WDWBORDER((*CHAR ' ||---'))
A VLDCMDKEY(91 'VLDCMDKEY')
A****************************************************************
A* Record format ASSUME - define ASSUME keyword for file
A****************************************************************
A R ASSUME TEXT('ASSUME record')
A ASSUME
A 1 2' '
A****************************************************************
A* Record format MENUBAR - Menu bar definition
A****************************************************************
A R MENUBAR TEXT('Menu Bar record')
A INDTXT(22 'Enable USER format')
A INDTXT(23 'Enable OPTN format')
A OVERLAY
A MNUBAR
A MNUBARDSP(&OPTION)
A MNUFLD 2Y 0B 1 2TEXT('Menu choice field')
A MNUBARSEP((*DSPATR UL) +
A (*CHAR ' '))
A 22 MNUBARCHC( 2 USER '>User')
A 23 MNUBARCHC( 3 OPTN '>Options')
A MNUBARCHC(99 EXIT 'E>xit!' &EXITRF)
A MNUBARCHC( 1 MENU '>Menu')
A OPTION 2S 0H TEXT('Selection in PULLDOWN')
A EXITRF 2Y 0H TEXT('Return field from Exit')
A****************************************************************
A* Record format MENU - Menu pulldown
A****************************************************************
A R MENU TEXT('MENU pulldown')
A PULLDOWN
A MSEL 2Y 0B 1 1TEXT('MENU selection field')
A MLTCHCFLD
A CHOICE( 1 '>User tasks')
A CHOICE( 2 'Set >Options')
A CHOICE(91 '>Enable all')
A CHOICE(92 '>Reset all')
A CHOICE(99 'E>xit')
A CHCCTL( 1 &CTL01)
A CHCCTL( 2 &CTL02)
A CHCCTL(91 &CTL91)
A CHCCTL(92 &CTL92)
A CHCCTL(99 &CTL99)
A CTL01 1Y 0H TEXT('CHCCTL for User tasks')
A CTL02 1Y 0H TEXT('CHCCTL for Options')
A CTL91 1Y 0H TEXT('CHCCTL for Enable all')
A CTL92 1Y 0H TEXT('CHCCTL for Reset all')
A CTL99 1Y 0H TEXT('CHCCTL for Exit')
A****************************************************************
A* Record format USER - User pulldown
A****************************************************************
A R USER TEXT('USER pulldown')
A PULLDOWN
A INDTXT(31 'Condition WRKACTJOB')
A USESEL 2Y 0B 1 1TEXT('USER menu selection')
A SNGCHCFLD
A CHOICE(1 'Work with >Job queues')
A CHOICE(2 'Work with >Output queues')
A 31 CHOICE(3 'WRK>ACTJOB')
A CHOICE(4 'WRK>SYSSTS' *SPACEB)
A CHCCTL(4 &CTL04)
A CTL04 1Y 0H TEXT('CHCCTL for WRKSYSSTS')
A****************************************************************
A* Record format OPTN - Set Options pulldown
A****************************************************************
A R OPTN TEXT('OPTN pulldown')
A PULLDOWN
A OPTSEL 2Y 0B 1 1TEXT('OPTN menu selection')
A SNGCHCFLD
A CHOICE(1 &OPTNTX)
A CHCACCEL(1 'F11')
A OPTNTX 35 P TEXT('Option text field')
A****************************************************************
A* Record format EXIT - Exit menu pulldown
A****************************************************************
A R EXIT TEXT('EXIT')
A PULLDOWN
Menu Design & Implementation w/ Graphical DDS: #1
Figure 2 RPG Code for Menu Bar Support
*===============================================================
* To compile:
*
* CRTRPGPGM PGM(XXX/GUI004RG) SRCFILE(XXX/QRPGSRC)
*
*===============================================================
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
FGUI004DFCF E WORKSTN
I 'Enable WRKACTJOB in -C ENATXT
I 'User menu'
I 'Disable WRKACTJOB - C DISTXT
I 'in User menu'
C*
C *ON DOWEQ*ON
C EXSR MNUBAR
C ENDDO
C*
C*****************************************************
C* Initialize program, set choices in menu formats
C*****************************************************
C*
C *INZSR BEGSR
C Z-ADD2 CTL92 *Disable Reset
C WRITEMENU *Initialize fmt
C*
C MOVEL*OFF *IN31 *Disable WRKACT
C WRITEUSER *Initialize fmt
C*
C MOVELENATXT OPTNTX *Set OPTN text
C WRITEOPTN *Initialize fmt
C ENDSR
C*
C*****************************************************
C* Display/process menu bar
C*****************************************************
C*
C MNUBAR BEGSR
C EXFMTMENUBAR
C SELEC
C*
C*****************************************************
C* Process Valid Command Key - across all menus
C*****************************************************
C*
C *IN91 WHEQ *ON *VLDCMDKEY
C EXSR CMDKEY
C*
C*****************************************************
C* Process MENU format - must read for MLTCHCFLD
C*****************************************************
C*
C MNUFLD WHEQ 1 *MENU format
C READ MENU 9999*99 - ERR/EOF
C*
C CTL99 IFEQ 1 *EXIT
C MOVEL*ON *INLR
C RETRN
C ENDIF
C*
C SELEC
C CTL91 WHEQ 1 *Enable all
C Z-ADD1 CTL01 *Selected
C Z-ADD1 CTL02 *Selected
C Z-ADD2 CTL91 *Unavailable
C*
C CTL92 WHEQ 1 *Reset all
C MSEL OREQ 0 *No selections
C Z-ADD0 CTL01 *Available
C Z-ADD0 CTL02 *Available
C Z-ADD0 CTL91 *Available
C Z-ADD2 CTL92 *Unavailable
C ENDSL
C*
C SETOF 2223 *Do not display
C*
C CTL01 IFEQ 1 *USER menu
C SETON 22 *Display
C Z-ADD0 CTL92 *Enable Reset
C ENDIF
C*
C CTL02 IFEQ 1 *OPTN menu
C SETON 23 *Display
C Z-ADD0 CTL92 *Enable Reset
C ENDIF
C*
C WRITEMENU *Update menu
C*
C*****************************************************
C* Process USER menu
C*****************************************************
C*
C MNUFLD WHEQ 2 *USER menu
C*
C*****************************************************
C* Process OPTN menu
C*****************************************************
C*
C MNUFLD WHEQ 3 *OPTN menu
C SELEC
C OPTION WHEQ 1 *Selected Opt 1
C EXSR SETOPT
C ENDSL
C*
C*****************************************************
C* Process EXIT menu
C*****************************************************
C*
C EXITRF WHEQ 99 *EXIT menu
C MOVEL*ON *INLR
C RETRN
C ENDSL
C*
C ENDSR
C*
C*****************************************************
C* Process valid command keys
C*****************************************************
C*
C CMDKEY BEGSR
C *INKK IFEQ *ON *CF11
C EXSR SETOPT
C ENDIF
C ENDSR
C*
C*****************************************************
C* Set options for USER and OPTN menu
C*****************************************************
C*
C SETOPT BEGSR
C CLEAROPTNTX *OPTN text
C*
C *IN31 IFEQ *OFF *WRKACT disabld
C MOVEL*ON *IN31 *Enable WRKACT
C MOVELDISTXT OPTNTX *Set text
C ELSE *WRKACT enabled
C MOVEL*OFF *IN31 *Disable WRKACT
C MOVELENATXT OPTNTX *Set text
C ENDIF
C*
C WRITEUSER *Update menu
C WRITEOPTN *Update menu
C*
C ENDSR
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online