Give your AS/400 applications a new look with graphical DDS.
Brief: In April, IBM released PTFs which make important improvements in the user interface for all AS/400 terminals. More than 20 new keywords have been added to display file DDS to support pull-down menus, radio buttons, check boxes and other traditional PC elements. Other new functions give the programmer better control of data entry and cursor positioning. Best of all, the system, not the programmer, analyzes what terminal is attached and adapts the interface to the hardware capabilities. A member of IBM's development team teaches you how to implement the new functions.
What is a graphical user interface (GUI)? Is it color and icons? Is it support for mouse input? Is it menu bars with pull-down menus? Whatever your answer, you'll probably agree that traditionally the AS/400 has not provided GUI support. Now, all that is changing.
IBM recognizes that although traditional AS/400 hardware and applications cannot support a full-scale GUI, many of the benefits of GUIs can be delivered with a little imagination. What this means in practical terms is that the hardware interface must be transparent to the application programmer. Our goal is to improve the user interface for all AS/400 workstations-from PCs to the newest InfoWindow II to your classic 5251 terminal-without placing an undue burden on the programmer.
The new DDS support we'll discuss in this article is an important step toward that goal. It includes support for traditional GUI functions such as menu bars and pull-downs, and improved displays featuring crisp, solid-line, window borders as well as enhancements to data entry. For example, new keywords give the programmer better control of cursor movement throughout an application. The latest controller technology gives users hotspot capabilities which make it possible to use a mouse to navigate an AS/400 application without any additional programming. Graphical DDS, as you have already seen, uses a lot of terminology that may not be familiar; the "Graphical User Interface Glossary" sidebar defines these terms by both function and appearance.
You may not be aware that the AS/400 has been able to support pull-down menus, mouse input and other GUI functions for more than nine months. IBM introduced the Enhanced User Interface (EUI) with the release of new workstation controller hardware in September 1992. But until April 1993, the only way to access these functions was via User Defined Data Streams (UDDS), which are difficult to code and maintain. In April, IBM released 21 new DDS keywords to make the EUI much more accessible to application programmers. The support is available immediately by ordering PTF SF11703 and its pre- and co-requisites. There's also a new manual available, Creating a Graphical Look with DDS (SC41- 0104-00), which describes the new and changed DDS keywords in detail. (A version for BookManager can be obtained by ordering PTF SF12632.)
A major strength of the DDS implementation is that, unlike UDDS, it doesn't require the application programmer to code for each type of hardware. The graphical functions provided in this PTF package include many, but not all, of the functions available with UDDS. For example, UDDS can support scroll bars, push buttons and selection lists in addition to the functions now available with DDS. By the end of 1993, graphical DDS-coupled with an intelligent workstation (i.e., a PC) and the V2R3 version of RUMBA/400-will deliver an interface that closely resembles the PC GUI standard. Under V2R2, the newest InfoWindow II terminals attached to one of the new workstation controllers (e.g., feature code 6050 or a remote 5494 controller) also deliver a high- quality interface. If your hardware capabilities aren't up to this level, graphical DDS is still worthwhile. Figures 1, 2 and 3 show the same application on three different types of hardware.
Without the new controllers, some aspects of the new graphical interface are limited-4 defines the support available with a variety of controller/terminal configurations. The principal differences are in the presentation-not the function. For example, the radio buttons used to select the output type in 1 become concentric circles in 2. Since 3 illustrates a terminal that doesn't allow mouse support, the selection must be made by entering the number of the choice. However, no function is lost.
Without the new controllers, some aspects of the new graphical interface are limited-Figure 4 defines the support available with a variety of controller/terminal configurations. The principal differences are in the presentation-not the function. For example, the radio buttons used to select the output type in Figure 1 become concentric circles in Figure 2. Since Figure 3 illustrates a terminal that doesn't allow mouse support, the selection must be made by entering the number of the choice. However, no function is lost.
The areas where hardware support affects function are mouse support, hotspots and entry field enhancements such as multi-line entry fields and controlled cursor progression. Both hotspots and the entry field enhancements are a direct function of the controller-without an EUI controller, a nonprogrammable terminal cannot access these functions. Mouse support requires both an EUI controller and a terminal that recognizes the mouse as an input device. Currently, mouse support is only available on InfoWindow II terminals.
One objective of graphical DDS is to give an applications programmer the tools he needs to improve host-based user interfaces. Because of the large installed base of nonprogrammable terminals, it is vital that the new interface give the programmer the ability to develop an application without knowing what terminal it will be run on. From the users' perspective, graphical DDS makes a fundamental change to the selection process used to get to the correct information panel. Once the user has arrived at an application, the new DDS keywords give the programmer much better control of data entry fields and cursor positioning. Finally, the graphical constructs such as radio buttons and check boxes reduce the effort required to make a choice from a group of items.
A Graphical Composition
To give you a flavor for how graphical DDS works, we'll show you how to develop a simple example using a menu bar and selection fields to choose some standard options for processing customer information. 5 illustrates the screen displayed on an InfoWindow II terminal attached to a 6050 EUI controller. The DDS and RPG/400 for this example are listed in6 and 7, respectively.
To give you a flavor for how graphical DDS works, we'll show you how to develop a simple example using a menu bar and selection fields to choose some standard options for processing customer information. Figure 5 illustrates the screen displayed on an InfoWindow II terminal attached to a 6050 EUI controller. The DDS and RPG/400 for this example are listed in Figures 6 and 7, respectively.
All the new and enhanced DDS keywords are listed in 8 along with a brief explanation of their use. For our first example, we'll need two types: menu bar keywords and choice keywords to define the contents of each pull-down menu.
All the new and enhanced DDS keywords are listed in Figure 8 along with a brief explanation of their use. For our first example, we'll need two types: menu bar keywords and choice keywords to define the contents of each pull-down menu.
The DDS source in 6 defines four records: one for the menu bar which contains three choices (Maintenance, Processing and Inquiries) and three to define the choices available for each pull-down menu.
The DDS source in Figure 6 defines four records: one for the menu bar which contains three choices (Maintenance, Processing and Inquiries) and three to define the choices available for each pull-down menu.
Menu Bar Keywords
The MAINMENU record is defined as a menu bar record by specifying the keyword MNUBAR. The MNUBARDSP record-level keyword is defined on the MAINMENU record and is used to display the menu bar when the record is written. As you'll see later, MNUBARDSP gives you the ability to add a menu bar to a data entry panel.
By definition, a menu bar record contains a single field that includes one or more menu bar choice (MNUBARCHC) keywords to define the choices in the menu bar. OS/400 automatically places three blank spaces between the options, wraps the menu bar to multiple lines if necessary, and inserts a default separator line after the menu bar. The menu bar separator (MNUBARSEP) keyword can be used, as shown in the example, to modify the appearance of the separator line. For each menu bar choice, the example defines a number (a unique identifier) and the name of a record to display the pull-down menu when the menu bar choice is selected. The user selects an option from the menu bar by placing the cursor on the option and pressing Enter or the space bar or clicking the left mouse button (depending on the hardware). Depending on the hardware being used, the menu bar cursor appears as a reverse-image bar.
The text for each choice can include a function called a mnemonic that gives the user another way to select the option by keying in a character rather than using the cursor. To activate this function, place a ">" in the choice text. This causes the next character in the choice text to be underlined on the display if the terminal supports single-character underline. In the example, the initial character of each menu bar choice (M, P and I) is designated as a mnemonic. The user can select the choice by pressing the underlined letter-the implementation of this feature is transparent to the application program.
Choice Keywords
Once the user has made a selection from the menu bar, one of the three pull- down records will be displayed. Each record is specified using the PULLDOWN keyword. In our example, each pull-down record displays several options-the user can pick only one at a time. This type of selection is not limited to pull-down menus; it is referred to as a single-choice selection. The DDS defines this condition with the Single-choice Field (SNGCHCFLD) keyword followed by one or more CHOICE keywords. In 6, the CHECK keyword with the keyboard control value of 'ER' has been added to cause an auto record advance when the choice is made. This eliminates the need to press the Enter key. Each individual choice is specified using the CHOICE keyword to define a unique identifier (number) and text to be displayed.
Once the user has made a selection from the menu bar, one of the three pull- down records will be displayed. Each record is specified using the PULLDOWN keyword. In our example, each pull-down record displays several options-the user can pick only one at a time. This type of selection is not limited to pull-down menus; it is referred to as a single-choice selection. The DDS defines this condition with the Single-choice Field (SNGCHCFLD) keyword followed by one or more CHOICE keywords. In Figure 6, the CHECK keyword with the keyboard control value of 'ER' has been added to cause an auto record advance when the choice is made. This eliminates the need to press the Enter key. Each individual choice is specified using the CHOICE keyword to define a unique identifier (number) and text to be displayed.
The field which contains the SNGCHCFLD keyword must be defined as input-capable with data type Y, length of 2, and 0 decimal positions. Depending on the hardware, entry fields for choices will be displayed either as radio buttons or as an input field to the left of the first choice.
If radio buttons are displayed for each choice of the selection field, the user selects a choice by positioning the cursor on a choice and pressing the space bar or the slash (/) or clicking with the left mouse button. If the hardware limits the selection capability to an input field, the user makes a selection by entering the number of the option. Mnemonics are also allowed for the CHOICE keyword on single-choice selection fields. As with the menu bar cursor, the selection cursor is dependent on the hardware; any terminal attached to an EUI controller will display the cursor position by changing the current choice to reverse image.
The HLL Program
As 7 illustrates, the code required to support the menu bar, pull-down and selection fields is minimal. The OS/400 support for graphical DDS handles most of the interaction between the user and the display. The HLL code only requires an EXFMT to write the initial menu bar display and implicitly read the menu bar choice made, and a READ to retrieve the final selection made by the user from the pull-down menu. Our example uses an RPG/400 program to control the menu, but the code could just as easily have been written in CL or COBOL.
As Figure 7 illustrates, the code required to support the menu bar, pull-down and selection fields is minimal. The OS/400 support for graphical DDS handles most of the interaction between the user and the display. The HLL code only requires an EXFMT to write the initial menu bar display and implicitly read the menu bar choice made, and a READ to retrieve the final selection made by the user from the pull-down menu. Our example uses an RPG/400 program to control the menu, but the code could just as easily have been written in CL or COBOL.
The first thing the RPG program does is to issue an EXFMT operation to the menu bar record MAINMENU. Because the MNUBARDSP keyword is within this record and is not conditioned by any indicators, it is in effect when the EXFMT operation takes place. Once the initial menu is displayed, the system handles all interaction between the menu bar and the pull-downs. The program does not regain control until the user selects an option from a pull-down or presses a valid function key or the Enter key. If the user presses Enter while the cursor is located within the menu bar, the system interprets this as a menu bar selection and does not pass control back to the HLL program.
For example, if the user selects Processing from the menu bar, OS/400 will automatically display the PROCESS pull-down record. The user can select any of the four valid choices; depending on the hardware, he makes a selection using the mouse, the spacebar or the unique identifier number. Control then returns to the program, which executes an appropriate subroutine.
The program in 7 examines MNUFLD to determine any further processing. This field, defined in the DDS for the MAINMENU record, contains the number (from the MNUBARCHC keyword) corresponding to the pull-down menu selected. The program must issue a read to the correct pull-down record to update the single- choice selection field defined in the pull-down record.
The program in Figure 7 examines MNUFLD to determine any further processing. This field, defined in the DDS for the MAINMENU record, contains the number (from the MNUBARCHC keyword) corresponding to the pull-down menu selected. The program must issue a read to the correct pull-down record to update the single- choice selection field defined in the pull-down record.
In this instance, MNUFLD would contain the value 2, which indicates that the user selected the Processing menu. The program then reads the pull-down record PROCESS and continues, based on the contents of PRCSEL. For example, if the user selects Statements, PRCSEL will contain a 3. You can use this information to display the first panel for your application.
That's all there is to it! The user gets an easy-to-use, multilevel selection process with minimal extra processing in your program.
Variations on a Theme
Now that you've seen the basic concepts of graphical DDS, we want to show you some of the other features. Because of space constraints, we won't go into detail on all of the new keywords. Instead, we'll try to give you some idea of the power available with these new functions. The code presented in the rest of this article is not intended to be compiled-it will illustrate the concepts we'll discuss.
Take a Shortcut
Many pull-down menus (including our first example) contain only one single- choice selection field. In this case, you can simplify the processing we showed in our example even further. The MNUBARDSP keyword allows a pull-down input parameter for this special case, as illustrated in 9. When the HLL program reads the record containing the MNUBARDSP keyword, the field defined for this parameter will contain one of the following values:
Many pull-down menus (including our first example) contain only one single- choice selection field. In this case, you can simplify the processing we showed in our example even further. The MNUBARDSP keyword allows a pull-down input parameter for this special case, as illustrated in Figure 9. When the HLL program reads the record containing the MNUBARDSP keyword, the field defined for this parameter will contain one of the following values:
o Zero (0)-no selection was made.
o The unique identifier (number) of the choice in the pull-down menu that was selected by the user.
o Negative one (-1)-The pull-down record contains something other than a single-choice selection field. In this case, the pull-down record itself must be read, as shown in the first example.
10 contains all the RPG code to process the DDS in 9. The explicit READ to get input from the pull-down record that was required in 7 has been eliminated.
Figure 10 contains all the RPG code to process the DDS in Figure 9. The explicit READ to get input from the pull-down record that was required in Figure 7 has been eliminated.
Menu Within an Application
Graphical DDS support makes it easy to add menu bar support to a data entry panel. By coding the MNUBARDSP keyword on the display file record for the entry panel, OS/400 will handle all menu bar operations for the application. When the MNUBARDSP keyword is coded this way, as opposed to coding it on the MNUBAR record as shown in the previous example, several parameters are available to manage the menu bar:
o The menu bar record name must be specified as a parameter to the MNUBARDSP keyword.
o The choice field parameter is used to designate a hidden field which will contain the number of the menu bar choice after the user makes a selection.
o An optional parameter, pull-down input, specifies the name of a hidden field which can be used to return the user's selection from the pull-down menu to the HLL program as previously illustrated in 9. This parameter is valid only if the pull-down menu contains a single-choice selection field.
o An optional parameter, pull-down input, specifies the name of a hidden field which can be used to return the user's selection from the pull-down menu to the HLL program as previously illustrated in Figure 9. This parameter is valid only if the pull-down menu contains a single-choice selection field.
An example of the MNUBARDSP coding for an application data entry panel is shown in 11. (The pull-down records have been left out for brevity, but they would be defined as in 6.) If the MNUBARDSP keyword is conditioned by an indicator you can control the menu bar display from within a HLL program.
An example of the MNUBARDSP coding for an application data entry panel is shown in Figure 11. (The pull-down records have been left out for brevity, but they would be defined as in Figure 6.) If the MNUBARDSP keyword is conditioned by an indicator you can control the menu bar display from within a HLL program.
Multiple Choice
The sample application allowed only one choice at each selection level. However, in some situations you will want to allow the user to select more than one item at a time. An example of a pull-down record that allows multiple selections is shown in 12; the MLTCHCFLD keyword on the REPSEL field is used to enable this capability. As with the single-choice selection field used in the earlier examples, the available selections are defined using the CHOICE keyword.
The sample application allowed only one choice at each selection level. However, in some situations you will want to allow the user to select more than one item at a time. An example of a pull-down record that allows multiple selections is shown in Figure 12; the MLTCHCFLD keyword on the REPSEL field is used to enable this capability. As with the single-choice selection field used in the earlier examples, the available selections are defined using the CHOICE keyword.
Depending on the hardware being used, multiple-choice selection fields will have either a check box or an input field to the left of each option. Depending on the hardware, the user can select a choice by placing the cursor on a choice and pressing either the space bar or the left mouse button. If each choice in the selection field has an input field to the left of the choice text, then the user selects a choice by entering a slash (/) or country-specific selection character into the input field associated with that choice.
A maximum of three different characters may be used as selection characters- the slash is always valid as a selection character, but the country-specific selection characters are determined when the display file is created. The default country-specific selection characters for the United States are initially set to slashes. If you need to modify these characters, they are defined in message CPX5A0C. The selection characters are found in the first two positions of the message text.
The CHCCTL keyword is used to return multiple-choice selections to your HLL program. The keyword contains a choice number that identifies each CHCCTL keyword with a selection field choice defined in the same record and a control field parameter which defines a one-byte hidden field. (In the example, the hidden fields are RCTL1 through RCTL4). If the control field contains a zero, the choice was not selected; if it contains a one, the choice was selected.
The CHCCTL keyword also lets you control which choices are available for both single- and multiple-choice selection fields. When the record is displayed, the control value can be zero for available, one for selected or two for unavailable. A third parameter on the CHCCTL keyword is optional and specifies a message to be displayed if the user selects a choice that is unavailable.
13 shows the partial RPG code which processes the screens defined in 12. The program checks MNUCHC to see if Reports was selected from the menu bar. The REPORTS pull-down record is then read to update REPSEL and RCTL1 through RCTL4 in the RPG program. REPSEL contains the total number of choices selected from this multiple-choice field and each RCTLn variable contains either a one or a zero, depending on the selections made by the user.
Figure 13 shows the partial RPG code which processes the screens defined in Figure 12. The program checks MNUCHC to see if Reports was selected from the menu bar. The REPORTS pull-down record is then read to update REPSEL and RCTL1 through RCTL4 in the RPG program. REPSEL contains the total number of choices selected from this multiple-choice field and each RCTLn variable contains either a one or a zero, depending on the selections made by the user.
Take Control
In many cases, you need to control the appearance of a panel based on information such as the user profile, previous selections made by the user or calculations in your program. The new DDS keywords give you a number of ways to provide variations in the information displayed and the options available to the user:
o Choices on the menu bar and on single- and multiple-choice selection fields can be conditioned with indicators. When a menu bar choice is optioned off with an indicator, the subsequent menu bar choices will compress to the left.
o Text for the CHOICE keyword can optionally be defined as a program-to-system field (P-field), which lets you control the text dynamically from your HLL program. For example, if the user can select from a list of valid warehouses, the program could dynamically retrieve the names of the warehouses from a database file.
o If the choices within a selection field are nonconsecutive (for example, their unique identifying numbers are one, two and four), OS/400 inserts a blank line to bring this information to the user's attention. If more than one number is skipped (for example, the choices are numbered one, three and seven), one blank line is inserted for each gap in the numbers.
o The availability of the options on a selection field can also be controlled with the CHCCTL keyword. 14 contains the DDS for a pull-down menu record, PROCESS. For example, suppose the user can only take the Month-End option on the PROCESS pull-down once each time the program is called. The PCTL4 field defined in the DDS and used as a parameter for the CHCCTL keyword controls the availability of this option. The choice available (CHCAVAIL) and choice unavailable (CHCUNAVAIL) keywords make it obvious to the user which choices can be selected by displaying unavailable choices in a different color.
o The availability of the options on a selection field can also be controlled with the CHCCTL keyword. Figure 14 contains the DDS for a pull-down menu record, PROCESS. For example, suppose the user can only take the Month-End option on the PROCESS pull-down once each time the program is called. The PCTL4 field defined in the DDS and used as a parameter for the CHCCTL keyword controls the availability of this option. The choice available (CHCAVAIL) and choice unavailable (CHCUNAVAIL) keywords make it obvious to the user which choices can be selected by displaying unavailable choices in a different color.
The program which displays this record can control the availability of the Month-End option by setting the value of PCTL4. If the value of PCTL4 is set to two, the choice is unavailable; if it is set to zero, the choice is available; if it is set to one, the choice is selected by default but it may be modified by the user.
o In some cases, the application programmer needs to condition the information displayed in a pull-down menu based on user input. However, the controlling HLL program can't modify the pull-down record (via indicators, control fields or program-to-system fields) before the record is displayed, since the display of pull-down menus is normally controlled by OS/400.
By adding a return field as the fourth parameter to the MNUBARCHC keyword for a pull-down menu, OS/400 controls are thwarted and your HLL program can control when the pull-down is displayed. This gives you the opportunity to modify what is displayed.
When using program-to-system fields, optioning indicators or choice control fields, the pull-down records may need to be written prior to the first display of the menu bar in order to set initial values. The simplest way to do this is to write all the display file records containing variable information in an initialization section of your application program (e.g., the RPG *INZSR subroutine).
Navigating the Application
One of the important goals in recent controller enhancements is to let the programmer control how the user can move about between screens and within screens. Most of the new controller capabilities are implemented using the DDS this article discusses-we'll cover all of the capabilities that fall into the general category of cursor movement in this section. However, the EUI controllers also provide a hotspot capability for any terminal that supports a mouse. Hotspots do not require any changes to applications-they are implemented directly in the controller interface. See the sidebar, "EUI Con- troller Hotspots Implementation," for more information.
The Menu Bar Switch (MNUBARSW) and Menu Cancel (MNUCNL) keywords define specialized uses for function keys. Typically, they will be defined at the file level of the DDS. Pressing the key specified in MNUBARSW tells the system to move the cursor between the application and the menu bar record. (A common choice for the MNUBARSW is F10, since this conforms to PC standards.)
The MNUCNL keyword defines a function key that performs the Cancel function and ends the current selection process. For example, if a pull-down menu is displayed and the user presses the Cancel key, the pull-down is removed and the cursor is placed in the menu bar choice associated with that pull-down record. If the cursor is in the menu bar when the Cancel key is pressed, the cursor is positioned on the application screen. In this case, if the user previously exited the application using the MNUBARSW function key, the cursor returns to its prior position in the application; otherwise, the cursor is positioned at the first input field below the menu bar. Processing takes place without returning to the HLL program with one exception-if the cursor is on the application screen and the user presses the Cancel key, control returns to the application.
Enhanced Entry Fields
The new EUI controllers give the applications programmer more control over data entry fields. This takes advantage of the ability to detect keystrokes without waiting for the user to press Enter or a function key (like a PC). The DDS which supports the enhanced data entry functions discussed here is ignored on a display which is attached to one of the older controllers.
Several new keywords make it easier for the user to move around a data entry panel containing numerous fields: Field Cursor Progression (FLDCSRPRG) allows the programmer to control which field the cursor moves to when exiting a field. The name of the next field in the progression is specified as a parameter. The Subfile Cursor Progression (SFLCSRPRG) keyword provides similar capabilities for a subfile display. It has no parameters but directs the cursor to go to the same field in the next subfile record. These new keywords make it simple to allow data entry in columns by moving the cursor top to bottom rather than left to right.
The Edit Mask (EDTMSK) keyword makes it much easier for the user to enter information into numeric fields. It works with both edit words (EDTWRD) and edit codes (EDTCDE) to protect the editing characters from data entry. This allows the programmer to display the fields in easy-to-read, edited format. The cursor will automatically skip over any position protected by an ampersand, as shown in the two examples in 15. When the user keys a social security number in the SSN field, the cursor automatically skips over the dashes. When he keys a date, the cursor skips over the slashes inserted by the edit code.
The Edit Mask (EDTMSK) keyword makes it much easier for the user to enter information into numeric fields. It works with both edit words (EDTWRD) and edit codes (EDTCDE) to protect the editing characters from data entry. This allows the programmer to display the fields in easy-to-read, edited format. The cursor will automatically skip over any position protected by an ampersand, as shown in the two examples in Figure 15. When the user keys a social security number in the SSN field, the cursor automatically skips over the dashes. When he keys a date, the cursor skips over the slashes inserted by the edit code.
The Entry Field Attribute (ENTFLDATR) keyword (see 15) changes the color and display attributes when the cursor enters a field. When the cursor exits the field, the color and attributes are restored to their original values.
The Entry Field Attribute (ENTFLDATR) keyword (see Figure 15) changes the color and display attributes when the cursor enters a field. When the cursor exits the field, the color and attributes are restored to their original values.
The Continued Entry Field (CNTFLD) keyword can be used to split a large field into several lines. Although there have always been tricks to accomplish this effect, CNTFLD includes a parameter that allows the programmer to specify the length of the lines and the system takes care of displaying the data (it does not have to be evenly divisible by the number of characters specified). The field is treated as a single field, complete with wrap, insert and delete capabilities.
A Graphical Perspective on the AS/400
In this article, we've been able to provide only an overview of the new DDS capabilities, but we hope you'll agree they deliver an exciting new way to program AS/400 applications. The development team worked hard to give you the ability to come closer to the look and feel of a PC on your current installed base of nonprogrammable terminals. We took advantage of controller enhancements that extend the 5250 data stream to give you as much function as possible in this PTF package.
A primary goal was to make sure that the DDS would not require any specifics about the hardware, making applications as portable as possible. At the same time, we wanted to give you as much access as possible to the capabilities of the new controllers and advanced displays such as PCs and InfoWindow II workstations. The new DDS functions released in this PTF package represent an important step toward that goal.
Dan Goerdt is a senior associate programmer for IBM in Rochester, Minnesota. During his five years with IBM, he has worked exclusively on the Workstation Function Manager component of OS/400. He helped develop the DDS support for windows released as a PTF for V2R1 and was part of the development team for the EUI DDS support discussed in this article. He may be contacted through Midrange Computing.
Dan wishes to thank Paul McNie, John W. O'Sullivan and Mohammad Ghaith of NewGeneration Software, Inc. (NGS) for their help with this article. NGS was a beta site for the graphical DDS PTF and developed the application examples used in the text. NGS is an IBM business partner and member of IBM's ASsociation/400 program specializing in AS/400 accounting, database report writing and data center automation. NGS is located in Sacramento, California (916-920-2200).
Graphical User Interface Glossary
accelerator key: A function key that the user can press to activate one of the selections from a pull-down menu without moving the cursor to select the function or pressing the Enter key.
bar selection cursor: A highlighted bar that moves to each choice in a menu bar or a selection field.
check box: A graphical way of showing a user's selections, when more than one selection can be made. It is shown as an empty box when the choice is not selected and as a box containing an X or a checkmark when the choice is selected.
continued entry: A field that appears as multiple lines of input on the screen field but is returned to the application as a single field.
Enhanced User Interface (EUI): The underlying hardware support which makes it possible for the AS/400 to deliver new user interface functions.
graphical user interface (GUI): A method of presenting information to the user which does not rely primarily on a text-based presentation.
hotspot: Hotspot capabilities make it possible for a user to use mouse input to emulate a variety of keystrokes. The area of the screen which is sensitive to this type of mouse input is referred to as a hotspot.
menu bar: A horizontal list of choices that allows the user to select a menu of additional choices to be displayed.
mnemonic: A single character used to make a selection. Implemented properly, mnemonics live up to their conventional definition by being easy to remember (e.g., E=Edit).
mouse: An electronic pointing device associated with GUIs.
pull-down menu: A list of additional choices that drops down from a menu bar when one of the menu bar items is selected.
push button: A graphic that the user can select with the mouse to activate a function.
radio button: A graphical way of showing a user's selections, when the choices are mutually exclusive. It is shown as concentric circles or a raised box within another box.
scroll bar: A horizontal or vertical bar that is used to move the cursor within a document or collection of data. The user slides a positioning block along the scroll bar to place the cursor relative to the entire set of information available.
selection field: The input field when selecting from a group of choices.
selection list: A dynamic list of choices that the user can choose from when making a selection.
window: A portion of the screen overlaying the main panel. Windows are typically surrounded by a border and may be a different color from the surrounding information.
SIDEBAR: EUI Controller Hotspots Implementation
Hotspots allow a user with a terminal that supports mouse input to use the mouse to emulate function keys, roll keys and the Enter key. The AS/400 implementation is supported entirely by the EUI controllers-no additional applications programming is required. Hotspots are activated by moving the mouse cursor to designated sections of the screen and clicking the left mouse button. Three types of input are recognized as hotspots:
o The Enter key can be simulated by double-clicking with the left mouse button.
o Function keys are activated when the panel displayed contains a specific string: Fx= or PFx= (where x is a function key number from 1 to 24). When the mouse button is clicked within a string that contains the designated text, the controller interprets the input as the corresponding function key. If you define text for multiple function keys, you should be aware of the string search algorithm used for hotspots: a new string can begin at the left edge of the screen; any time the text contains two or more blank (or null) characters; or any time the text contains an attribute byte.
o Subfile rolling can be activated with hotspots by clicking the mouse over the plus (+) or minus (-) sign. Like the function key hotspots, this feature depends on string searches for specific characters-the plus and minus signs. Typically, the plus sign will be provided by the Subfile End (SFLEND) keyword and the minus sign will be supplied as a constant by the applications programmer.
If you prefer to use More... and Bottom to indicate whether there are additional records in the subfile, you'll need to modify messages CPX6AB1 and CPX6AB2 in QCPFMSG in QSYS and recompile your display file. CPX6AB2 should include both a plus and a minus character so that the user can select rolling in either direction. CPX6AB1 should include only a minus sign. These values allow the mouse to be used for rolling up and down.
DDS Goes Graphical
Figure 1 A PC Running V2R3 RUMBA/400
*** Unable to reproduce graphic ***
DDS Goes Graphical
Figure 2 InfoWindow II Terminal (EUI Controller)
Maintenance Processing Reports ---------------------------------------------- Select Output Type: Display Printer File Select Printer Options: Page Length Page Width Form Name Page Overflow Line Page Headings Page Footers Enter Date Range: 0/00/00 0/00/00 F3=Exit F10=Actions F12=Cancel 01-02 SA MW KS IM II S1 S1034786 KB
DDS Goes Graphical
Figure 3 5251 Terminal (Non-EUI Controller)
Maintenance Processing Reports ------------------------------------------------------------- Select Output Type: _ 1. Display 2. Printer 3. File Select Printer Options: _ Page Length _ Page Width _ Form Name _ Page Overflow Line _ Page Headings _ Page Footers Enter Date Range: 0/00/00 0/00/00 F3=Exit F10=Actions F12=Cancel 01-02 SA MW KS IM II S1 S1034786 KB
DDS Goes Graphical
Figure 4 Hardware Support for Graphical Functions
The DDS discussed in this article is valid for any AS/400 terminal/controller configuration. However, the graphical representation of items such as radio buttons differs significantly depending on the hardware being used. To get a graphical effect approaching the GUI standard, you will need an InfoWindow II terminal and one of the EUI controllers. Later this year, V2R3 of RUMBA/400 will extend the GUI environment even further by supporting the EUI DDS enhancements. There are two classes of controllers: 1. EUI controllers provide full support for all the functions discussed in this article. The following EUI controllers are currently available from IBM: the remote 5494 controller; twinax controller feature codes 6050, 2661, 9146 and 9148; and ASCII controller feature codes 6041, 6141, 2637, 9145 and 9147. The table illustrates the level of support available with different terminals attached to an EUI controller: Hardware Support for Terminals Attached to an EUI Controller *** Unable to reproduce chart *** 2. All other controllers provide limited support for the graphical aspects of the new interface. However all the DDS discussed in this article, with the exception of the enhanced entry field capabilities, is fully supported on older AS/400 controller technology. Graphical elements such as pull-down menus are displayed using text characters and selection field input is provided with character fields rather than radio buttons or check boxes.
DDS Goes Graphical
Figure 5 Sample Application Display
Maintenance Processing Inquiries ---------------.------------------------.-------------------------------------- : Invoices : : Cash Application : : Statements : : Month-End : :........................: 03-18 SA MW KS IM II S1 S1034786 KB
DDS Goes Graphical
Figure 6 DDS for Menu Bar Example (GUI001DF)
* * CRTDSPF FILE(XXX/GUI001DS) + * SRCFILE(XXX/QDDSSRC) * A CF03(03) * A R MAINMENU MNUBAR A MNUBARDSP A MNUFLD 2Y 0B 1 2 A MNUBARCHC(1 MAINT '>Maintenance') A MNUBARCHC(2 PROCESS '>Processing') A MNUBARCHC(3 INQUIRE '>Inquiries') A MNUBARSEP((*COLOR RED)) * A R MAINT PULLDOWN A MNTSEL 2Y 0B 1 1SNGCHCFLD A CHECK(ER) A CHOICE(1 '>Customer') A CHOICE(2 '>Salesperson') * A R PROCESS PULLDOWN A PRCSEL 2Y 0B 1 1SNGCHCFLD A CHECK(ER) A CHOICE(1 '>Invoices') A CHOICE(2 '>Cash Applicatio n') A CHOICE(3 '>Statements') A CHOICE(4 '>Month-End') * A R INQUIRE PULLDOWN A INQSEL 2Y 0B 1 1SNGCHCFLD A CHECK(ER) A CHOICE(1 'Customer >Balanc es') A CHOICE(2 '>Invoices') A CHOICE(3 '>Checks') * * A R CHOICES WINDOW(*DFT 9 15) A 2 2'Choice Fields' A DSPATR(HI) A 4 4'MNUFLD:' A MNUFLD 2Y 0O 4 12EDTCDE(3) A 6 4'MNTSEL:' A MNTSEL 2Y 0O 6 12EDTCDE(3) A 7 4'PRCSEL:' A PRCSEL 2Y 0O 7 12EDTCDE(3) A 8 4'INQSEL:' A INQSEL 2Y 0O 8 12EDTCDE(3) *
DDS Goes Graphical
Figure 7 RPG/400 for Menu Bar Example (GUI001RG)
* * CRTRPGPGM PGM(XXX/GUI001RG) SRCFILE(XXX/QRPGSRC) * FGUI001DFCF E WORKSTN * * * * C EXFMTMAINMENU Read menu bar C *IN03 DOWEQ'0' Until F3 C MNUFLD IFEQ 1 Maintenance C READ MAINT 99 C MNTSEL CASEQ1 SUBR C MNTSEL CASEQ2 SUBR C END C END C MNUFLD IFEQ 2 Processing C READ PROCESS 99 C PRCSEL CASEQ1 SUBR C PRCSEL CASEQ2 SUBR C PRCSEL CASEQ3 SUBR C PRCSEL CASEQ4 SUBR C END C END C MNUFLD IFEQ 3 Inquiry C READ INQUIRE 99 C INQSEL CASEQ1 SUBR C INQSEL CASEQ2 SUBR C INQSEL CASEQ3 SUBR C END C END * * Read Menu Bar * C EXFMTMAINMENU C END * C MOVE '1' *INLR C RETRN * * Dummy Subroutine to Process Selections * C SUBR BEGSR C ENDSR
DDS Goes Graphical
Figure 8 New and Enhanced DDS Keywords
DDS Keyword : Level : Description : Purpose CHCACCEL : Field : Choice Accelerator Text : Specifies the text for the accelerator key on a single-choice selection field-the text is automatically positioned to the right of the choice description text. An accelerator key allows the user to press a function key to make a selection from a single- choice selection field within a pull-down. CHCCTL : Field : Choice Control : Controls whether a particular choice may be selected by the user. CHCSLT : Field : Choice Color when Selected : The color or display attribute used when displaying a selected choice in a menu bar. CHCAVAIL : Field : Choice Attributes when Available : The color or display attributes used when displaying available choices for a single- or multiple- choice selection field. CHCUNAVAIL : Field : Choice Attributes when Unavailable : The color or display attributes used when displaying unavailable choices for a single- or multiple- choice selection field. CHOICE : Field : Selection Field Choice : Defines each choice for a selection field. CNTFLD : Field : Continued Entry Field : Defines an input field for display as multiple lines. EDTMSK : Field : Edit Mask : For a numeric input field, defines the positions to protect- typically edit characters. The cursor will skip over these characters during data entry. Must be used with the EDTCDE or EDTWRD keyword. ENTFLDATR : Field or Record : Entry Field Attributes : Defines the display attributes and color for a field when the cursor is positioned within the field. FLDCSRPRG : Field : Field Cursor Progression : Specifies the field the cursor should move to when it exits the current field. HLPARA* : Field : Help Area : The HLPARA keyword has been enhanced to allow the coordinates of the help area to be dynamic based on the position and size of the field. HLPID : Field : Help Identifier : Links help text to a constant field. MLTCHCFLD : Field : Multiple-choice Selection Field : Specifies that multiple selections are allowed from the associated group of CHOICE fields. MNUBAR : Record : Menu Bar : Defines a record that displays a horizontal list of choices for pull-down menus. MNUBARCHC : Field : Menu Bar Choice : Specifies one item in the list of choices for a menu bar. MNUBARDSP : Record : Menu Bar Display : Controls display of the menu bar. MNUBARSEP : Record : Menu Bar Separator : Overrides the default attributes of the line separating the menu bar from the rest of the panel. MNUBARSW : File or Record : Menu Bar Switch : Assigns a function key used to move back and forth between the menu bar and the application. MNUCNL : File or Record : Menu Cancel : Assigns a function key used to cancel the current menu(either a pull-down or a menu bar). PULLDOWN : Record : Pull-down Menu : Defines a record as a pull-down menu associated with a menu bar. SFLCSRPRG : Field : Subfile Cursor Progression : For a subfile record, moves the cursor to the same field in the next record of the subfile. SNGCHCFLD : Field : Single-choice Selection Field : Similar to MLTCHCFLD. Specifies that only one selection is allowed from the associated group of CHOICE fields. WINDOW* : Record : Window : The WINDOW keyword has been enhanced to allow the programmer to control whether or not messages should appear within the window and to allow a window to be positioned based on the cursor location. *=enhanced
DDS Goes Graphical
Figure 9 Using a Pull-down Input Parameter (Partial DDS)
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 * A R MAINMENU MNUBAR A MNUBARDSP(&PULINP) A PULINP 2S 0H A MNUFLD 2Y 0B 1 2 A MNUBARCHC(1 MAINT '>Maintenance') A MNUBARSEP((*COLOR RED)) * ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 10 Partial RPG/400 to Process the Pull-down Input
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 C EXFMTMAINMENU Read menu bar C MNUFLD IFEQ 1 Maintenance C PULINP CASEQ1 SUBR C PULINP CASEQ2 SUBR C ENDCS C ENDIF ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 11 Partial DDS for a Menu Bar Within an Application
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 A CF03(03) * A R MAINMENU MNUBAR A MNUFLD 2Y 0B 1 2 A MNUBARCHC(1 MAINT '>Maintenance') A MNUBARCHC(2 PROCESS '>Processing') A MNUBARCHC(3 INQUIRE '>Inquiries') A R APPSCR MNUBARDSP(MAINMENU &MNUCHC &PULINP) * * Fields for the application panel go here * A MNUCHC 2Y 0H A PULINP 2S 0H ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 12 Partial DDS for a Multiple-choice Field
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 A CF03(03) A MNUBARSW(CA10) A MNUCNL(CA12 12) A PRINT * * A R MAINMENU MNUBAR A MNUBARDSP A MNUFLD 2Y 0B 1 2 A MNUBARCHC(1 MAINT '>Maintenance') A MNUBARCHC(2 PROCESS '>Processing') A MNUBARCHC(3 INQUIRE '>Inquiries') A MNUBARCHC(4 REPORTS '>Reports') A R REPORTS PULLDOWN A REPSEL 2Y 0B 2 1MLTCHCFLD A CHOICE(1 '>Aged Receivables') A CHCCTL(1 &RCTL1) A CHOICE(2 '>Cash Receipts') A CHCCTL(2 &RCTL2) A CHOICE(3 '>Sales by Customer') A CHCCTL(3 &RCTL3) A CHOICE(4 '>Outstanding Invoices') A CHCCTL(4 &RCTL4) A RCTL1 1Y 0H A RCTL2 1Y 0H A RCTL3 1Y 0H A RCTL4 1Y 0H ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 13 Partial RPG for a Multiple-choice Field
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 C MNUCHC IFEQ 4 Reports? C READ REPORTS 99 Get multi-choice C REPSEL IFGT *ZEROS Got choices C RCTL1 CASEQ1 SUBR1 Aged Receivables C END C RCTL2 CASEQ1 SUBR2 Cash Receipts C END C RCTL3 CASEQ1 SUBR3 Sales by Customer C END C RCTL4 CASEQ1 SUBR4 Outstanding Invs. C END C END C END ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 14 Controlling a Choice Dynamically (Partial DDS)
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 A R PROCESS PULLDOWN A PRCSEL 2Y 0B 1 1SNGCHCFLD A CHECK(ER) A CHOICE(1 '>Invoices') A CHOICE(2 '>Cash Application') A CHOICE(3 '>Statements') A CHOICE(4 '>Month-End') A CHCCTL(4 &PCTL4) A CHCAVAIL((*COLOR GRN)) A CHCUNAVAIL((*COLOR BLU)) A PCTL4 1Y 0H ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DDS Goes Graphical
Figure 15 Entry Field Enhancements (Partial DDS)
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 A 3 32'Soc Sec No:' A DSPATR(HI) A SSN 9 0B 3 45FLDCSRPRG(HIRDAT) A ENTFLDATR((*COLOR TRQ) (*DSPATR RI)) A EDTWRD('0 - - ') A EDTMSK(' & & ') A 4 32'Hire Date:' A DSPATR(HI) A HIRDAT 6 0B 4 45FLDCSRPRG(SLSNAM) A EDTCDE(Y) A EDTMSK(' & & ') A ENTFLDATR((*COLOR TRQ) (*DSPATR RI)) ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
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