DRJ's Spring 2019

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 31, Issue 4

Full Contents Now Available!

Many words have already been written about the so called millennium bug. Probably many more will also be written prior to January 1, 2000. So why am I adding to the number when surely we would all be better off rolling our collective sleeves up and getting down to fixing the problem while there is still some time left? After all it is essentially a very simple problem - too few digits in the year - so why all this talk?

The problem may well be simple in the extreme, but the solutions that have arisen to solve it have caused a small sub-industry to come into existence. Year 2000 software has become highly competitive and the user may well be baffled as to his or her needs and requirements.

Initially, for most people, is the need to measure the scale of the problem. Management needs a figure to budget for the solution just so they could stay in business. Impact Analysis tools are available to produce measurements of how date affected systems were.

At this stage a number of people have undoubtedly decided to port their systems to another platform and effectively solve the problem with a total rewrite. However, most have decided to amend their existing systems and make them Year 2000 compliant.

At this stage the need for detailed Source Analysis was required. Date related data names needed to be tracked on a program by program basis. The Analysis needed to be capable of allowing the programmer to quickly and effectively make the changes towards Year 2000 compliance. This is usually done by creating some sort of smart-edit session where the necessary changes are done in a semi-automatic manner. It is interesting to note that most sites have decided to use some form of windowing technique rather than a full expansion of dates into four digit years.

Putting it crudely, most people have realized that the scope of the problem was such that they did not have the time to do the job properly! However, it must be said that a sizable minority who started ahead of time have done just that.

Having made the necessary source changes the next step is to test these changes. An obvious requirement is to be able to run the program so as to receive a Year 2000 date from the operating system. People can either run their applications in an LPAR that had been IPL’ed with a Year 2000 date or use a Date Simulation package to achieve the same end. Most have decided to go for the Simulation package for unit testing as it offers a greater degree of flexibility saving the LPAR approach for system testing. However, it has become apparent to most people at a very early stage that the system date was the least of their problems.

Most systems interact with dates stored on files and databases. These dates potentially can cause far more problems to the working of a program than the system date. Any testing procedure needs to take these dates into account. In order to completely simulate a Year 2000 environment not only must the system date be changed but also all the dates on files and databases must also be representative of the Year 2000.

What has now come into being is the File Aging or Warping software package. The basic functionality of a File Aging package is to allow the user to identify dates within files and databases and then to update the file by changing the dates by a certain amount of time. Typically you could take a copy of a current sales order file, age all relevant dates by ten years and then use the copy as part of a Year 2000 test. In this way you are coming as close as possible to predicting the effects on your systems of executing in the twenty first century.

Lets now look at the various functions that you need to consider when choosing a File Aging package. Obviously the package needs to support directly the majority of your files and databases in terms of access method. Most packages will allow you to unload prior to aging and reload post aging. However, it is the nature of most database reload utilities that they are usually fairly time consuming.

This is not surprising when you consider that they are effectively rebuilding the database complete with all its internal links and pointers. Far better to choose a package which performs direct updates on all your databases and files. To illustrate exactly the sort of performance differences between the direct update method and the unload/age/reload process here are statistics generated by a large well known insurance company:

Size of Database 209 cylinders 943,680 records

PACKAGE ONE (no direct updates)
Unload Time 12 minutes
Aging Time 54 minutes
Reload Time 120 minutes
Total Time 3 hours 5 minutes

PACKAGE TWO (direct updates)
Aging Time 9 minutes
Total Time 9 minutes

In order to define your databases and the dates within them you need an easy to use procedure that ideally needs only to be done once when the product is initially installed. This procedure should take the information automatically from a medium that you already have available such as copybooks or a data dictionary. The package should have the ability to create a copy of the original file rather than update it. This feature is essential for tapes or cartridges. The package needs to be able to process all your dates no matter which format they are in. Obviously it will have direct support for all the common variants of Gregorian and Julian but what about company dates which are derived from the date of the company’s inception? The package will need to be able to process these dates as well. Usually a good and easy to use User Exit facility will handle non standard dates. Not all dates within your file will need to be aged. Birth dates are obvious examples of dates where you may wish the original data to be kept. So the package should not only allow selective aging but also aging by different periods for different dates. Forward and Backward aging should be allowed. The package must allow for holidays and non working days when aging certain dates. For instance shop floor dates held on file will always fall on Monday to Friday. If you age these dates by ten years the package must ensure that the same restriction is also true and adjust the dates accordingly.

Finally, the package needs to be able to age several files and databases as part of the same synchronized run to ensure that all the files/databases in a system are aged in a consistent manner. Having chosen a File Aging package you can then begin to create Year 2000 testing databases.

However, there is one final piece of the jigsaw that you may well need and that is an Aging Comparison tool! Lets imagine that you have taken copies of all your files and Aged the data in to the Year 2000. You can simulate the date and run your systems as if they were executing in the twenty first century with Year 2000 data. In addition you can run a parallel test using today’s file and today’s date. However, how can you ensure that at the end of the process the two files and databases only differ by the dates which have been aged. You need to compare the two sets of files taking into account which dates were aged and by which amount. In effect you would use the same criteria that was used for the initial Aging to perform the Compare.

Obviously you would need to signify date related fields that may be different. Only at this stage can you be reasonably confident of the results of your Year 2000 testing. In conclusion, this article looked briefly at the complete spectrum of the Year 2000 Compliance Process and looked in detail at the important and necessary part a File Aging package can play in this process.

Ian Stewart is a founding partner & the technical director of Domino Software, a software developer for the IBM mainframe market, based in London England. Their DATE/2000 product is sold in the USA through ASPG in Naples, Florida.