Midrange Programmer--How to Get New Shoes with Work-Flow Oriented Menus

"I got new shoes!" Don't you love it when a 4-year-old tells you this, with such raw enthusiasm? Well, I got some new shoes, too, and they belong to my coworkers! I know you've heard this before, but please bear with me and see if this isn't a cool idea. Put yourself in your coworkers' footwear for a moment. When they're sitting in front of their menu, how do they know what option to take? What needs their attention the most, right now?

You can help your fellow employees answer this question by creating their initial menu in RPG, not SDA. Why? Because you can have their RPG menu program check to see if any of their options has something important waiting for them to do, and it will tell them.

Let me give you an example. In my last job, I worked for a telephone company. In the state of Washington, there was one toll-free number to call in order to request a "locate" of all cable and pipe locations, to prevent damaging these cables or pipes when digging to put in others. The people at the toll-free number would determine all the utilities to contact for the caller's reported location and would then contact (via fax, at that time) each of those utilities. The faxes would go to an upstairs office at the phone company's main building. Someone would pick up the faxes and enter them into a file on our AS/400, via a program I wrote for that purpose. (It does seem kind of archaic now, re-keying all of that information, but it seemed like it then, too!)

Anyway, someone else, let's call him Tom, had an office on a different floor, and he was responsible for making sure someone was assigned to go out and find where the cable ran and to spray-paint the ground there, so it didn't get damaged when the caller went to dig. If one of those requests was entered at, say, 9:00 a.m., and Tom didn't happen to take the menu option to work with new cable locates until 4:00 p.m., a day was wasted, and perhaps a cable was dug up (which is a very expensive thing to repair, and affects service).

So I created a menu for Tom in RPG. Whenever the menu was called (when he signed on or returned from any chosen option), it would change that option's number and description to display, in red type, any cable-locate requests waiting for him to assign. I also gave Tom the option to refresh or to recheck the appropriate files by pressing F5.

Obviously, the same approach can work with new work orders, new sales to process, or anything that a fellow coworker needs to do in a timely manner.

Let's take that a step further. Your RPG menu program could, for example, count how many of each type of task has to be done, and put that number next to the menu option; if one type of task is more important than the others, it can be given a higher priority.

So how do you count how many of each thing is waiting? The easiest way is to use a logical file for each appropriate menu option that selects only those records with the appropriate status and indicates that they're waiting for a certain user. In the example above, the status field always had a W for "written" when Tom needed to see it. After Tom assigned it, the status changed to A, for "assigned," and he no longer saw it with that one option. So there was a logical file that only selected those records with a status of W. It was pretty easy then to count all the records in that logical file, and in the example above, if there were any records, it turned on an indicator that made the color red. Of course, if there were none, it turned the indicator off.

The RPG menu program, of course, uses a display file with the options listed, the various indicators to change colors of the option number, and the option descriptions. It also had a choice number input field so the user could enter which option to take. The RPG program calls a CL and passes it the option number. Then the CL can do, for example, any print file overrides that might need to be done before calling the program that is behind the option. After each option, the CL ends, control is returned to the RPG program, it checks counts again, and redisplays the menu options, colored appropriately. All green meant nothing was immediately pending. In this case, the date and time on the screen is very important, because it indicates when it last looked for anything that needing to be done.

Now imagine you've written an RPG-based program that counts how many of each type of task is waiting for the user. And it does that every time an option is taken and control is returned to the menu program. You do, of course, have to set that up as the initial program for that user profile. And, of course, don't forget to add an option to sign off.

So what do you have? The first step is to just indicate in some way that there are things waiting to be done. The second step is to count how many of each thing there is waiting to be done. Of course, you could do both. Make red the things that are critical and give them a count of how many are waiting. But here's another thought: How about, when the menu runs, logging those counts to a file whose contents can be displayed in a sort of status panel for that user's supervisor. So Tom's supervisor could see that he has five of these, seven of those, and nine of them are critical. If I were the supervisor, I'd want to know if my people were getting their work done, and if not, then why. Help your workers, and you'll never know what kind of footwear you'll be able to afford.

G. Wayne Hawks is a programmer/analyst with 15 years of experience in AS/400 programming. E-mail: donkey_hote@hotmail.com