View Example Code
In my previous job at a local telephone company, we received calls requesting a "locate," a description of where utility cables and pipes were buried. People need this information to find out if they can dig in a particular location. Contractors, home, and business owners call in to receive this information to avoid causing damage when digging. When these requests were received, over our special toll-free number, the information was relayed via fax to the phone company's main building, where the requests were picked up and entered into the AS/400.
On another floor of the same building sat "Tom," who was responsible for assigning someone to go out into the field, find the cables, and spray-paint the ground. He was the guy who ultimately sent the guy out with the answer to the question, "can you dig it?"
The problem was that when Tom was sitting in front of his menu of options, he didn't know which option really needed his immediate attention. He had a high volume of other responsibilities to concern himself with daily. If one of the requests was entered at, say, 9:00 a.m. and Tom didn't happen to select the "locates" menu until 4:00 p.m., a day was wasted and perhaps a cable was dug up (an expensive repair and an impact to service).
But I was able to help Tom do a better job. By creating the initial menu in RPG, not SDA, you can have the menu program check to see if any of the options have something important waiting and display the information.
So, I created a menu in RPG for Tom. Whenever he signed-on and whenever he returned from any chosen option, the RPG menu would refresh and display the option in red if (and only if) there were cable locate requests waiting for him to assign. Otherwise, the option was displayed in green. I also gave him the option to refresh (or re-check the appropriate files) at will by pressing F5.
Obviously, the same approach can work with new work orders, new sales to process, or anything else your users need to do in a timely manner.
Let's take it a step further. Maybe your RPG menu program could count how many of each outstanding task is waiting for action and display the volume for each task next to the menu option. That way, if there is only one of Task A and people think that's more important, that option could be selected first, and the third item under Task B or the sixth under Task C, which aren't as important, could wait. I'm sure you can see how this can help your users prioritize time and maximize productivity.
The easiest way to count quantity is to use a logical file for each appropriate menu option and use Select/Omit to select only those records with a pending status. In Tom's menus, 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 would no longer display under Task A on Tom's menu because there was a logical file that only selected those records with a status of "W."
It was pretty easy to count all the records in that logical file. To help Tom further, the menu selection turned red when one of the pending tasks was a "locate." Of course, if there were no locates, the menu selection was green. If there were no pending tasks at all, the menu selection was turned off entirely.
The RPG menu program uses a display file with options listed and various indicators to change the colors of the option numbers and option descriptions. It also has an input field for the selection choice. The RPG program (besides the counting section) calls a CL program and passes it the option number. Then the CL program can do any print file overrides that might need to be done before calling the program that is behind the option.
After each option, the CL program ends and control is returned to the RPG program. The RPG program then checks the counts again and re-displays the menu options, colored appropriately. In this case, the date and time on the screen are important as they indicate when the program last "looked" for updates.
To summarize, the first step is to indicate there are tasks pending. The second step is to count how many of each task are pending. Then, you can flag options in red that are critical and display a count. Of course, you do have to set up the initial program for the user profile. And don't forget to add an option to sign-off.
Here's another idea. You could set it up so that when the menu runs, it logs those counts to a file whose contents are displayed in a status panel for that person's supervisor? Then Tom's supervisor could see that Tom has 5 Task B's, 7 Task C's, and 9 critical Task A's. The supervisor also could see that another employee named Mary (who has her own file) has 3 Task A's and 5 Task B's, and so on.
If I were the supervisor, I'd want to know whether or not my people are getting their work done. With this simple technique, you can help employees do their jobs better and help management determine what's going on. Everybody wins.
View Example Code
G. Wayne Hawks is a programmer/analyst with 15 years of experience in AS/400 programming. E-mail: email@example.com