Display file DDS supports powerful ways to provide contextual help text to your users…but with limitations. Learn how to get around those limitations.

IBM supports a wide range of help-related keywords in DDS source—too many for me to cover here. If you have a free weekend (or three), you can browse through the latest Programming DDS for Display Files manual starting around page 123. Yes, I know the world is changing and in two (or five or ten) years, there will be no more display files. But then again, I've heard that since the mid-’90s, so forgive me if I'm not quite ready to roll up the 5250 just yet. And as long as we have green-screens, we should have good help text for them.

Contextual Help in the 5250 World

The 5250 interface can be a little constricting, given its 24x80 (or even 27x132) size limit. Programmers tend to create very dense screens, with codes instead of actual words, and even when words are employed, they're often abbreviated. All of this compacting leads to screens that are very powerful for seasoned users but can be daunting for novices. That's what help text is supposed to alleviate. However, the very denseness of the screens leads to a problem: If you provide users with all the possible help for a screen, it will take them too long to read through it, and that defeats the purpose of the help text in the first place.

Over the years, we've settled on the idea of contextual help. Typically, the Help key would provide help that is specific to the field where the cursor is located when the user hits the Help key. Often, a more general help is available as well. This may be invoked when the user hits the Help key but isn't on a specific field. This was the most common technique in the early days of DDS-based help text.

The Simple Method: HLPARA and HLPRCD

In addition to the primary enabling keyword HELP (and it's close relative ALTHELP), only the two keywords HLPARA and HLPRCD are required for traditional help. When you define your display, you are able to specify the help for rectangular sections of the display. You can do this either by specifically using row and column (top-left and bottom-right corners of the rectangle) or by specifying a field name. Rectangles can overlap and also can be conditioned; this provides a lot of flexibility. One use of this feature is to specify a default help for the display. Simply create a help definition that encompasses the entire screen (from position 1,1 to position 24,80) and place this at the end of the list; this help definition will be used any time that the user presses the Help key and the cursor isn't in any of the other definitions.

Each help definition also needs a keyword identifying the help text to display. The two basic concepts are help records (HLPRCD) and panel groups (HLPPNLGRP). Today, we'll assume you're using the HLPRCD keyword, which allows you to specify a record either in the display file or in a completely separate file. The latter is nice because you can change the help even when people are in the program (as long as they're not currently using the help!).

Which Definition Type? Row and Column or Field Name?

If everything else were equal, from a maintenance standpoint I'd prefer to use the field name technique because you don't have to change your help definitions when a field moves on the screen. The system takes care of the details for you and automatically brings up the correct help text.

The row and column technique is required for subfiles. For whatever reason, DDS doesn't support using the field name technique with subfiles. You can only specify the HLPARA in the subfile control record, and you can only specify field names from the record where the HLPARA is defined, so effectively you can only specify field names in the subfile control record. Instead, you're limited to specifying the help text definitions using row and column rectangles. Figure 1 shows an example.

Figure 1: RDi will show you your help rectangles.

In Figure 1, I defined rectangles around the columns in the subfile. Each column has its own rectangle, defined using the HLPARA keyword. Then, I have a default rectangle that covers the entire record. The source looks like this:

     A         H                           HLPARA(7 2 21 4)

     A                                     HLPRCD(HELP_OPT)

     A         H                           HLPARA(7 7 21 10)

     A                                     HLPRCD(HELP_ID)

     A         H                           HLPARA(7 14 21 43)

     A                                     HLPRCD(HELP_DESC)

     A         H                           HLPARA(1 1 24 80)

     A                                     HLPRCD(HELP_RCD)

Each rectangle has an associated help record which has been defined in the display file using the HLPRCD keyword. As noted earlier, I could also have pointed to an external file to allow separation of the display file and the help file. Overall, this technique works very well when you have subfiles with a single line, with the primary negative being that whenever you change the subfile, you have to change the rectangles in the DDS. However, it gets much harder with a folded subfile.

Figure 2: Folded subfile records don't lend themselves as well to the rectangle approach.

As you can see here, it would be impossible to define columnar rectangles; the column for zone overlaps the column for station, and the column containing city and state overlaps the column for address. The only answer in this case is to specify individual rectangles for every station field in every subfile line—in this case, eight different rectangles for station alone—and then do the same for every other field. And as if that weren't already overly complicated, consider this: What if the subfile can be folded with, say, F11? Now the rectangles are different! You can do it, although it requires a combination of tedious definition in the DDS and unusual programming. It really starts to become a maintenance nightmare.

On the other hand, you might also have noticed that my rectangles in Figure 1 include the headings for the subfile columns. That's a downside to the field name technique: Constants don't have a name, so there's no way to specify the field name. IBM provided a workaround; you can specify a special value called HLPID and that can be used, but remember there's a much larger issue: Fields in subfiles can't be specified by name at all! So unfortunately we're stuck with rectangles.

Or are we? In subsequent articles, I'm going to address two different enhancements to the help system. One has to do with the actual text itself and involves moving from DDS-based help records to far more flexible UIM panel groups. The second involves a one-time piece of programming that allows you to have much better control over your help area definition and allows you to use field names even on subfiles.

So start here, familiarize yourself with the basics of HLPARA and HLPRCD, and stay tuned for more good things in the future!

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale