Documentation may not be the No. 1 concern on your project list, but perhaps it should be. Good documentation strategies can make or break your MIS staff, not to mention your users. Well-done, user-friendly user documentation can save you from having to answer the same questions all the time. It can also make it easier to train new users, which can be a big timesaver if your company has a large turnover. With that in mind, I’ll go over some old documentation ideas as well as some new ideas you might not have thought of before.

User Documentation Ideas

Effective user strategies can be as simple as using traditional green-screen help screens or as complex as using a Windows help file, created with the help compiler included with any of the Microsoft development platforms, or a product such as Delphi or an HTML document that is displayed when the Help key is pressed. No matter which strategy you choose, the most important thing is consistency. The more consistent the documentation scheme, the easier it is for your users to navigate through the applications. I’ll start with the basics and go over some green-screen help.

While the DDS help (HLPxxx...) keywords will get the job done, I’ll use another technique in my example. Figure 1 contains the source for the RPG program HELP. The source for the display file HELPWINDS can be retrieved from the MC Web site at www.midrangecomputing. com/mc. This source file is used to display the green-screen version of your documentation.

The RPG program HELP has four parameters: the program screen name, the horizontal and vertical cursor positions, and a return code to tell your application program whether any documentation was found for the selected screen. You will use the first three parameters to access help information stored in the physical file HELPFILE (also available for download from the MC Web site). The HELPFILE physical file contains a screen name field that defines the screen and/or application, start and end row and column positions, a line number field, a text field that contains the actual help text, and a field used to link to the external application (HLWBPG). The last field is relevant only on records where the line number field is 0. Your application must provide the cursor positions, using the information data structure (INFDS) for the display file. You can also retrieve the cursor position using the DDS keyword RTNCSRLOC (Return Cursor Location), which retrieves the position of the cursor and converts it to variables. When your program detects that the

Help key has been pressed, it calls the HELP program to display the help window. If you don’t pass the cursor positions or you don’t have any text defined for the cursor position passed, the HELP program will display the “overview” text, which, accordingly, would be defined with no starting and ending cursor position range in the HELPFILE file. After creating the HELPFILE physical file, the HELPWINDS display file, and the HELP RPG program, enter some help text into the HELPFILE file. Then simply modify your application program to call the HELP program, using the required parameters, when the Help key is pressed. My example also gives you a first basis for the second example: using an HTML document for your help text.

Modernize Help with HTML

Start by recreating the text of the help file created in the previous step by using either a text editor that can save documents as HTML files or an HTML editor of your choice. After you’ve written the help text, make sure you save the document as an HTML file. Place your saved document somewhere on your network so that it is accessible by all of your AS/400 client workstations—for example, on your LAN server or in the AS/400 Integrated File System (AS/400 IFS).

Now, using a text editor, create a PC batch file that provides a link to the location of your Internet browser. To do this, add the following line to your DOS batch file:

C:Progra~1Intern~1IEXPLORE.EXE %1

This example shows the path to Internet Explorer on a Microsoft Windows NT workstation. If you use Internet Explorer under Windows 9x or Netscape Navigator or another browser, make sure the path name reflects the location of your own browser. The %1 allows you to pass the Web page location as a parameter.

Now save the batch file under the name INET.BAT to the root directory of your PC
(i.e., C:). Next, you’ll need to update the HELPFILE file on your AS/400 by adding the link to the HTML document associated with the cursor location to the HLWBPG field. Be sure to use a fully qualified link to your Web browser and the document (for example, C:INET.BAT http://myserver/helpdoc1.html or C:INTET. BAT C:hlpdochelpdoc1.html).

Now when your application calls the HELP program, it will first attempt to display the HTML version of your help file using the DSPWEBPGE program, which is downloadable from the MC Web site. DSPWEBPGE first retrieves the IP address of the current job and then uses the Run Remote Command (RUNRMTCMD) command to open your Web browser and display the selected document. Make sure your PC is set up to accept incoming remote commands. The CWBRXD.EXE incoming remote command daemon program must be running on the PC for this technique to work. (See “Building the Bridge Between RPG IV and PC Programs” in the July 1998 issue of MC for more information on using this technique.) The easiest way to get the daemon running is to open up the PC’s Control Panel utility, select the Client Access icon, click on the Incoming Remote Commands tab, and then check the Automatically Start Incoming Remote Commands box. This also means that you must be using IBM’s Client Access product on the PC. If you are not a user of Client Access, you could modify this technique a bit by using FTP instead of RUNRMTCMD. For this to work, you’ll need an FTP server running on each PC that will be displaying your help files. The FTP server will accept the incoming remote command and execute it for your application. (For more information on using an FTP server, check out “A Better Way to Distribute Your AS/400 Software Changes” in the April 2000 issue of MC.) If the RUNRMTCMD command or the FTP command you replaced it with fails, DSPWEBPGE will display the DISPHELP window with the original help text that you created. The nice thing about the HTML format is that

you can create links between your HTML help documents to move between related help files without returning to the AS/400.

Using HTML as your help documentation allows for documentation that is more dynamic and attention-grabbing. For example, you can include pictures, screen shots, and flowcharts within the documentation to fully replace, in effect, written documentation. Also, when you use this technique, the HELP program will be fully compatible with both green-screen “dumb” terminals and Windows clients. Although my example is executed using an HTML Web page, you could use the program to launch any Windows program simply by replacing the HLWBPG field with the full path to the application, including the document to be loaded. This means that, using an inexpensive Web cam and video recording software, you could record the instructions for a given task—month-end closing, for example—in a Windows video file (e.g., AVI or Real Player) and launch the Windows media player and open the video file when the help key is pressed. Now that you’ve got the most user-friendly documentation possible, I’ll examine technical documentation.

Technical Documentation Strategies

Effective technical documentation can be as simple as using a good modification marking standard and sticking to it. You know that, when you are really in the crunch and struggling to meet your project deadlines, the last thing you’re thinking of is making sure that you mark your program code modifications properly. Time constraints, however, are no excuse for not marking your modifications. This simple task can save you an enormous amount of time when you are performing any type of code maintenance.

As you can see in the Access database in Figure 2 (which you can download from the MC Web site), marking changes isn’t difficult. This database gives you a tool for tracking modifications made to programs and/or files. The database allows you to generate reports by program name, source type, application ID, or programmer name. The menu allows you to enter object information and modification information as well as generate reports based on the data you’ve entered.

There are also many software utilities available to assist with technical documentation. Most of those packages will give you the ability to search for field, file, or program and other object usage throughout your system in addition to many other powerful documentation tools. For a complete list of documentation software and vendors, be sure to visit the Midrange Computing Online Yellow Pages at www.midrangecomputing.com/yellowpages.

Another important part of technical documentation is functionality flowcharting. Functionality flowcharting allows you to show graphically how application A interacts with application B. Think of it as the technical road map to your software. This can be especially important if you are building applications to interface with multiple systems. Unless you have a photographic memory, you can easily forget what causes data from application A to get to application B and when it happens. Besides, people other than yourself are likely to be working with your code and systems, and they will need a way to understand, at a glance, the big picture of the project. To do this, you can create a simple flowchart, by using Microsoft Word or purchasing a flowcharting package such as Visio. As with user documentation, the key to success is consistency. If your program documentation technique is consistent throughout your system—that is, all programs relating to one modification are marked, using the same modification identifier—you can find all of the programs related to a certain modification simply by using PDM’s search feature (option 25 from the PDM Work with Objects screen) on your source physical file (QRPGSRC).

Sticking to It

Whether you work in a small MIS department or a large one, setting documentation standards is only half the battle. Sticking to them and making sure that everyone else does,

too, is the other half. Using some of the techniques I’ve gone over here can make creating documentation less of a chore, while making it easier to use as well.

REFERENCES AND RELATED MATERIALS

• BCD International Web site: www.bcdsoftware.com
• DDS Reference (SC41-5712-02, CD-ROM QB3AUII02)
• Hawkeye Information Systems Web site: www.hawkinfo.com
• RPG/400 Reference (SC09-1817-00, CD-ROM QBKAQV00)

* ******************************************************************

* To Compile: CRTBNDRPG PGM(xxx/HELP) SRCFILE(xxx/QRPGLESRC) +

* SRCMBR(HELP)

*

* ******************************************************************

FHELPWINDS CF E WORKSTN SFILE(HELPTEXT:RRN)

FHELPFILE IF E K DISK

D EOFHelp S Like(*IN01)

D CsrRw S 3 0

D CsrCl S 3 0

D RTCode S 2

D Text S 70

D RRN S 5 0

C *ENTRY PList

C Parm Screen 10

C Parm CsrRow 15 5

C Parm CsrCol 15 5

C Parm RetCde 2

C*

C Eval CsrRw=CsrRow

C Eval CsrCl=CsrCol

C HelpKey KList

C KFld Screen

C KFld CsrRw

C KFld CsrCl

C*

C HelpKey1 KList

C KFld Screen

C KFld StRow 3 0

C KFld StCol 3 0

C*

C HelpKey2 KList

C KFld Screen

C KFld StRow 3 0

C KFld StCol 3 0

C KFld Line 3 0

C*

C HelpKey SetLL HELPRCD

C Screen ReadE HELPRCD

C If %EOF(HELPFILE)=*ON

C HelpKey SetLL HELPRCD

C Screen ReadPe HELPRCD

C EndIf

C If %EOF(HELPFILE)=*Off

C If ((HLSTRW<=CsrRw AND HLENRW>=CsrRw) OR

C (HLSTRW=0 AND HLENRW=0)) AND

C ((HLSTCL<=CsrCl AND HLENCL>=CsrCl) OR

C (HLSTCL=0 AND HLENCL=0))

C Eval StCol=HLSTCL

C Eval StRow=HLSTRW

C Else

C Eval RetCde='ER'

C Eval *INLR=*ON

C Return

C EndIf

C*

C* First Try Web Page version

C*

C Eval Line=0

C Clear RtCode

C HelpKey2 Chain HELPRCD

C*

C* Call program to using RUNRMTCMD to run the specified Application

C* (in this case the web browser using the help document)

C*

C If %FOUND(HELPFILE)

C Call 'DSPWEBPGE'

C Parm HLWBPG

C Parm RtCode

C Else

C Eval RtCode='ER'

C EndIf

C*

C If RtCode='ER'

C*

C* If RUNRMTCMD returned error display green screen help

C*

C HelpKey2 Setll HELPRCD

C Eval *IN30=*Off

C Write HELPWIN

C Eval EOFHelp=*Off

C DoW EOFHelp=*Off

C HelpKey1 ReadE HELPRCD

C Eval EOFHelp=%EOF(HELPFILE)

C If EOFHelp=*Off

C Eval RRN=RRN+1

C Eval TEXT=HLTEXT

C Write HELPTEXT

C EndIf

C EndDo

C*

C If RRN>0

C Eval *IN30=*On

C Exfmt HELPWIN

C Eval RetCde=' '

C Eval *INLR=*ON

C EndIf

C EndIf

C EndIf

C Eval RetCde=' '

C Eval *INLR=*ON

Figure 1: Use the RPG program HELP to display help text based on cursor position.

Figure 2: Use an Access database to track program source modifications and save time performing future code maintenance.

Mike Faust is a senior consultant/analyst for Retail Technologies Corporation in Orlando, Florida. Mike is also the author of the books Active Server Pages Primer, The iSeries and AS/400 Programmer's Guide to Cool Things, JavaScript for the Business Developer, and SQL Built-in Functions and Stored Procedures. You can contact Mike at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Mike Faust available now on the MC Press Bookstore.

		Active Server Pages Primer Learn how to make the most of ASP while creating a fully functional ASP "shopping cart" application. List Price $79.00 Now On Sale
		JavaScript for the Business Developer Learn how JavaScript can help you create dynamic business applications with Web browser interfaces. List Price $44.95 Now On Sale
		SQL Built-in Functions and Stored Procedures Unleash the full power of SQL with these highly useful tools. List Price $49.95 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails