Prescriptions for Ailing Software
Author: G. Wayne Hawks
What As programmers, we often divide our time between giving birth to new software and trying to prolong the lives of the old applications. Maybe we should be called Software Doctors because we have to diagnose the errors in a program and then fix them.
To help you diagnose software problems, in this article, I take you through some time-saving techniques. I'll start with the search option in Program Development Manager (PDM) and end with a utility I use frequently that I wrote several years ago.
As an example, imagine this situation: your company has just been purchased by another company. Your job is to find and change your code to replace the old company name with the new name.
In PDM Option 25, you are given several choices. These are the most interesting:
- The text (string) you want to find.
- The search from column number.
- The search to column number.
- Whether to match or ignore the case of the text.
- The PDM option to take for each member that has matching text. (This option is powerful.)
Item 1 is simply the text you want to find. In this example, you'd type in your company's old name.
Items 2 and 3 (the search from and to column numbers) limit the width of the search. Suppose you were looking for what changed a particular field. Assuming you're using ILE RPG and not changing it in an EVAL statement or free-form RPG, you might want to limit your search to columns 50 to 64, the Result field. If you don't find your text string with a limited search, you can always run the search again and look at all the columns.
I always set Item 4 to ignore the case of the text. I still type my code in upper case, but my comments appear in mixed upper and lower case because it makes the comments easier to read later. Other programmers also may use lower case, so it's best to set the option to ignore the case of the text.
The PDM option 25 search tool is a powerful way to find text, but what if you need to make massive amounts of changes as in our example? Item 5 is the answer. First, you could do a trial scan to discover whether the search selects all the members you want.
Then after verifying that it works, you can set item 5 to do PDM option 3, which copies all the source members to a brand new source file. You can then change your company's old name to the new one in every member in that new file. When you are ready you can then do an option 14 to compile it, and then do an F13 to copy that for every member of that source file. When you are finished, you then can copy it all back to your original source file. (Use PDM option 3 for the first member and F13 to copy that option for all members again.)
It took me a while to realize that source code is just data and that this data is easy to manipulate. Every source file has three fields: SRCDAT, SRCDTA, and SRCSEQ. The date of last change is in SRCDAT, the line number is in SRCSEQ, and the data is in SRCDTA. So you can write programs that change your program code.
Using the company name example, you could use Display File Description (Member Info Only) of the new source file to an output file. You could then read that output file in a CL to determine which members to override. Then using an RPG program you created to scan through a member, you could look for your old company name and change it to your new company name. The CL program could have the RPG change all the source file members. You would only have to write the CL and RPG programs to do the work. In other words, you can either go into each member and use search and replace, or just write one CL and one RPG program to do the same thing. Because you're working with copies, you can try it. Just be careful to check that it really does the right thing before you compile them or copy them back.
Here's another situation. What if you know that somewhere in a program, a field is getting changed, but you don't know where? You can use option 25 for this problem too, or use F16 when you are editing the source. In both cases, it positions the source to the next occurrence of the field. If the search string is only in the source once, it's fine. Otherwise, you may have to hit F16 time repeatedly. Unfortunately, when you hit F16 repeatedly, it's easy to miss the right spot and you fly right on by, and you have to start over.
That situation used to happen to me a lot, so I had an idea. Wouldn't it be better to just look at a list (subfile) of source code lines that contain the field in question? Then, at a glance, I could see which line might be changing that field.
To solve the problem, I created a program I call Source Member Scan. While I was at it, I built it as two subfiles I can toggle between. One subfile has the source and line number and the other subfile contains the source and date it was last changed. After all, if the program has been working fine for years and a problem has just cropped up, it would be good to know if a change has been made in the program recently or if something else in the data stream caused the problem.
I used a PDM user option to call the program. I used "FS" to stand for File Scan because you can only use two characters. By using the PDM user option, the library, source file, and member are passed along to the program and the CL can do an override to the correct code.
When you choose the FS option, you first get a screen that asks you to enter up to four text strings. These are the strings you want to search for. I created it as an "or" search. If any one of these strings is found in a line of code, that line of code is added to the subfiles.
I also included an option on the screen to indicate whether you want to include BEGSR, ENDSR, and Format Names. It's helpful to have those as it gives a hint to program flow to know in which subroutine(s) that field is getting changed. Because a display file is of the biggest places a field can get changed, I wrote the program so it also works on display files (hence the Format Names option).
The search string text you enter and whether or not you want to include BEGSR, ENDSR, and Format names is saved in a file by user. The next time you use the option, the information is pre-populated into the screen. Because you may be using this program over and over while searching, it's handy to not have to keep typing in the same stuff repeatedly.
After you've filled in the strings you want to look for and you press Enter, you'll get a subfile display that only contains lines with one or more of the text strings you entered (and possibly BEGSR, ENDSR, or Format name lines). At the top is a count of how many lines it found. The first subfile to be displayed is the one with the line number on the left. Just press F8 to toggle between this subfile and the one with the date last changed on the left.
Whether you're making mass changes or just need to find what's happening to a field, I hope that these techniques and this utility help you in your endeavors. Maybe it will free up enough time so you can make more house calls to your own house!
Click Here for the Utility
G. Wayne Hawks is a programmer/analyst with 16 years of experience in AS/400 programming. E-mail: firstname.lastname@example.org