In-Depth

SNA Server Case Study

• 12/01/1998

With the Year 2000 rapidly approaching, Spokane Software, a leading provider for growers, packers and shippers of agricultural products in the United States, implemented a Microsoft-based solution to analyze more than 4,000,000 lines of RPG and other legacy code. Using Microsoft’s SNA Server 4.0 with the OLE DB Provider for AS/400 and VSAM, Spokane Software was able to maximize the resources of their small staff and budget to conquer this huge problem.

Working with Spokane Software’s AS/400 programming team, Marc Mims, Director of Product Development and Jonathan Lundquist, Senior Software Developer, faced the daunting task of analyzing and modifying 20 years of legacy and PC-based source code. Their automated Y2K solution would need to accurately examine every line of code and search for date fields and other variables that could have date dependencies. The solution would then repair the areas that it could, or indicate that manual intervention by the AS/400 programming team for further inspection and resolution. According to Lundquist, "the whole point of the process was to ensure that all changes have been made accurately, with minimal human input."

Mims and Lundquist reviewed several packaged Y2K date conversion utilities, which were able to find many date fields containing 2-digit years, but not all the programmatic dependencies. According to Mims, these tools "might help you find 80 percent of the non-compliant dates, but the other 20 percent is horribly difficult to find." From their research, the team decided to develop an automated Y2K interoperability solution using Microsoft technologies to transport, manage and modify the more than 1300 files that needed to be inspected or changed. Their solution incorporated Microsoft SNA Server 4.0 with the OLE DB Provider for AS/400 and VSAM, Microsoft Access, the Microsoft Visual SourceSafe and Microsoft OLE Automation to allow consistent platform integration amongst all the disparate technologies within the system. Using custom OLE automation, the code or file was brought from the AS/400 through SNA OLE DB Provider to their testing machine.

The file was then checked into Visual SourceSafe and loaded into the Access database. This process allowed for version control of the files and provided the ability to examine the data using pre-determined rules. The source code was then run through an automated analysis utility that checked for date variables and programmatic dependencies of those variables. If errors were found, they would be automatically remedied, or an error message would pop-up that could alert the tester that manual intervention might be required. Once any necessary manual modifications were completed, the remedied code was checked back into Visual SourceSafe with a new version number and uploaded to the AS/400 via SNA Server and the OLE DB Provider.

The process analyzed the entire four-million line code base as a single unit and discovered that 600 of their 1300 database files needed Y2K modification per the results of the analysis program. "All these pieces (referring to the Microsoft products) were part of the solution," stated Mims during the interview; "we traced every possible path for every date field."

The team started designing their automated analysis tools in May 1997 and completed this first phase of their Y2K conversion project one year later. The conversion process began in mid-June 1998, and within six weeks they had transferred 40 percent of their code with not one single error resulting from faulty automated changes. In addition, another benefit of the automated solution was that the team identified unused source code that often needed to be exterminated.

Early into the process the team knew they had a large task ahead of them. The sheer magnitude of the number of lines of code developed over many years, meant that multiple programmers may have injected errant or unused date fields into Spokane Software’s system. Therefore, with this fact assumed true, any field that had date content would need to be identified and determined how it was used. According to Mims, "the permutations (of the AS/400 date fields and variables) were astronomical." One of the common programming issues that occurs in RPG code is the use of dates in multiple ways, such as mm-dd-yy and dd-mm-yy. Using SNA Server in conjunction with the other Microsoft products and their custom-designed tools, Spokane Software identified every spot in their system that referenced a time-related variable and even traced the reference to external code where another date dependency might exist.

One key to Spokane Software’s Y2K remediation success was being able to use OLE automation to bring the suspect code into Access, allowing the programmers to utilize PC tools to analyze the pertinent data and make necessary modifications. Written by Mims and Lundquist in the Visual C++® development system, the automated analysis tool runs 24 hours a day, 7 days a week, incorporating recent source changes into the process. "This solution was valuable because we could see absolutely everything once it was imported into Access," says Mims, "there were definitely some odd dates we discovered that we never would have guessed."

Another key benefit to their Y2K solution was the ability to transfer code from the AS/400 to the analysis machine in real time via the OLE DB Provider in SNA Server. For Mims and Lundquist, this meant that recently updated AS/400 production files could be checked immediately after they were used, verified or changed and uploaded back to the AS/400 -- all without effecting production. According to Mims, SNA Server, combined with Spokane Software’s custom-designed automated analysis tools "allowed us to leverage a small amount of human resources to solve a large problem -- and do it accurately."