|
by Steve Broadhead
Ask most people what they associate with the year 2000 and
the answer will be "let’s party".
However - pose the same question to an IT manager and partying will probably be the last
thing on their mind. Not since the outset of the infamous computer virus threat has the
computing world been gripped with a fear of the unknown. Like the computer virus problem,
the initial thought is that of: "is there really an issue here, or is it all
over-hyped nonsense to enable specialists to make a lot of money out of fixing
nothing?" Martin Hewitt, managing director of network solutions provider Jaguar
Communications, whose marketing newsletter is appropriately titled "towards
2000", is witnessing this fear and concern shown by his customers at first hand.
"We’re getting a lot of letters from central IT departments who are panic
stricken about what effect the year 2000 will have on systems supplied by us. We’re
having to write formal declarations to our customers to confirm to them that the
networking systems we’re selling them will not create problems in the year
2000," said Hewitt.
However, he feels that the most important point to spell out is that any problems are not
going to be related to networking equipment.
"We’ve discussed it with all the manufacturers, and internally, and we
can’t see where there will be any problems. After all, the average working life of a
piece of networking hardware is about four years, so many products installed pre-1995 will
not even be around in 2000", Hewitt explained.
The important point here is that problems inherent in computer systems come the millennium
are not related to networking and communications hardware which typically has an internal
time and date stamp which will not be affected by the move towards the next century.
Yes, the problems are obviously time and date related, but not with respect to the
"clocks" within your average bridge or router, let alone a PC or modern UNIX
host computer. So where exactly are the problem areas likely to be and how can we stop
them creating havoc in three years time? After all, with so many documented cases of major
banking and finance companies putting aside hundreds of thousands of pounds to budget for
necessary changes, there must be potential problems out there, waiting to trip up
unsuspecting IT departments. And the last thing anyone can afford to do is wait until
January 1st 2000, to see what happens then. Action - where necessary - needs to be taken
as soon as possible. But what action exactly?
If the problem doesn’t lie with the networking and communications hardware, it is
natural to assume it therefore lies with the applications running on the hardware. But not
the kind of shrink-wrapped Microsoft or Lotus badged PC applications; these should be
future proofed, having been largely developed in the past 10 years. The same applies to
the kind of applications running on PC LAN servers; Novell and IBM LAN Server based
systems, for example. No, the chances are that the problems lie with much older
applications running on mainframe and other host systems. These may be applications
running on systems which have been largely unchanged - hardware and software wise - for
many, many years. Equally however, the reason they may have been left unchanged is because
of the enormous cost and difficulties involved in migrating them to a more modern
computing platform. Systems for applications such as payroll and personnel are classic
examples of this genre; hardly non-critical systems, hence the "if it isn’t
broke, don’t fix it" approach to maintaining old applications of this type. And
herein lies the first obvious problem in trying to track down potential problem areas.
Most of the staff, be they programmers, analysts, support staff, or managers, who
developed those systems, have probably long since left the company. Likewise, the
suppliers of the hardware and software used to develop those systems may also be long
gone, including the companies themselves. So in many cases, the first point of reference
is probably not there to refer to!
The next most obvious reference point - program documentation - is also a debatable
strategy to follow. First and foremost, programmers are infamous for not documenting their
programs - especially in the days of assembler and machine code development - and even
where they have, that documentation may not be that meaningful to IT staff at the company
now. So if a search through application program documentation produces no clues, what
then? The answer is to manually look through every function, procedure and parameter of
every old (for example, anything developed 10 years ago or more) application for date and
time routines, and run checks against them to see what happens once the year 2000 is
reached. Is this going to be easy?
Of course not. It requires staff with the right programming language skills and lots of
time on their hands. Hence, the number of consultants and contractors offering to carry
out this kind of problem solving on your behalf, while commanding suitably high hourly
rates of pay! Is there any other approach in this case?
While effectively discounting hardware as a source of "year 2000" problems, this
is not necessarily the case with - again - respect to old proprietary host systems. A
major problem in trying to provide a set of rules for identifying year 2000 problem areas,
is that no two company’s computer networks or systems are the same. Even where
companies bought the same base system at around the same time, these will have been
enhanced and changed over the years in different ways. It is therefore not possible to
say, carte blanche, that a given type of system, dating back to a specific time and date,
will need changes. While software now rules OK, in the past, hard coding - either through
firmware or directly in the system hardware - was more commonplace. The answer here is to
know the exact versions and revisions of all elements of your old systems and contact the
manufacturers for initial advice. The same applies to operating system and application -
database, for example - providers.
And what if they no longer exist? Then it’s a warm - if expensive - welcome to those
specialist trouble-shooters…
|
|
