Brief: When you use GDDS to define menu bars and drop-down menus, you can choose from three types of pulldown menus. The first type is a multiple-choice menu. The second type, the single-choice pulldown menu, is the most commonly used and is easy to program and work with. The final choice is a menu that has no choices on it-just the word on the menu bar. This article examines each of these menu types, explains how to code them and addresses the design considerations you face when using them.
In last month's article, we saw that something as seemingly simple as defining a menu bar involves many choices. Because menu-bar and pulldown-menu implementation is primarily a user interface issue and not a programming issue, you must devote most of your effort to designing an easy-to-use menuing system. Users have expectations of how pulldown menus should work. This is not the place to demonstrate technical wizardry by overstepping or ignoring commonly expected practice.
With that in mind, we'll look at three types of menus that you can implement. Last month's DDS and RPG fragments have been expanded to full, operational code, with working examples of multiple-choice, single-choice and "no-choice" menus. By examining the multiple-choice menu in detail, you should see that this menu format is much more complicated to program and use than the preferred single-choice menu format. Within the single-choice format, you must consider the ordering of the menu items, the spacing between them, when to "gray" a menu choice and when not to display a menu choice. The final menu choice, a no- choice menu, is a special case that may be useful in small doses.
Multiple-choice Menu
The first pulldown menu in 1 is the MENU record format. This is an unusual pulldown menu, since you can choose more than one item within the pulldown menu.
The first pulldown menu in Figure 1 is the MENU record format. This is an unusual pulldown menu, since you can choose more than one item within the pulldown menu.
You can define a record format as a pulldown menu by including the record-level PULLDOWN keyword. A pulldown record is a special case of a DDS window. The border used with the pulldown menu can be specified with the WDWBORDER (window border) keyword. In the example display file, WDWBORDER is specified at the file level, so that it applies to all of the pulldown (and other WINDOW) formats within the file. If you want to specify different window borders, you can specify WDWBORDER at the record-format level.
Each pulldown menu format includes at least one input/output (I/O) field. In our example in 1, we use the MSEL field for the MENU format. This is a two-byte numeric field, starting at line 1 position 1. Like the MNUFLD we defined in the MENUBAR record format last month, the selection field is not actually displayed. Instead, the system either formats one or more fields for you to make a selection or displays radio buttons or check boxes depending on the terminal and controller support available at runtime.
Each pulldown menu format includes at least one input/output (I/O) field. In our example in Figure 1, we use the MSEL field for the MENU format. This is a two-byte numeric field, starting at line 1 position 1. Like the MNUFLD we defined in the MENUBAR record format last month, the selection field is not actually displayed. Instead, the system either formats one or more fields for you to make a selection or displays radio buttons or check boxes depending on the terminal and controller support available at runtime.
The MLTCHCFLD field-level keyword associated with the MSEL field makes the MENU record a multiple-choice format. This complicates the format somewhat, because we now need to add coding to indicate which of the choices were selected. On single-choice pulldown menus, the selection can be returned to a HLL program through the selection field. When you use a multiple-choice format, the value returned in the selection field is the number of selections that you made. You need to look elsewhere to determine which items were selected.
You describe your menu-item selections with the CHOICE keyword. Three parameters are used with this keyword. First is the choice identification number. This serves a purpose similar to that of the MNUBARCHC identification number, in that it indicates which selection was chosen. The identifier number is followed by the descriptive text for the menu item. You can also define a mnemonic for menu-item text, by placing a greater than (>) character in front of the character that is to be the mnemonic. Unlike menu-bar items, you do want menu-selection text to be descriptive. You don't need to be overly wordy, but you can certainly use more than one word to good effect.
An optional third parameter of the CHOICE keyword is the special value *SPACEB. This is used to indicate that you want a blank row between consecutive CHOICE specifications. Another way to create spacing between menu choices is shown in the MENU format example. The MENU record format contains five choices: 1, 2, 91, 92 and 99. By assigning nonconsecutive identification numbers (e.g., 2 and 91, or 92 and 99) to sequential menu choices, we force a blank line to be inserted between those choices.
It is desirable to use the spacing capabilities of a menu when you have a number of choices and you can sensibly group choices together. You can see many examples of this grouping of choices in PC programs. For example, choices on the File menu typically include Save categories grouped together and Print categories grouped together. This categorization constitutes far better menu design than simply listing choices in alphabetical or random order. Like the presentation of menu-bar choices covered last month, grouping related options is a design area where you should be consistent between menus. Put similar groupings in similar relative positions on different menus.
The MENU format includes an additional keyword, CHCCTL (choice control), that is required for each choice you define on a multiple-choice menu. CHCCTL has two required parameters and an optional parameter set. The required parameters, shown in the example, are the choice identification and the associated control field. The choice identification corresponds with each item defined in a CHOICE keyword. The control field corresponds with a one-byte, numeric, hidden field that is defined in the same record format. Each CHCCTL keyword must be associated with a unique control field.
The control field is used to set the availability of a menu item when the pulldown menu is displayed and to return the status of the menu item to your program when the format is read. 2 shows the values that are used with the control field. The optional parameter set is used to specify a message to be displayed if the user tries to select an unavailable choice. A default message is displayed if you do not specify a different message.
The control field is used to set the availability of a menu item when the pulldown menu is displayed and to return the status of the menu item to your program when the format is read. Figure 2 shows the values that are used with the control field. The optional parameter set is used to specify a message to be displayed if the user tries to select an unavailable choice. A default message is displayed if you do not specify a different message.
In the example program in 3 (page 104), control field CTL92 is set to a value of 2 (unavailable) in the *INZSR subroutine. That means that even before the program displays the menu bar, we have decided that the "Reset all" menu item should not be available. When you make a menu item unavailable, it is still displayed in the menu but cannot be selected. On monochrome displays, the first character of the menu-item text is replaced by an asterisk. On color displays, the unavailable choice is displayed in a different color. This is sometimes referred to as "graying" the selection.
In the example program in Figure 3 (page 104), control field CTL92 is set to a value of 2 (unavailable) in the *INZSR subroutine. That means that even before the program displays the menu bar, we have decided that the "Reset all" menu item should not be available. When you make a menu item unavailable, it is still displayed in the menu but cannot be selected. On monochrome displays, the first character of the menu-item text is replaced by an asterisk. On color displays, the unavailable choice is displayed in a different color. This is sometimes referred to as "graying" the selection.
Simply setting CTL92 to the unavailable value does not make the choice unavailable, though. In order to do that, we have to write to the record format containing the field. In *INZSR, this is done by the WRITE statement to record format MENU. This does not cause the pulldown menu to be displayed. The pulldown menu can only be displayed when the menu-bar record format is displayed. Because we have not yet done that, we can initialize our pulldown menu formats before they are displayed. You can see examples of these initializations in the *INZSR subroutine.
When the multiple-choice pulldown menu is displayed, the program first checks the values in the control fields. For fields which contain a value of 0, the associated menu-item text is displayed as available. If the value in the control field is 1, the associated menu-item text is available and the item is marked as selected. On a low-function terminal, the system indicates a selected item by placing a slash (/) character in the associated selection field. A control-field value of 2, as mentioned above, means the menu item is unavaiable.
When the pulldown menu is displayed on a low-function terminal, the user selects an item by tabbing to it and entering a slash character. High-function terminals enable users to select multiple-choice items with the mouse.
On input, the program examines each of the control fields to determine whether or not the field was selected. Your program simply goes through the list of the control fields and checks for the value zero or one. For example, in processing the MENU format, the first control field checked is CTL99, the field associated with the Exit menu-item selection (note that Exit is included on both the MENU pulldown menu and as a separate menu-bar item). We examine this field first because if it was selected, we can immediately exit the program.
Following through the rest of the processing of MENU, you can see how one or both of the additional items can be selected. If you select the "Enable all" option (CTL91), a value of 1 is placed into both CTL01 and CTL02, so that those menu items will be marked as selected the next time the menu is displayed. CTL91 is marked as unavailable by putting a value of 2 into it. This is used to toggle the "Enable all" option off. Later in the code, the "Reset all" option is toggled on. The pulldown menu itself is updated in the WRITE statement to the MENU format, which sets the selection indicators and available or unavailable items.
In the same section, indicators *IN22 and *IN23 are set. These indicators are used to condition menu-bar items in the MENUBAR record format. The updated menu-bar format is displayed when the EXFMT statement at the beginning of the MNUBAR subroutine, is executed again.
Multiple-choice Menu Design Considerations
I can't recall ever having encountered a multiple-choice pulldown menu, and I had to contrive this example to show how one works. Multiple-choice fields in GDDS will more typically be used in what Windows refers to as a "dialog box," not in a menu. The idea with a menu is that the user can make one choice to cause one action. More properly done, this example would have a menu option that perhaps would read "Specify menu-bar options." Selecting that option would pop up a window in which you would make the multiple-choice selections.
Although the capability exists, it should not be used for user-oriented menus. As you can see from the example, a considerable amount of definition and processing is associated with a multiple-choice field, compared to the single- choice menus we will look at next. Also, you introduce an extra step when you use a multiple-choice menu, because you must examine each of the control fields associated with the menu. In single-choice menus, you can determine the menu item that was selected in the menu-bar format itself.
Single-choice Menu
A single-choice menu is the most commonly used type of pulldown menu. A single- choice menu does not limit you to only one choice displayed on the menu. The phrase "single-choice menu" means that you can make one choice from a list of possible choices. Examples of single-choice menus are the USER and OPTN record formats in 1.
A single-choice menu is the most commonly used type of pulldown menu. A single- choice menu does not limit you to only one choice displayed on the menu. The phrase "single-choice menu" means that you can make one choice from a list of possible choices. Examples of single-choice menus are the USER and OPTN record formats in Figure 1.
These formats are pulldown menus by virtue of the PULLDOWN record-level keyword. Because they are pulldown menus, they also define a two-byte, numeric selection field. The field-level keyword that defines these formats is SNGCHCFLD (single-choice field). Like the MENU format, this is followed by a list of CHOICE keywords that define the menu-item choices. You can optionally define and use CHCCTL keywords on a single-choice field, as shown in the USER menu with control field CTL04. (In the example, it is defined in the file but not used in the program.) Remember that in multiple-choice fields, CHCCTL keywords and control fields are required.
Both the USER and OPTN formats contain other features that control how the menu items are displayed. Except for the CHCACCEL keyword, these features can also be used on the multiple-choice field menu format.
The first feature is conditioning indicator *IN31 used in format USER for choice 3. This works similarly to the conditioning indicators used on the menu- bar format. If the indicator is off when the format is displayed, the selection is not displayed and the user cannot select the option. This is in contrast to setting the availability and unavailability of an item with CHCCTL control- field settings.
The second feature is the use of the program-to-system field in format OPTN to specify the text used for a menu item. In that format, the CHOICE keyword specifies field OPTNTX as the field in the same record format containing the text to be displayed for the menu item. As described last month for menu-bar item text, you can use the program-to-system field when you need to change the text for different national language versions. In the example program, the text is being toggled between two settings.
The choice accelerator keyword (CHCACCEL) can only be used for a single-choice menu item. It is used to associate text describing a function key with a menu option. In the example, it is used on the OPTN menu to associate the text "F11" with the CHOICE field identified by number 1. The use of CHCACCEL does not bind the function key to the choice. It is up to your program to make the association between the function key and the related menu item. You can see this in the program by examining both the processing for the OPTN menu (MNUFLD equal to 3) and the processing for F11 (*INKK is on). In both cases, the program calls the same subroutine to perform the processing.
It is important that you define the function key at the level where you want it used. In this case, CA11 (F11) is defined as a file-level keyword, meaning that it is available when any of the record formats are displayed. If you want to limit it to being valid only when the OPTN format is displayed, define it as a record-level keyword. You should generally define function keys used as accelerators at the file level, since your users will expect to be able to use the accelerator at any point.
You cannot condition the CHCACCEL keyword. However, if you want to control the display of the text, you can use the form of the CHCACCEL keyword in which the text is defined in a program-to-system field. That way, you can dynamically "reassign" the function keys (although all you are actually "assigning" is different text) or indicate unavailability of an accelerator by putting blanks into the program-to-system field. It is still up to your program to identify and process the accelerator key.
Design Considerations for Displaying Menu Items
The example menus show two different techniques you can use to control how menu items are displayed. The first method is to condition the CHOICE keyword field. When conditioned, the text is either displayed or not. The second method is to mark a choice as selected, available or unavailable with the CHCCTL keyword.
You should use the first method, conditioning the CHOICE field, when an option may or may not be available depending on certain external criteria. For example, your application might have a menu option for "Change" that users with a certain level of authorization can use. Users with lower levels of authorization will never be allowed to use the Change function. Rather than simply mark the menu item as unavailable for those users, you can condition the choice so that it is never displayed.
For choices that are toggled available and unavailable during execution of the program, you should use the CHCCTL method. Although at first this seems to be more work, it is the preferred method of indicating to the user the various program options and their current state.
An excellent example of this is readily available in most word processing programs on the Edit menu. Most programs include Cut, Copy and Paste functions. Those options are usually "grayed" (unavailable) until a section of text is marked in the document. Once the text is marked, the options are available on the Edit menu.
The advantage to marking options as unavailable is that a user can learn about the capabilities of the program by browsing through the menus. For example, if a word processing program's Cut, Copy and Paste options were never displayed until a text selection is made, the user might never realize that such functions are available at some point in the program.
No-choice Menus
The final example is the "no-choice" pulldown menu-the EXIT menu format, in this example. This menu is associated with the Exit! menu-bar item. The concept behind this menu-bar item is that the action (exit) will be performed when the user selects the item. There are no additional options to be selected.
To make this work, we use the optional return-field parameter on the associated MNUBARCHC keyword. Because we want Exit! to show up as a menu-bar item, we have to define a MNUBARCHC keyword. We also have to define a valid pulldown menu for the keyword. We meet the requirement for the valid pulldown menu with the EXIT format, which contains nothing other than the record-format identifier and the PULLDOWN keyword. We tell the system that we want control to return to the program when Exit! is selected by including the EXITRF return field in the menu bar record.
When the user selects Exit!, the value 99 is placed into EXITRF. Fields MNUFLD and OPTION in format MENUBAR are set to zero. As shown in 3, the program can test for that special case.
When the user selects Exit!, the value 99 is placed into EXITRF. Fields MNUFLD and OPTION in format MENUBAR are set to zero. As shown in Figure 3, the program can test for that special case.
You generally will not have any no-choice return fields; if you do, they will probably be for functions similar to the exit function shown here. If you find that you are creating a menu bar with more than one no-choice return field, you should consider putting those choices into their own pulldown menu.
You can also decide if you should in fact create a pulldown menu for just one choice, as shown in the OPTN menu. In that menu, we created a single-item menu because we wanted to have room to describe the option that is available. Rather than take up room on the menu bar itself with a long description, the description is pushed down into the pulldown menu. The design consideration then becomes a matter of looking at your pulldown menus. If you are creating more than one single-item menu, you should consider consolidating those into one menu.
Overall Considerations
The new DDS keywords for menu-bar and pulldown definition make it practical to add these special types of record formats to AS/400 applications. But in order to use menus effectively, you may have to look at your applications and design differently.
As it is, we are used to designing applications within the 24 function keys. You need to allocate room at the bottom of the display for the function-key legend and create code to display additional keys (unless you are using UIM, which takes care of this for you). An additional constraint that is particularly sharp for software vendors is that a great many of those keys are already "assigned" by virtue of SAA/CUA standards. My experience with providing software to customers indicates they are harshly critical of nonstandard function-key usage.
It is unfortunate that DDS menu capabilities are being added at such a late date. At this time, it is difficult to say if it is worth adding the menus to existing applications, since an increasing amount of application development will be done with PC front-ends that already provide this support. However, if you will be maintaining a base of code for quite a while, and especially if you are developing new code, you should look very closely at GDDS menus. It is an advantageous situation for both the application developer and for users. The developer can free himself from the constraints of a function-key model of application design. Users can take advantage of an interface that's easier to use and that still incorporates function keys, by means of using the function keys as "accelerators" for menu items.
When you do start to use GDDS menus, give serious consideration to the idea of putting the menu part of the application into its own program. It is far easier to develop and maintain an application in this manner than the usual technique of bundling all of the interface processing with the code that actually "does something."
Craig Pelkie can be reached through Midrange Computing.
References Creating a Graphical Look with DDS (SC41-0104, CD-ROM (V2R2) QBKA7M00; also available as V2R2 PTF SF12632). DDS Reference (SC41-9620, CD-ROM QBKA7402). Goerdt, Dan. "DDS Goes Graphical," MC, July 1993. Guide to Programming Displays (SC41-0011, CD-ROM QBKA7902).
Menu Design & Implementation w/ Graphical DDS: #2
Figure 1 DDS for Menu-bar and Pulldown-menu 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: #2
Figure 2 Values Used for CHCCTL Control Fields
Value Output Input 0 Available Unselected 1 Selected Selected 2 Unavailable
Menu Design & Implementation w/ Graphical DDS: #2
Figure 3 RPG Code for Menu-bar and Pulldown-menu 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