All organizations facing the Year 2000 (Y2K) challenge have the same basic problems: Theyıve got to modify a big chunk of their code to handle dates in the next century, and theyıve got a deadline that isnıt likely to be pushed back. Failing to fix all of the date-afflicted programs means stalled applications and, more important, products that wonıt sell and customers who wonıt get served.

Nowhere is this more true than at the Social Security Administration (SSA). You know what happens to your customer-support and help-desk lines when thereıs even a minor bug in your product or a glitch in service delivery. Now imagine 50 million people not getting the monthly income on which they depend. In fact, the SSA predicts that a Year 2000 error that affects just 1 percent of monthly payments would induce as many as a half million people to call the agencyıs support line or visit one of its field offices.

With less than two years to go until January 1, 2000, you might think Chris Murphy, a computer specialist at the SSAıs Baltimore headquarters, would be a bit nervous. He isnıt ı or at least he doesnıt sound like he is. His apparent confidence stems in part from the head start the SSA has on the solution: It began its Year 2000 effort long before "Year 2000" became a buzzword that strikes dread into the hearts of DBAs and managers everywhere.

"We started working on Year 2000 changes to our code back in 1989. Thatıs when our first application ran into it," says Murphy. "It worked with recovering overpayments, in which we set up recovery schedules for as long as 10 years. So in 1989 we started testing out changes for 1990 with a 10 year recovery period, and the system couldnıt handle ı00ı as 10 years after 1990."

When the implications of that little error message set in, the SSA began a massive effort to find and fix date fields and the programs that work with those fields so that they would handle dates beyond the year 2000. Early on, it estimated that about 20 percent of the lines of assembler and Cobol code would be affected by the millennium change ı one fifth of the more than 30 million lines of code in production at any given time. (For more information, see the sidebar: Social Security Administration Data Processing At A Glance.)

Whatıs more, each record in the SSAıs CA-IDMS databases has a high proportion of dates. "Weıre working with date fields that represent everything from when someone was born to what year they earned wages and how much they earned in that year," says Murphy. "We track wages back to 1935." Other typical date-field entries include the dates a person starts and stops work for each employer, changes in salary, when a marriage begins or ends, when children are born, and so on.

Whatıs My Line?

In the years since that fateful day in 1989, Murphy and his associates have relied on several software tools as well as their own skills as programmers and date-field detectives to ensure Year 2000 compliance. [Editorıs note: While it acknowledges that it uses certain software and hardware products, the Social Security Administration does not endorse any products or services.]

To help get a handle on the daunting task of finding the lines that need to be modified, the SSA used Viasoftıs Estimate 2000, which identifies portions of code that contain date information and helps determine whether they will be affected by the turn of the century. Although tools such as Estimate 2000 highlight the actual lines of code that need to be reviewed as well as aid in calculating the time, effort, and costs involved in carrying out the modification project, a programmer must still examine all of those lines, one at a time.

"Some lines may not need to be modified because theyıre there for display purposes," explains Murphy. "Human beings are still going to know that if the last two digits in the date are 00, it means 2000 instead of 1900. But for logic comparisons and things like that, we do need to worry about how the dates are being represented and how theyıre being interpreted. In some cases weıve expanded the dates to four-digit years. In other cases weıre applying ıwindowingı on the years. Basically, that involves setting a pivot year. The classic example of a pivot year is 50. Anything 50-99 is in the 1900s, anything from 00 to 49 is in the 2000s. We build in logic to determine which century those two digits are in."

Once each change is made, it is tracked by CA-Endevor, a change- and application configuration-management product from Computer Associates. CA-Endevor identifies the changes made, helps manage software entities, provides security checks, and compiles information about the build process. "It also enables us to track the source of the executables to verify that the executable is made up from a given level of source," says Murphy.

Source Recovery

In the mainframe world, itıs not unusual to work with code written not just years ago, but decades ago. As Murphy says, "The standing line is, old hardware gets put into museums. Old software gets to put into production every night."

Indeed it does. But what happens if you need to modify an executable and you canıt find the source code? According to Murphy, this was the case with a handful of utility programs written in assembler code, some of which had last been run through a formal mainframe assembler in 1972. The source couldnıt be found, and that source had to be checked for Year 2000 readiness.

"As the source libraries got full, every so often weıd go through and do a cleanup, saying, ıAccording to our records nothing has changed on this code in the last five, 10 years. Let us know if itıs still needed.ı People didnıt pick up on the fact that some of these programs were utility modules that were still being used on a regular basis," recalls Murphy. "So they got deleted."

Enter the Source Recovery Company (SRC), a Framingham, Mass. firm that specializes in doing just what the name says: taking an compiled application and decompiling it. SRC uses proprietary techniques for disassembly, pattern matching, operand analysis, internals analysis, and locating any relevant supporting information. Says Murphy: "They give us back source code that will assembler-compile and re-create the exact same object code and the executable thatıs running today. Then we can take a look at the code and what itıs doing, and determine whether or not the code is performing any date-related functions."

Aside from the decompiling service it performs for the agency, SRC offers additional services geared specifically to addressing Year 2000 compliance: It determines which version of source code is in production when multiple source versions exist, reconciles similar versions of source code into one correct version when the original version is missing, and provides meaningful data names for defined variables in recovered programs.

Getting Reengineered

Any reengineering project ı even those not on as grand a scale as the SSAıs ı has a significant impact on an IS department, especially in terms of the hours DBAs and programmers must give over to Year 2000 tasks. Often IS personnel are torn between doing their "regular" jobs and the not less-important Year 2000 work. Like many other organizations, the SSA didnıt have room in its budget for hiring additional staff or contractors for the Year 2000 effort.

"Because we were trying to do this along with our other workloads," says Murphy, "there have been occasions when people have come back after they said they could get things done in a certain amount of time and said, ıWell, no, we really canıt do two things at the same time.ı But thatıs to be expected. There are finite resources and a definite deadline on Year 2000."

Another problem for the SSA is the sheer size of the system and the complex interrelationships between the 20,000-odd programs involved. "Every time we come up with an approach or a solution for one application," says Murphy, "we have to make sure that itıs going to work with the applications upstream and downstream from it." The requisite process of testing and retesting is a major time consumer. (See "Testing Year 2000 Conversions" by Andrew Pollner in this issue.)

The Byzantine nature of the SSAıs rules and regulations add to the complexity, especially in testing programs for Year 2000 compliance. Because of legislative changes in benefit amounts over the years, some groups of beneficiaries are paid at different rates from others. For instance, the benefits paid to people born between 1918 and 1925 are based on a different formula from others. Such groups are known within the agency as "notches." Without notches, testing programs for Year 2000 compliance would be a relatively simple matter of artificially aging data and running the programs.

"We canıt just go and take every date in the record and push it up by five years or 10 years or whatever, to test out how things are going to work," says Murphy, "because by changing their date of birth we would be taking them out of the notch. When we do our tests, we need to make sure that weıre still doing the computations based on their being in the notch."

Another potential pitfall is taking a personıs date of birth and pushing it up 10 years to test future scenarios. An 18 year old, for instance, may be about to become ineligible for certain benefits. Simply adding 10 years to the date-of-birth field would result in the benefits being calculated for an eight year old. Murphy and his associates must be puzzle masters. "Weıve got to be careful about how we manipulate the dates," he says. "We canıt just take every date field and add 10 years to the value."

To make the process of setting up future test scenarios a bit easier, the SSA has dedicated its recently purchased mainframe ı one of six Hitachi Data Systems Skyline Series-72 computers with HDS GX processors ı entirely to testing. "Itıs going to be running day in and day out with its internal clock set as though it were running in the Year 2000 and beyond," says Murphy. "Weıll then take these applications over to that box with aged copies of data to verify that they also work properly come 1999, 2000, 2001, and so on."

Murphy says that 80 to 85 percent of the mainframe code has been modified, regression tested, and is now running in production. But that doesnıt mean the SSAıs Year 2000 project is about to end. Still another problem is looming, and itıs one Murphy and his cohorts canıt do much about: Not only must the SSAıs own programs be converted, but they must also work with a variety of other computer systems, such as those each state uses to compile information on disability insurance beneficiaries ı data that is shared with the SSA. If the states donıt bring their systems into Year 2000 compliance, SSA recipients could experience significant delays in receiving payments.

Once the Year 2000 milestone has passed, the SSA will focus on implementing its plans for migrating its MVS- and CICS-based mainframe systems to a multitier client/server environment. Each of the field offices now employs LAN-based dumb terminals and transfers data in batches to the SSAıs central computers in Baltimore. (The SSA retired the last of its punch-card reader systems in 1995.) It is also looking at moving its databases from CA-IDMS to IBMıs DB2. A pilot client/server disability-claims application is being rolled out at press time.

"The idea," says Murphy, "is to get some of the computing resources and power out in the field to help them get some automated answers and processing back more quickly rather than putting things in and waiting for the batch run at night to come back and tell them whether or not things actually worked out as they expected.

"This is a process thatıs been of great interest to Congress over the last few years, and itıs of interest to us to take the client/server environment and see what it can do to help us improve our processing."

And if youıre planning on retiring soon, or even long after the Year 2000, thatıs good news.