OS/400 includes several tools that can find a string of text but only one that can replace one string of text with another. Moreover, that tool, SEU’s Change command, works only interactively and not in batch. This article presents a utility that can not only scan a member or group of members for a search string but can also replace it with another string. Although the shop that produced this tool did not design it for Y2K conversion, the tool has nonetheless proven useful to that end.

My firm awoke to the Y2K problem in 1996 when we received a call from a client with an accounts receivable due date after 1999. That single call swelled to a slow trickle of calls by midyear, and although it would have been simple enough to swap the one six-digit date in favor of a Y2K-compliant field, we figured it was time to face the music for all of our applications.

After a brief evaluation process, we decided to replace all our six-digit dates with eight-digit dates and all two-digit years with four digits. The date data type looked attractive, and had we more time to explore its capabilities, we might have employed it. At the time, however, we had a mile-long backlog of change requests that were more interesting and more important to our clients than Y2K conversion. Face it: Building industry intelligence into applications wins clients; Y2K compliance just prevents them from going to the competition.

Identifying Dates

With the format decision made, we needed a change strategy that would make our code ready for distribution before the trickle of date complaints swelled to a stream. Working in our favor was the fact that shop standards required all date fields in files to contain either the suffix “DAT” or the suffix “DT,” save a small minority of date-of-birth fields ending in “DOB.” We also knew that year fields—abundant in our application—would almost uniformly have the suffix “YER,” with only a few deviants ending in “YR,” so the fields in question would at least be easily identifiable. In addition, date validations were all performed through a single called program, so accommodating Y2K date validation would be painless.

We also had going for us the fact that we require date conversions to be made through that old multiplication trick (MMDDYY * 10000.01 = YYMMDD; YYMMDD *
100.0001 = MMDDYY). This conversion mechanism has a lot of well-respected detractors but cannot be faulted for succinctness. Finally, DDS for display formats (except subfiles) are required to place field prompts at positions 2 and 40 with data entry fields at 21 and 59, which meant that tacking two extra digits onto a date would rarely interfere with other fields. Let’s hear it for shop standards.

Still, identifying dates wasn’t even half the problem. Even with a limited number of patterns to locate in date field names, changing command, DDS, RPG, and CL source code was still going to be quite a chore. PDM could help us locate fields, edit codes, and conversions that needed to be modified, but it could not make the changes for us. The application we supported topped out at over 250,000 lines of code, which is modest by some standards. Nevertheless, for a small shop with only two programmers to do the coding and testing, it was looking like a three-month job. Tack on testing time, and, suddenly, two warm bodies would be out of action for a good part of the year.

This was not good news, especially since we viewed this as a maintenance item, meaning we had already been paid to do it, on top of all our other routine maintenance work. To make matters worse, it was not even interesting programming. Y2K conversions are a matter of going into program after program, making the same changes (and some new mistakes), getting out, compiling, testing, fixing, and moving on to the next program. Yawn. Come to think of it, Y2K changes are exactly the sort of dull, repetitive work from which computers are supposed to save us. There are utilities out there that do it, but they take a substantial investment of money to buy and time to learn to use, and their value evaporates once the modified code is put into production.

Another Use for a Handy Tool

Fortunately, we had in our shop a homemade utility we had been using for several years, which allowed us not only to locate strings in source code but also to replace them. Of all the programming aids we had developed or downloaded over the years, this was the only one that saw day-to-day use. Scan and Replace, or SCNRPL as we called it, could find and replace strings in command, DDS, CL, or RPG source members and had a parameter that allowed us to automatically recompile any changed source member.

But could it be used to simplify a Y2K project? Since file, display, and printer DDS source was kept in separate source files in our shop, I quickly scanned through the data file DDS in all application libraries for six-digit, zero-decimal numeric fields. They were all dates. I scanned the DDS again, this time replacing all occurrences of “6S 0” with “8S 0” and recompiling, and then recompiled dependent physical file DDS (those that used the REFFLD keyword with fields in the changed files) and logical files.

Display and printer files would be just as easy: There were only a few six-digit fields because the majority of dates had been defined in reference to database fields. Output dates would use an edit word of “ / / ”, never an edit code. This 6-byte date edit could easily be replaced with an 8-byte edit word, but, to make sure the newly changed field references took, I recompiled all source with PDM rather than just the source that had been changed through SCNRPL. Whew. This Y2K thing was rough.

The next day, I tackled RPG. I searched for all internally defined date fields (e.g., six-digit, zero-decimal numeric fields with names ending in “DT” or “DAT”) and replaced them with eight-digit fields. A similar operation took care of all two-digit year fields (those with two digits and zero decimals and ending in “YER” or “YR”). Since the only reason the numbers 10000.01 and 100.0001 would occur in RPG source would be for date conversion, it was easy to scan and substitute 10000.0001 for either. Also, “UDATE” would have to be replaced where it occurred with “*DATE.” Doing this in all application libraries would take a while, so I coded the various scans into a CL program, set them running, and went home. (Come to think of it, a good chunk of our Y2K conversion took

place after hours while I was puttering in the garden.) Again, because more programs would be affected than just those to which changes had been made, I chose not to use the automatic recompile option, preferring instead to recompile everything through PDM after the fact. Fewer than 10 percent of the programs failed to compile. Since it was one of only a few in the entire application that dissected a date in a data structure, I changed the validation subprogram by hand and added a feature that would default the century to the current century if none were entered.

Commands were tougher because the date parameters there were defined as 6-byte character fields, as were a good number of non-date parameters. They still adhered to the same date naming conventions used in RPG, so it was relatively simple to replace everything in the declaration (DCL) from the suffix through the length (LEN). “MMDDYY” prompts were infrequent and replaced with “MMDDYYYY” where necessary. SCNRPL does not compile commands, but since all of our commands ran CL programs named CommandName + “CL,” batch compilation through other means was a breeze. All our CL programs used CVTDAT for conversion purposes, so it was a relatively small matter to have SCNRPL replace “*YMD” with “*YYMD” and “*MDY” with “*MDYY.”

In fairness, there were quite a few year fields in the display and print file DDS that had fields following them that did not use relative positioning and so had to be changed by hand. There were also a few unexpected “DTE” suffixes for date fields in the RPG, but these were quick fixes, and the week that we spent in testing showed so few problems that we shelved it and went into distribution. Overall, we spent two weeks converting and testing 250,000 lines of code.

Building SCNRPL

The SCNRPL utility consists of a command, printer file, and three ILE programs. These three programs are built from five modules. (The source members used to create these objects are listed in Figure 1.)

SCNRPL has six parameters, which are listed in Figure 2. You may scan a single member of a source file, all members, or only those members whose names begin with a certain group of characters. SCNRPL ignores trailing blanks in the search and replacement strings.

The Allow data shift (ALWDTASHFT) parameter tells SCNRPL how to behave when the string for which you are searching is not of the same length as the replacement string. You may specify a *YES or *NO value if you wish, but you may prefer the default, *SRCTYPE, which means that the source type determines whether or not data is to be shifted. For commands, CL members, and text, data is shifted; for RPG and DDS, it is not. Consequently, replacing a file name with a longer file name does not mess up an RPG F spec by shifting the position entries to the right but correctly adjusts the closing parenthesis of the FILE parameter of a RGZPFM command in keyword format.

The recompile option calls the SCNRPLCM program for each changed member. I included only the types of members we wanted to recompile. You may want to add others.

Source members used to create this utility are available for downloading from the Midrange Computing Web site at www. midrangecomputing.com/mc/99/04. Compile them in the order shown using the compilation instructions given.

Our Happy Ending

Because we tested our replacement runs on a single member before running them against all the source files in our libraries, source errors from replacement were nonexistent. Buoyant from our success with automated programming, we wrote another utility that would generate RPG conversion source (since CPYF wouldn’t do) and ran up conversion programs for each of our physical files. Our Y2K crisis was over, and the money we saved in the process will more than pay for the generators we’re buying to get us through next New Year’s Day.

Source member Type Program Function

SCNRPL CMD Command interface for SCNRPL SCNRPLCG RPGLE SCNRPLCL Checks for a generic name SCNRPLCL CLLE SCNRPLCL Command-processing program SCNRPLCM CLLE SCNRPLCM Compiles source members SCNRPLRG RPGLE SCNRPLRG Revises source code SCNRPLMT CLLE SCNRPLRG Determines type of a source member SCNRPLPF PRTF Prints a report listing occurences of search string

Figure 1: The SCNRPL utility consists of three programs, a printer file, and a command interface.

Parameter Description

SRCFIL A qualified source physical file name MBRNAM A member name, a generic name, or *ALL SCNOBJ The string for which to search
RPLOBJ The replacement string
ALWDTASHFT Whether or not to shift source code when the search and replacement strings are not of the same length.

RECOMP Whether or not to recompile changed source members.

Figure 2: SCNRPL requires six parameters to do its magic.