For the truly patient ones. The upturn which began thursday in volume and price may have been due to the following...
Financial Planning, Sep, 1997
ELLEN JOVIN
The multibillion-dollar year 2000 problem will affect not only computers, but
also those who invest in companies with outmoded equipment.
The year 2000, or Y2K, problem continues to make inroads in the public
consciousness, with more and more people recognizing the potentially dire
consequences of computers' inability to handle dates after Dec. 31, 1999.
Although the primary area of concern is the mainframes fueling many large
financial services companies, planners should make sure their own hardware
and software are ready for the new millennium. They should also understand
the potential impact of unresolved Y2K issues on profitability and even
solvency of companies in which their clients invest.
The problem's origin lies in the shortage of memory in the computers of the
1960s and '70s. At the time, programmers saved space by devoting two, rather
than four, digits to year fields. Thus, 1967 was truncated to 67, 1943 to 43,
and so on. The 21st century did not exist, as far as the computers were
concerned.
The programmers knew that their code would turn the year 2000 into 00, or
1900, but they did not imagine that their systems would survive into the next
century. However, those legacy systems, as they are called, not only survived
but also thrived, evolving and growing with their companies, and now
represent an enormous investment. 'You're just not going to throw that away,'
says Michael Higgins, president of the Germantown, Md.-based Century Services
Inc., a Y2K 'total solution' provider.
A major portion of the hardware and software currently in existence, legacy
or otherwise, is affected by the millennium bug, as it is often called. If
these systems are not fixed or replaced, date-dependent operations such as
interest calculations, invoices, bill payments, databases that sort by year,
and numerous other functions simply will not work. That is because many
programs calculate time spans by performing calculations on two-digit years.
While date addition isn't a significant problem, subtraction is.
For instance, in 2000, a non-compliant system that is given a birth year of
1939 will subtract 39 from 00 to obtain -39. Rick Bardine, senior systems
product manager at The New England Life Insurance Company in Boston,
explains: 'Suppose you utilize the date field to interpret the age of an
individual to do a projection of retirement needs or a life expectancy
calculation. If the software cannot recognize the century, then you don't
have an accurate way of assuring that you know the current age of your
individual.'
In addition, files that should be ordered sequentially by date may be
sequenced improperly. Suppose you have four files from 1979, 1989, 1996 and
2003. If the century digits are truncated, 2003 will become 03 and
erroneously precede the other three files.
Fortunately, new solutions continue to appear. Software has been developed to
scan mainframe applications and other programs for two-digit dates and to
modify the programs and data.
Still, as Century Services' Higgins points out, 'Most of that software is
appropriate for COBOL programming language, which is the majority of legacy
systems out there. But you also have a lot of other systems that are not
COBOL, for which there are not that many fully automated software tools out
there. It will require a lot more manual work to fix those systems.'
Achieving compliance can take years. Higgins says, 'I know of companies that
spent in excess of a year just to gather their software inventory.' The
conversion and testing phases eat up more years. With less than three years
left, he warns, companies that haven't started the process are in serious
danger of not being Y2K-compliant in time.
Barsa Consulting Group in Purchase, N.Y., offers year 2000 solutions for
AS/400 systems. 'Unfortunately,' says president Al Barsa Jr., 'in the AS/400
marketplace, we don't think most customers are focused on [the Y2K problem]
yet, although the cover of Newsweek a couple of weeks ago probably helped.'
Even so, he says, 'I can't tell you the number of phone calls I'm going to
get the week before, and these are people that will potentially go out of
business.'
The PMA Group, an insurance company in Blue Bell, Pa., does not intend to be
one of them. The company began addressing the problem actively in 1995,
calling in the New York-based Cap Gemini America to assist in their
compliance effort, which is now in progress. The effort involves renovating,
replacing and eliminating systems, but investing in a well-paced solution
buys a company peace of mind on New Year's Eve 1999 - and, of course,
corporate bragging rights.
Companies that procrastinate, on the other hand, can expect escalating
conversion costs, a loss of profitability, or worse. Lawyers are suiting up
for the anticipated proliferation of lawsuits filed by shareholders angry
over inadequate corporate commitment to Y2K solutions.
In any case, companies should be year 2000-compliant before that year
arrives. 'All your applications are different and what we call the time
horizon is different,' Higgins says. 'For example, if I'm a bank and I issue
a two-year bond, I need to calculate the interest over the next two years. I
can do that right now because it's 1997. Come 1998, that same application
will not work or it will give me faulty data.'
The Impact On Independent Planners
The situation for financial planners is not nearly so grave. However, it is
still important to take inventory of your own systems. Ask yourself: What
hardware am I using? What software? Which software is third-party software?
Which was created in-house? What programs involve date-dependent calculations?
Fortunately, for most planners hardware will not be an issue. According to
Higgins, personal computers and workstations purchased in the last year or
year and a half are likely to be Y2K-compliant. Even computers dating back to
1994 may be safe. Nonetheless, the financial planner should check whether
aging PCs are still toiling away somewhere in the office.
Also, warns The New England's Bardine, 'I believe that there have been
circumstances in which Pentiums that are two years old are not year
2000-compliant.' Certainly if you are relying on an old 386, you should test
it. Bardine recommends setting your system date to 2000. If your machine
ceases to function or produces erroneous data, you may want to consider
retiring it or reassigning it to functions that do not involve date
calculations.
As far as operating systems are concerned, Windows 95 or 97 will escort you
safely into the next century. However, Barsa cautions: 'Windows 3.11 will not
make it. Windows 3.11 turns itself into 1980 [when it reaches 2000].' Check
with your vendors if you have any questions at all about Y2K compliance.
Beyond operating systems, there are two categories of software to consider:
third-party and in-house. Third-party vendor software purchased within the
past year is probably safe. However, says Bardine, you should make sure the
software contract states that it is compliant and that you will be protected
if by chance it fails to live up to its promise.
DOS fans may have more serious Y2K-induced problems. Therefore, planners who
are determined to avoid a what-you-see-is-what-you-get environment should at
the very least test their DOS products with post-millennium dates.
The biggest uncertainty, says Bardine, is presented by the systems you have
created in-house. If you have constructed your own Excel or Lotus
spreadsheets, he recommends you examine how you treated the dates. For
instance, if you have a spreadsheet that relies on a birth date to calculate
an age, and then uses the age in calculations of future retirement or
educational needs, you need to make certain that the date has been recorded
in a Y2K-compliant format.
Bardine offers the following test: Change your system date to a date after
December 31, 1999. Then enter a 20th-century birth date such as 5/1/57. How
does your system respond? What age does it return for a retirement
calculation? If it doesn't work, one way to address the problem is simply to
expand the year field to four digits.
Before you begin experimenting with your systems, make sure you back up your
data into a storage system. Even if you determine that testing is
unnecessary, it is especially important to back up as the millennium
approaches. If your files are assaulted by a non-compliant application or
non-compliant data from outside your company or department, you will then be
able to re-create lost or corrupted data.
In this time of electronic vulnerability, you may find yourself appreciating
anew the value of old-fashioned paper records. Jim Woodward, senior vice
president at Cap Gemini America, cautions, 'There is a strong possibility
that banks and mutual funds and other financial institutions will not finish
all of the systems that they need to fix in time, in which case they may have
inaccurate financial records for their customers.' |
