1996 January 1st - December 31st Toronto and environs - Home & Away: NEEDS TEXT, NEEDS CAPTIONS

Dateline: 1996 December 31st Toronto, Ontario

This trips travelling map 

Just another year, Family, friends etc

January - December 1996

Columns by your correspondent. First Published February 28th 1996. Computer World Canada:

Published Computing Canada. 1996 February 28th.

Toronto, Ontario

Ah, those were the days. The kids thought (or wanted you to believe) that you were great

First Published February 1996. Computer World Canada:

Year 2000: Fight or Flee II

In my last article, I discussed how the technological implications of January 1st. 2000 could mean meltdown for companies using ANY data processing system not designed and coded adequately, whether of primeval origin, or up to date technological pedigree. In this column, I will outline a path of possible salvation.

Year 2000: The impending Meltdown Fact or Fancy?

Several years ago, I worked in the Middle East. Programming in Saudi Arabia does not require the same level of navel gazing (just as well really) which the Gregorian Calendar (a mere figment of a religious perspective) entails. Currently, the year in Saudi Arabia is 1417 and as I recall, little effort went into adjusting for changes in centuries. Israel at the other end of the spectrum at 5756, still has many years to go before any serious investigation is required.

Anyone who has been involved in designing, writing and maintaining data processing systems, knows full well that not only are systems rarely completely stable, but turbulence of a system in most corporations, let alone dynamic ones, is the rule rather than the exception.

Typically, business rules "exceptions" of how a company operates murkup the original system concept. "Didn't I tell you about...... " is the bane of designers. New requirements are always coming along to chafe and twist entrails as to the total incapacity of the current system design to handle the latest requirements of sales and marketing. A data processing system is in fact, only "stable" three months after the last coding has been attempted! This scenario is not however a normal occurrence. Indeed, talk to any systems manager about the day to day operational requirements of any system, be it large, mid sized, "heritage", mainframe, mid-frame or any other, any you will find (if you're not already aware of it) that gut wrenching changes are an INTEGRAL part of any operations mangers environment. The fact is, processing systems are a dynamic entity in their own right.

Now the good news

Given that change is a perpetual, the advantage of the impending need for change relating to the next millennium (if it really does exists), is that it has been foreseen, and the implications can be shown to be a definite reason for concern.

Once again, the only reason why this could suddenly create data anarchy come January 2000, is that even to assess if there is a problem, requires the same nemesis of D.P. managers of the 90's: Time and Budget. Without these, the (possible) time bomb will tick away (sotto voce) behind the day to day panics and fire fighting.

It is also still a "long way off"; in the next 4 years, there are resumes to write, directorships to attain, careers to be re mapped etc: you get the picture.

Strong nerves, budget, or promotion?

Prior to any systems testing, it is essential to realise that the system date is a significant detail which may conspire to kill any system. Programmers and system internals, typically grab this to time stamp information for audits etc. To adjust the clock by several years on your production system, is not something to be taken lightly. This will be the mainspring of testing: whether you need to adjust your data processing system in a production environment requires strong nerves and a clear head. In large systems, changing the system clock can have other undefined consequences. (Kids, do not try this at the office)

To check whether a production system will work in 4 years time, requires that the machine date is set to the next millennium, and data for the years 99 and 00 are entered as regular data with the time stamps for these dates. The simplest way of assessing if your system has a problem is to generate a test environment, and test it out under pretty demanding criteria ie duplicate the details expected in a production environment.

There are three ways to do this: The first two will need raw data: production data can be copied and turned into details for the turn of the century this can be done by simply copying data for December "95" and January "96" say with the all the years changed to "99 and "00". Simply by mapping the date formats in data, you will gain valuable insight into the system architecture.

If you are of the strong nerves persuasion, then the first approach may be for you. In addition to strong nerves, a long weekend and verified backups would be considered essential equipment.

Option One

Using this approach, the test system is loaded onto the same processors and drives which house the main production system. Once loaded into a separate controlled area of the system, the main system is shut down, the new environment is brought up and the system clock set to January 31st. 2000. (See above: E&OE). In the time remaining before production resumes, you may delve into the resulting alignments, assess the system, and reset your environment for normal production.

Option Two

If you are not trained in the disciplines of nerves of steel, (dammit Jim, I'm a programmer, not a doctor!), you may wish to encourage an additional line on your next budget:

Once you have budget approval, the first thing to do is to locate a similar system to the one used in production; do you have a disaster contingency system being paid for at this very instant? If not, find one: there is a secondary market for old equipment that can be purchased by the kilogram. Purchase a low end model of what you are currently using that will run your system, load data as above and tell it the system time is now January 31st. 2000 and enjoy at your leisure.

This second approach appeals to me as it enables the manager to decide what if anything needs to be done on the production system(s), and to instigate these changes into production gradually. It's also politically correct because you can ask everyone to approve it. After all, how many people are going to come into the office on a weekend to worry about something that may happen in 4 years time? That description may also include you of course, in which case you need option#3:

Option Three

The third option is simply to get promoted and let someone else carry the can for this research: this approach has the advantage that it is tried and tested, and also conforms to ISO 9001.

Columns by your correspondent. First Published February 14th 1996. Computer World Canada:

 1996, February 14th. Toronto, Ontario

Way back when Y2K was just a glint in my bank managers eye

Don't think I wangled any gigs specifically from this one, but fun to write, and boy, did I ever make a killing in 1999! Ha Ha!

Never loose sight of the fact that you are only working to give your family the best (I did)

First Published February 1996. Computer World Canada:

The Year 2000: An issue of technology or ego?

The idea that moving into a year which has a number followed by 3 zeros, has struck various amounts of awe, fear, born againism and whathaveyou into various facets, categories and strata of societies since the late 900's. Hopefully, the outlook of the late 1900's is somewhat different to the outlook from the mid 900's.

My own predictions for the impending turn of the century, is that few (if any) virgins will be sacrificed, few (if any) elements of the upper echelons of the food chain will have their entrails read, and any company using outdated or poorly designed software, COULD become ancient history shortly thereafter, unless time and budget is reserved for investigating the impending technological solstice.

It is a well known fact that good news does not sell as readily as bad news. So let me put some bad news perspective into this foray:

Historically, when data storage and computing cycles cost lots of money, every imaginable artifice was employed to contract the amount of space required for data. We all still live with the MS-DOS constraint of 8.3 characters - I seem to remember the last 3 bytes were with exceptional technical wizardry, made to occupy 1.5 bytes somehow. The reasoning for this was akin to the reasoning of 640KB for MS-DOS memory constraints, (who would ever need more than 640KB of memory etc!). This approach pervaded computing circles until the 80's. BASIC, COBOL, assemblers etc., were all of the bent that 2000 was too far away to be concerned about, and the designers (back in the 50's) would not be around to be sued then anyway!

Modern languages (typically 4GL's and languages developed since the late 70's), have been written by people with larger egos': developers expected their work to outlast them. Consequently, these updated products do not have INHERENT incapacity hidden away inside there entrails. Unfortunately the converse is also true: newer products do not necessarily have an INHERENTLY correct capacity for avoiding the change simply because the technology is current. Life is not that simple.

Concentrates the mind

This INFERENCE is of course the meat and potatoes of what all the fuss is about.

Ask 100 programmers to write a run of the mill order entry sub system, and without doubt, you will eventually get 200 or more sub systems (any programmer worth any salt will never be content with a first pass at anything). The issue here is NOT that the system compiling engine is in any way lacking, it is that the analysts and programmers may overlook certain aspects of performance. The bare fact that dates are stored as YY/MM/DD does not necessarily mean that the system will give up to the grim reaper of 1999 and be consumed into the residue of systems past. NOR does it mean that "modern" systems are immune to these hazards.

The straight truth is that if the system is designed with the philosophic constraint of requiring the 4 digits of the year into the code, then there will (probably) be no significant melt down. Two (or three) digits will not cut the potential millennial impasse. This of course must be taken in the context of E&OE*

For example, all those years ago when I began to actually sell my designing and coding capacity as a BASIC programmer (and of course having an insufferably large ego), all systems had date details stored as integer fields of YYYYMMDD. Similarly, time was stored as HHMM on a 24 hour clock. To ensure that the most recent events were displayed on top of the scan, the YYYYMMDDHHMM field was inverted, simply by subtracting it from 999999999999. This was then used as a significant part of the indexes. Not exactly sophisticated, but very effective, and has worked very successful. The point being that even with a prehistoric BASIC system, avoiding the much feared black hole of the next millennium, WAS possible; even with minimal resources.

Working with 4GL's for 6 years has also enabled me to see similar (if opposite) possibilities with new processing languages. Unfortunately, exactly the same problems are possible under these "safe" languages, once again if the full implications are not allowed for, a user can enter 2 digits for a year, and unless there is a century default, then the year 1996 will be entered, saved and indexed as the year 96; does this sound familiar?

The problem then would appear not to be one of technology or lack of it, but more of one relating to analysis, design and coding. The buck finally stops, where it belongs: at the application and its creators, NOT because the "best by" date has passed on older technology.

We have now established that bad news exists, and this magazine will thus sell out and need reprints.

My next article will outline how companies can address these issues and achieve a trial balance on January 31st. 2000 (E&OE of course).

* E&OE = Errors and Omissions Excepted: LawSpeak for "If I'm wrong it's still your problem, not mine".