Disturbing inaction while the millennium bomb
The Asia and Pacific region has been too
slow in getting prepared for the date that many
computer systems cannot handle. The current
financial and economic turmoil could not have
come at a worse time as governments and companies
alike need resources to make their systems year
2000 compliant. Now is the last moment to create
public awareness and start fixing priority systems,
as many of them will fail as early as 1 January
The year 2000 (Y2K) problem is more complex
and potentially more harmful than a first look
would suggest. Fixing it involves not only modifying
the program source codes, but also making changes
to other components such as data files, forms,
screens, file indices, utility programs, packaged
applications, reports, interfaces, operating
systems etc. Its impact extends to embedded
devices, such as in security systems, elevators,
facsimiles, and photocopiers. Many of the affected
programs were written long ago in languages
and for platforms that nobody would use for
new development today. Nevertheless, it is often
cheaper to make them year 2000 compliant than
to replace them, provided of course that qualified
personnel can be found to do the conversion
According to industry reports, Y2K awareness
and progress in addressing the problem have
been sluggish practically everywhere, except
in the United States. Many developing countries
that use IT quite widely have been mentioned
among those that have hardly started addressing
the problem. In Asia, Australia is known to
be the leader, while India, New Zealand and
Singapore are also making good progress. Surprisingly
slow action has been reported in developed regions,
including Japan and Europe. The slow European
response is partly because many countries have
another priority to take care of simultaneously,
namely the transition to a new common currency
(which will eventually affect international
transaction systems all over the world).
In Asia, the current economic turmoil has tended
to focus minds on daily survival, with less
immediate goals being pushed aside. In principle,
the governments have no choice but to fix their
key applications; inaction could seriously disrupt
internal administration, accounting, government
transactions and public services. As the time
to identify and fix problems will run out anyway,
all government offices should engage themselves
in contingency planning in case their key systems
fail. Ignoring the problem will not make it
disappear, but merely lead to escalation of
The facts are simple...
The year 2000 problem,
colloquially known as the Y2K problem,
extends to all technologies that employ
programming such that only two digits
are used for the value of the year. Implications
extend to computer hardware, software,
systems with embedded chips. When the
year 1999 (i.e., 99) changes to 2000 (i.e.,
00), they will fail or produce erratic
The 1999 problem
usually refers to the use of the date 9/9/99
as an expiration date for archived data
that had 'no expiration date', a programming
practice which was popular in the 1980s.
(99/99/99 was also used but that would cause
problems on 1 January 2000). Another critical
day will be 1 January 1999, when
financial and other systems attempt to rollover
to cover a year forward.
The year 2000 day-of-the-week
results from the use of only the last two
digits of the year to calculate the day
of the week. That kind of application claims
that 1 January 2000 will be a Monday, which
was what 1 January 1900 was. (In fact, 1
January 2000 falls on Saturday, which means
that many problems will not be discovered
until Monday, 3 January 2000.)
that may contain faulty date functions
are used, for instance, in the following
It is quite difficult to test, and therefore
to identify and audit embedded systems.
The controllers and microprocessors may
be in units that are no longer manufactured,
or suppliers may not be able to offer updates.
Even when correction is possible, a physical
hardware update (such as a new ROM chip)
may be required. The process cannot be automated
and is likely to require physical inspection
of hardware distributed widely throughout
- telephone and telecommunication
equipment (cars, trains, aeroplanes,
ships) and control systems
- security systems,
- video and audio
- bar code readers
- bank cash machines,
- factory machinery
- process control
and monitoring equipment
- ventilation, heating
and air-conditioning systems
- microwave ovens,
failure It is rather surprising, even
embarrassing, that appreciation of the
year 2000 problem has started gaining
momentum only now, as the first failures
were detected a long time ago. For example,
mortgage companies face d year 2000 problems
as early as 1970 when calculating 30-year
mortgages. Failures have been detected
in credit card expiration dates, and many
other forward-looking situations. While
most of the above failures were fixed
in the course of normal maintenance, it
will be much more difficult to keep up
with the pace of accelerating occurences
as the double-zero year approaches.
misconceptions are common
| Common misunderstandings
|| More appropriate ways
to look at it
2000 problem is a simple technical problem
-- just expand the date fields.
of two-digit year expressions are hidden
deep in software code that is often undocumented
and inaccessible to staff.
|It is only
a mainframe problem.
applications, mainframes, PCs, LANs, operating
systems and commercial and custom-made software
can fail. In addition, applications containing
embedded microprocessors can fail.
|It is a problem
for the IT department to resolve.
responsibility for resolving Y2K problems
lies with the top executive, who has to
initiate an organization-wide alert and
action to address the issue. The IT department
will certainly be assigned a key role in
identifying the problems. However, since
many issues in resolving the problem are
beyond the control of the IT departments,
all departments and their heads must be
are running new software / All our applications
are high that the new mainframe is running
old applications. Checks should be made
that all applications are new or Y2K compliant.
plenty of time.
||Time is running
out. The first big wave of Y2K failures
will come one year before the D-day as systems
rollover to cover a year forward. Therefore,
an acceptable deadline for having the fixes
in place is 1 January 1999. Note that the
acquisition of new software and hardware
takes time, and delivery times will get
longer as the demand increases.
|All our systems
will be replaced by the year 2000.
||Even if there
is a definite schedule to do so, implementation
of new applications, transfer of data to
the new systems, and modification of related
non-computerized processes that are usually
necessary in any migration, often take a
longer time than planned.
invent an automated solution.
solutions do not exist, or exist only for
marginal applications. Nevertheless, some
tools exist to assist in identifying potential
|We will outsource
our entire conversion effort.
of the problem, resource allocation, and
testing of applications will always require
involvement of staff who have developed
or are maintaining and running the systems.
Outsourcing is a recommended addition to
the remedial tool box, but it may be difficult
to find the necessary expertise. Large organizations
have commonly chosen to tackle the problem
Y2K doomsday scenarios -- any truth in them?
The effects of the year 2000 'bug' vary from
minor annoyances to catastrophes that could
ruin businesses or threaten personal security.
Some have predicted that the problem may trigger
a worldwide recession, caused by disruptions
of critical systems, including communications
and electric power systems. Such scenarios are
useful in the sense that they might alert government
departments, and public and private enterprises
to act more swiftly and fix their mission -
Quick examples of year
Interest calculation. A year 2000 compliant
application calculating interest from 20/12/1998
to 19/12/2000 credits the account with 731 days
of interest. However, if the application was
programmed to calculate dates by deducting 20/12/98
from 19/12/00, the chances are that it debits
the account with 35,795 days' worth of interest
(that's what Editor's Lotus 4.01 @DATEVALUE
function gives -- it cannot handle four-digit
years). With an interest rate of 5 per cent
per annum, that particular error would deduct
$4,903 for every $1,000 in the holder's account.
A faulty computation like that in a 'suitable'
place might have a domino effect on other accounts;
it might do irreversible damage to business
operations. At the end of the day, a mistake
of that order would probably be detected and
corrected, but it might take time and be costly
to all parties.
Age calculation. Numerous examples
can be predicted, but the one with by far the
widest implication is calculation of the difference
between the current year and birth year. For
example, a non-compliant system would insist
that someone born in 1925 is -25 (00-25) in
2000. This error could be found for instance
in entitlement systems, such as pensions and
social benefits, and life insurance applications.
Health systems. Millennium revellers
would be wise to celebrate modestly as some
hospitals could face disruptions in their routine
operations, such as patient registering and
billing systems. That may cause chaotic scenes
at medical centres, and even inability to take
proper care of all patients. Medical equipment
might malfunction because of failures in controlling
computers or embedded chips.
Air traffic. Some airlines are
considering grounding flights on 1 January 2000
as part of their contingency plans. Apart from
the aircraft themselves, system failures are
possible in air control and weather forecasting
systems and telecommunications.
Personnel systems are some of the most
affected. Think only about the possibilities
of getting the following wrong: hire date; date
in job; date in department; adjusted service
date; birth date; date next salary review; date
next performance review; benefit enrollment
date; benefit eligibility date; date last record
change; date last salary change; date last physical
exam; family member birth dates; company property
expiration dates; license/certification expiration
dates; earnings date; deductions start date;
deductions end date; leave of absence start;
leave of absence end; termination date; education/membership
dates; skills dates; on-the-job dates, etc.
[list taken from http://www.year2000.com/archive/NFlegal.html]
Scaling the mainframe
The Gartner Group estimates that approximately
80 per cent of the computer code to be fixed
is on large mainframe systems. Contrary to what
one might feel after reading computer magazines,
only a minority of large systems have been modernized
or "downsized" to client-server. At the same
time, the installed mainframe processing power
has continued to increase, and it is estimated
that more than half of the large scale systems
are running on mainframes less than two years
old. However, much of the new stock of mainframes
is running old software, susceptible to year
2000 failures. Moreover, the mainframes seldom
run in isolation, but supply data in great volumes
or provide data processing muscle to PC-based
or client/server systems that provide an easier
presentation layer for the information stored
in the mainframes. "Downsizing" these large
systems is not (any more) a key to year 2000
compliance due to time, skills and resource
constraints. [Source: Testimony of Bruce
H. Hall, GartnerGroup Research Director, Applications
Development Methods and Management, before the
U.S. House of Representatives Science Subcommittee
on Technology and the Subcommittee on Government
Management, Information and Technology, 20 March
20, 1997; http://www.house.gov/science/
Difficulties in finding
fixers and organizing the work
Despite the fact that Y2K doctoring can be
very profitable for those engaged in it, many
computer professionals avoid going into that
business. Most of the work involves dealing
with outdated technologies, which may have a
negative impact on their careers. Their future
bosses are unlikely to appreciate that work
very highly as "the Y2K problem should not have
existed in the first place." Nevertheless, higher
appreciation and prestige might be on the way
after crucial systems fail.
For clients and consultants alike, fixing Y2K
bugs is laborious as patent or automated fixes
do not exist. However, the technical solutions
in each individual case are usually not complicated.
What makes the task challenging is
- finding all locations
where a program might miscalculate or improperly
terminate due to date problems;
- coordinating the modification
of each part of the system so that it does
not interfere with the operations of the overall
- testing the changes with
data that accurately simulate the processing
that will occur in the next decade.
The representative of the Gartner Group compared
Year 2000 planning to an old house that needs
remodeling: "We know it's a big job and we're
trying to figure out how much it will cost and
how long it will take. But, we are trying to predict
the cost of the job while standing on the curb
across the street. If we were able to walk through
the house, our estimate would be more accurate,
and only by getting in and actually doing some
of the work can we realistically tell what we
are up against. And, as usual, the contractor
thinks the job will cost more than the homeowner
thinks it should."
Consequently, he recommended doing the planning
in parallel to the remedial work of the most
critical systems. Apart from saving time, it
would allow the project team to learn the tricks
of the trade and be more efficient in their
subsequent remedial projects.
Practical steps in Y2K problem solving
Rule number one is that no new system
should be acquired without certification of
its Y2K compliance. For existing systems,
the following check list can be used.
1. Make an inventory
of applications and data files
- How many applications
exist in the organization?
- How big and complex are
- Which components are
likely to be affected?
- Identify mission-critical
systems by making an audit of programs that
are frequently used; identify systems without
which the organization could not operate at
an acceptable level.
2. Make a more detailed
- Estimate the magnitude
of the change effort required by
- counting how many
applications and lines of code are affected,
- investigating what
additional components are affected. They
could be, for instance, data, data transfer
modules, control cards, as well as smaller
applications that use downloaded data, hardware,
and inter-organizational systems.
- Categorize each system
according to its year 2000 exposure level
- Some have no exposure
- Some are limited
to cosmetic and run-time exposures (e.g.,
systems whose execution results in dates
appearing on reports).
- Date-sensitive logic
exposures require most attention.
3. Devise a plan and a
schedule to make each mission-critical application
year 2000 compliant.
- Define project stages
and prioritize them. Each application, based
in part on its exposure level, needs to be
evaluated in terms of alternative, but not
mutually exclusive, strategies such as
- replacement, and
- Resolve appropriate composition
of in-house versus outsourced resources
Some of the visible indications of good planning
- appointment of project
managers to be responsible for the overall
coordination of the project;
- contacting vendors and
electronic trading partners to determine what
action they are taking on the problem
- setting a goal to have
an action plan in place within a few months
- establishing a relatively
early goal for project completion (typically
in late 1998); and
- allocating a certain
additional amount of non-discretionary money
over each of the next few years to address
this issue as part of the organization's ongoing
The restructuring option involves replacing
appropriate source code, updating databases
and files, and expanding year fields. The need
for good project management and good change
management is essential.
5. Testing and implementation
All base strategies (restructuring, redevelopment,
replacement, and redeployment) have substantial
testing requirements associated with them to
ensure that new or modified systems function
Source: "Critical issue report: Facing the
year 2000 problem. Leon A. Kappelman and James
J. Cappel. 10 October 1996. http://www-lan.unt.edu/cobabak/www/bcis/
fixing the date
There are three common approaches to
fixing two-digit year expressions:
- In date expansion,
date fields and functions are expanded
to represent the proper context of data,
i.e. four-digit for the year.
- Century indicator
saves space as only single character
is appended to the date fields and interpreted
by specifically added code.
is a technique that allows the maintenance
of two-digit year expressions. In this
method, a hundred-year period around
both sides of year 2000 is interpreted
so that the small numbers, say less
than or equal to 30, represent years
2000-2030, and large numbers represent
For these and a few other techniques, see
for instance http://www.pirkle-websites.com/sc_dcomp.htm.
Progress in the
In mid-August 1997, the U.S. Office of
Management and Budget reported the following
progress in addressing the year 2000 problem.
Of the total 8,562 identified mission
critical systems in government agencies,
- 19 % were already
year 2000 compliant;
- 62% were being
- 13 % were being
- 5 % were being
Although the U.S. statistics are not directly
applicable to Asia and the Pacific, it is
noteworthy that the share of systems retired
or replaced was only 18 per cent, leaving
the large majority of systems to be fixed.
The estimated cost for the government agencies
to fix the problem stood at $3.8 billion.
The latest projections show that at the
current rate of progress, more than half
of the major Federal agencies will fail
to prepare even their mission critical computer
systems before the year 2000 date change.
it be costly?
Yes, it can be costly as financial, administrative,
information and physical transaction systems
run by government departments have many date-dependent
functions. Even entities that have outsourced
all computer services, or are running only new
applications and latest technology, should systematically
review whether their data processing is Y2K
compliant; assurances of vendors and providers
should be backed by concrete evidence. Small
offices with low rates of computerization and
limited dependency on external computer systems
are less affected.
The estimated figures
on aggregate global costs of achieving year 2000
compliance are staggering. According to the Gartner
Group, fixing the year 2000 date problem worldwide
will cost in the range of $300 to $600 billion.
One parameter in the estimate was that it would
cost about $1 for each line of code, excluding
documentation, training, and final implementation
testing. Other estimates vary from one half to
two dollars per line. In any case, should the
funds be allocated at one go from a national budget
to all applications, fixing the Y2K problem would
make a big dent in any government's budget.
Is replacement an option?
Replacement of old applications and equipment
would be an ideal solution. While the lurking
Y2K problem might indeed be a good reason to
invest in new gear, there are at least two major
problems. First, the replacement is often more
costly than making the existing environment
Y2K compliant. That appears to have been the
conclusion of most large companies and organizations.
The second problem relates to the short time
horizon that is left to develop new applications.
The experience is that most major applications
take significantly longer than expected in the
first blueprints to develop and operationalize.
Replacement is, however, a viable alternative
in making personal computers Y2K proof.
Costs add up easily...
As the deadline approaches, the number of available
qualified programmers may become scarce and increase
remedial costs. The cost is not limited to making
internal systems year 2000 compliant as data processing
is increasingly integrated between organizations.
The identification of all date problems, modification
of affected systems and especially testing, which
are needed to bring a large scale system into
date compliance, are time consuming and, therefore,
expensive processes. The process of putting newly
written programs on-line must usually occur during
weekends and holidays when it will cause the least
disruption to normal business operations. Finally,
if things go wrong, the loss of output, revenue,
the trust of staff (when they do not get paid)
and the public-at-large can be significant and
slow to recover.
... and will not cease
in the year 2000
The year 2000 problem will cause continuing
costs well beyond the year 2000. Those expenses
can be categorized as follows:
- Fixing obscure year 2000
instances that were missed prior to the end
of the century;
- Repairing bad fixes that
accidentally introduced new errors;
- Frantically completing
new applications that were intended to replace
ageing legacy software, but which were not
finished prior to the end of the century;
- Hardware upgrades and
retuning of applications whose performance
was degraded by hasty repairs;
- Litigation expenses for
the host of anticipated year 2000 law suits.
The Global Economic Impact of the Year 2000
Software Problem, Version 5.2 January 23, 1997
by Capers Jones, Chairman, Software Productivity
Research, Inc. http://www.spr.com/html/year_2000_problem.htm
(downloadable PDF file)
Testimony of the Honorable Andrew Hove,
Acting Chairman, Federal Deposit Insurance Corporation
before the U.S. House of Representatives Subcommittee
on Financial Services and Technology, Senate
Banking, Housing and Urban Affairs Committee,
30 July 1997. http://www.senate.gov/~banking/97_07hrg/073097/witness/hove.htm
If nothing else, legal implications should alert
Litigation attorneys might not need to
work very hard to obtain compensation for damages
caused by Y2K defects, since the problem is
highly predictable and preventable, giving clients
every reason to believe that problems would
have been rectified at an early stage. The chances
are that it will not be the technical staff
that will be sued, but the top management.
The purpose of this article is not to give
legal advice, but to highlight some judicial
repercussions the Y2K problem might cause in
governments. Our coverage is limited to two
issues, namely the government's liability for
damages caused to third parties, and the possibility
of making computer vendors responsible for fixing
software licensed from them. More insights about
legal issues can be found from the Internet,
including the sources mentioned at the end of
The question of responsibility for damages
will not arise in the majority of cases as most
of the Y2K failures will have limited impact.
However, it is not difficult to imagine a situation
where a government contractor is unable to continue
delivering an expensive infrastructure project
because a government ministry is unable to meet
its part of the contract, because, for instance,
key applications in the ministry's planning
and accounting departments are down too long.
It is unlikely that standard force majeure
clauses could be used to avoid responsibility
since Y2K problems are well known, predictable
and preventable. To avoid accusations of gross
negligence or similar failures that could result
in personal liability or dismissal, executives
would be well advised to document their efforts
in making their organization Y2K compliant.
Apart from government contractors in the private
sector, considerable damage can be caused internally,
leading to rifts within and between departments.
Although those cases might not be resolved in
courts, a culprit search will be inevitable.
That could lead to transfers of top civil servants
and politicians, who at least have the responsibility
for creating general awareness in their departments
and making sure that appropriate action is initiated.
Moreover, the deterioration or disruption of
government services will be felt by the public-at-large,
which may react accordingly.
Another angle on legal issues is to see what
the licence agreements and maintenance contracts
of third-party software say about vendors' responsibility
to guarantee operation of applications in the
future. In normal circumstances, customers expect
to operate their applications beyond the expiry
date of the warranty period. How long is a vendor
responsible for guaranteeing normal operation
of a software application? Depending on individual
licence agreements, national law and its enforcement,
that liability can extend beyond the warranty
period. Common sense dictates that year 2000
compliance does not represent added functionality
or quality of a product, which would allow vendors
to force clients to buy upgraded versions. However,
it remains to be seen whether Y2K failures are
allowed to become a special case in the courts.
In developing countries, two issues make the
position of consumers more difficult than in
developed countries. First, consumer protection
laws are non-existent or deficient. Second,
the use of pirated software is more common,
and can preempt any case against vendors.
Whose head will fall?
Fixing the year 2000 problem, by its nature,
is an issue that few would unreservedly assume
sole responsibility for. The bottom line is
that the decision to use two digits for the
year was made knowingly and has, over several
decades, conserved expensive storage space and
made applications faster. Therefore, internal
culprit hunts would lead to nothing but a delay
in resolution of the problem and additional
expenses. It is estimated that benefits already
gained by two-digit coding far outweigh the
cost of transition to Y2K compliant applications.
Moreover, the cost of not fixing the problem
would be much more than of fixing it.
In the likely event that something goes wrong
in the years 1999 or 2000, it is not only the
chief information officers or heads of data
processing who will feel the heat. Directors
and executives might be blamed for failing to
address the year 2000 problem or for failing
to disclose the financial impact of compliance.
In serious cases, they might be found to have
been grossly negligent in dealing with the year
2000 problem, which could result in personal
liability for them. Another candidate group
for potential litigation are the year 2000 consultants
and solution providers. Other 'risk' groups
include those providing advice in software and
hardware acquisition, for example when preparing
requests for proposals.
In the light of the above issues, government
departments and agencies and their management
might want to make a legal audit a part of their
Jeff Jinnet: Legal issues concerning the
year 2000 "millennium bug" http://www.year2000.com/archive/
Warren S. Reid and Steven Brower: Beyond
awareness: Ten management and ten legal pitfalls
regarding the year 2000 computer problem that
you may not have considered, yet! http://www.year2000.com/
Scenarios for offices in developing countries
Technologically speaking, the solutions
for the Y2K problem are no different from those
offered in developed countries. Computer magazines,
the Internet, respectable vendors, mass media
and other sources offer advice on handling the
problem in various commercial platforms. On
the other hand, custom-made applications must
be tracked for the problem line by line, and
module by module. Managers who are on good terms
with coffer holders may be able to use the approaching
millennium to justify the purchase of Y2K proof
new hardware and software.
A possible scenario
What might happen in an unprepared government
department after its Y2K reaction threshold
is overcome by an external or internal alert?
- The first reaction may
be to downplay the importance of the problem
as it appears so distant and does not comfortably
fall under anybody's responsibility. Later
the denial reaction is replaced by anger,
and attempts to find culprits might be made.
However, that is unproductive as the problem
is global and will not disappear by itself.
- After the denial - anger
stage is over, first attempts to plan the
remedy are made. These might often be simplistic
attempts to replace a few lines of codes in
obvious places, rather than proactive and
systematic investigations. At this stage,
the IT department might be assigned the responsibility
for making an inventory of affected applications.
Ideally, they will do it organization-wide,
but they are more likely to ignore applications
that are not under their responsibility.
- The inventory allows
a first cost estimate to be made for achieving
year 2000 compliance.
- At some point, the management
moves on to review that initial estimate and
will perhaps seek a far more detailed assessment,
since available resources appear insufficient.
- In the above acceptance
and planning process, time is wasted unproductively.
Finally, the management might be ready to
act and allocate priorities to tasks. The
allocation of resources is not simple as the
time the internal staff is using to fix Y2K
bugs is obviously taken away from productive
work. As internal resources prove insufficient,
the department decides to hire external consultants,
but is unable to find anyone soon enough,
or within available budget.
- On 1 January 1999, the
first application fails 'prematurely' and
the rest of the year is spent in getting that
back on-line. More applications fail during
the year and several more in January 2000.
Crucial data from another office stop coming
in as their system failed, too...
But the scenario can
be a more positive one if priority areas are identified,
responsibilities assigned and shared and reasonable
| Some encouragement
on the ability to plan:
|| Since resources
are likely to be the main problem, consider
|A better start can be made
if the core business is focused on. Mission-critical
applications without which operations would
be seriously impaired or damage would be
caused to the organization or its partners
should be listed.
||Important operations may
have to be cancelled or delayed to release
resources to fix the Y2K problem in mission-critical
|Those applications should
then be examined for existence of Y2K problems
in hardware, software, operating systems,
utilities, networks, communication systems
||Taking care of the Y2K problem
will show temporary decrease in productivity,
but is a necessary investment to achieve
higher or acceptable productivity in the
|A technical plan to address
the issues, should be drawn up and to decide
which of the problems can be tackled internally,
and which require external expertise. If
computer services are outsourced, the provider's
plan to become Y2K compliant should be requested.
||Discussions should be held
with managers on which resources can be
released to focus on the Y2K problem, with
potential non-availability of their mission
critical applications made clear.
|A realistic cost plan should
be made; it might include alternative ways
to fill any gap between required and existing
||Few public sector organizations
have all the resources they need; they have
to start with what they have. The case for
transferring resources from other areas
and functions is strong.
|The impact on key operations
of inputs and links to systems controlled
by other organizations should be identified,
and precautions taken.
||Planning meetings should
be held with third parties, and those who
are unlikely to achieve Y2K compliance should
be dealt with consistently.
|Decisions should be made
quickly and iterative processes used, rather
than wasting time in perfecting a plan.
All parties should be informed about progress.
||Accurate estimates require
hands-on experience. Plans should be revised
as experience is gathered.
| In all cases contingency
planning will be needed to cope with possible
for failures in mission-critical applications
The Y2K problem is unique in nature and
presents many unusual management issues.
How government statisticians saw it
|The tenth session of the
Working Group of Statistical Experts was
organized by the secretariat of the Economic
and Social Commission for Asia and the Pacific
(ESCAP) from 11 to 14 November 1997, and
the Y2K problem featured prominently on
the agenda. Twenty-five members and associate
members of ESCAP, several United Nations
bodies and specialized agencies, and a number
of other intergovernmental organizations
had a lively discussion about strategic
issues the Y2K problem posed to national
statistical services. Most participants
were heads of national statistical offices,
many running large systems and employing
a large number of people, often in many
To begin with, the Working Group noted several
reasons why the resolution of the Y2K problem
posed extraordinary challenges for all public
and private organizations, including national
statistical offices (NSOs). Those reasons related
not only to the technology itself, but also
to managerial responsibility, organization and
monitoring of corrective action, human and financial
resources, the availability and cost of external
expertise, and the extent to which the organizations
were dependent on each others' computer systems.
While in several countries of the region the
mass media had provided a wealth of information
on the Y2K problem, the Working Group expressed
concern that the awareness of the problem was
not sufficiently high in most statistical offices.
The Working Group agreed that the preferred
solution to the problem was to retire the non-compliant
hardware and software altogether or replace
them with new systems, but recognized that that
would be expensive and would require careful
planning for the transition. With respect to
hardware acquisitions, the Working Group recommended
that NSOs order their Y2K compliant equipment
well in advance so as to allow sufficient time
for its delivery and the migration of operations
into the new environment. Because of the shortage
of purchase budgets and the short time frame
that was left for the migration of statistical
operations to new environments, many old generation
applications were likely to be still in use
after the turn of the millennium. The fixing
of the 'bug' in the existing system sometimes
involved laborious line-by-line checking of
The Working Group noted that the global trend
of migrating systems from mainframes to personal
computers and client-server environments had
occurred too recently to have phased out all
non-Y2K compliant applications. The Group recognized
that applications created by end-users posed
special problems owing to insufficient documentation
or missing source codes. It was not at all clear
if even those agencies that were fully seized
of the problem would be able to fix the bugs
in all their systems in time, especially when
the program testing often required as much time
as amending the non-compliant codes. The Working
Group observed that in some offices, the information
technology (IT) departments appeared to rely
strongly on suppliers of hardware and software
to come up with solutions to their Y2K problems
and had not considered the issue as urgent.
The Working Group recognized that it was a
managerial challenge to address the Y2K problem
organization-wide. It heard that only the most
advanced NSOs had made organization-wide Y2K
plans and were now implementing them. In those
plans, top management had assigned accountability
for solving the Y2K problem to each department,
which were headed by senior middle managers;
the departments had to report periodically to
a high-level management group on their progress.
At the organization level, a dedicated coordinator
raised awareness of the problem and maintained
inventories and resource bases, including Web
links to Y2K sites on the Internet. The advanced
NSOs relied on in-house solutions rather than
outsourcing the problem solving. The Working
Group was informed that the Australian Bureau
of Statistics, which had 20 million lines of
program code to check, had set up a separate
year 2000 test environment, in which all amended
applications were tested before the respective
departments were given a sign-off for the completion
of the assignments. That procedure was proving
useful, as some applications that were thought
to have been fixed properly had failed.
Although the less advanced statistical offices
might eventually not be in a position to solve
the problem by themselves, the Working Group
felt that the heads of those agencies should
not avoid the responsibility of initiating Y2K
risk analysis and should take action to prevent
lurking catastrophes. That responsibility extended
to the NSOs' non-statistical systems, such as
administrative, personnel, procurement and finance
systems, as well as systems that used embedded
chips with date information. The Working Group
agreed in general that in large organizations,
such as national statistical offices, the IT
departments could not alone be held responsible
for solving the Y2K problem. They did not have
the resources to do so; they also lacked access
to departmental and individual systems. Furthermore,
over-reliance on one department to solve the
whole organization's problems contained a high
risk. Therefore, the Working Group recommended
that less advanced offices should employ multidisciplinary
and team approaches adapted from the models
of more advanced offices.
The Y2K problem was in no way limited to NSOs
themselves; the Working Group agreed that it
had to be addressed in the context of the wider
statistical environment involving data suppliers
and data users. A risk analysis was required
in the NSOs to assess whether their data suppliers
were able to continue providing information
without interruption and in the agreed electronic
format. The Working Group observed that hardware
and software vendors had not been keen to give
legally binding guarantees of their products'
Y2K compliance. Nevertheless, it recommended
that NSOs include a clause to that effect in
their future procurement contracts. It was noted
that some clients of one NSO had requested assurances
on its own Y2K compatibility; that NSO was in
the process of checking legal issues involved
in such written provisions.
The Working Group agreed that in most computer-intensive
organizations it was difficult to estimate how
much work was involved in discovering and fixing
the 'bug' and in testing the computers and applications.
The cost of fixing the year 2000 problem depended
not only on the work-months required but also
on the unit price of the labour, which was already
well above the average cost of new development,
and was very likely to increase as the critical
date approached. The Working Group cautioned
the countries that the longer the problem solving
was deferred, the higher the cost was likely
to be. The Working Group noted the enormous
cost estimates made at national and enterprise
levels in some advanced countries within and
outside the region. In contrast, the cost was
likely to be relatively small in countries which
had only very recently started to develop computerized
systems. Also, any new development in modern
environments was likely to be free of year 2000
problems so long as the user-defined date formats
conformed with the four-digit year expression.
While the accuracy of the high-end cost estimates
could be ascertained only afterwards, the Working
Group felt that those figures were sufficient
to alert those who had not started addressing
The Working Group recommended that NSOs identify
the implications of failure of any of their
systems in order to prioritize which of the
mission-critical applications should be fixed
first. The less important systems could be fixed
when the time and resources allowed. The Working
Group reminded the NSOs that the backing up
of data and program source codes to external
devices, or to independent and reliable backup
centres, was even more important than usual
as the new millennium approached.
Having reviewed the serious technological and
managerial challenges that all countries in
the region were facing within a very short time,
and having compared them to scarce resources
and low awareness, especially in developing
countries, the Working Group requested:
- The secretariat and the
Bureau of the Committee on Statistics to create
awareness through the oncoming Commission
session in April 1998 that the Y2K problem
posed a real, serious and potentially economically
hurting threat to the governments in the region
and that they needed to allocate resources
urgently to tackle the problem.
- The Chairperson, secretariat
and the members of the United Nations Statistical
Commission from the region to raise the issue
in the forthcoming session.
- The secretariat to create
awareness of the Y2K problem in the countries
of the region by compiling and disseminating
information through its publications and web
site; such information should use non-technical
language and be disseminated widely.
- The secretariat and the
NSOs to facilitate the sharing of experiences
in the region, especially from the governments
and NSOs that had tackled the problem with
some success and comprehensiveness.
- The secretariat to approach
the donor on the possibility of including
the Y2K issue on the agenda of the planned
seminar on IT applications, and hold it in
- The secretariat to investigate
if meetings on the Y2K issue could be held
soon outside the standard project funding
- SIAP to investigate if
it could organize a training event in early
1998 on the Y2K issue.
Finally, the Working Group cautioned the NSOs
not to wait for information on other countries'
experiences, since those countries were far from
completing their own solutions.
Selected Y2K references and how to obtain them
Those with access to the World Wide Web of
the Internet need look no further for readings
on the year 2000 problem. Start by pointing
your browser to any of the following URL:s;
all of them contain links to many good documents
and additional information sources. More links
are provided earlier in this issue. A piece
of practical advice: try to progress quickly
to references that are relevant to your hardware,
software, operating systems, networks and area
Year 2000 International Information Directory,
Group of Seven (G7), Government On-Line (GOL)
Year 2000, United States General Services Administration,
Office of Governmentwide Policy (United States)
Year 2000 Information Directory, CIO Council
Subcommittee on Year 2000 & General Services
Administration, Office of Governmentwide Policy
Australian Government's Year 2000 Home Page.
Year 2000 recession? "Prepare for the worst.
Hope for the best." by Dr. Edward Yardeni.
Year 2000 Information Center, de Jager &
Company Limited and the Tenagra Corporation.
Lists Y2K vendors, lots of articles.
ITANZ Year 2000 Page, Information Technology
Association of New Zealand.
UK Computing Services & Software Association,Year
2000 Information Service
How to obtain Web documents
Those who have access only to e-mail can use
e-mail services to obtain any of the above or
other Web pages from the Internet. Send e-mail
to one of Agora Servers
In the body of your note include
>> send <URL>
>> rsend <return-address> <URL>
(to override your return address). Replace
"<URL>" with the actual URL specification.
[Do not include ">>"; here it only denotes a
line to be inserted]
For instance, if you send a message to
>> send http://www.un.org/Depts/escap/
in the body of the message, you should get
back the ESCAP home page, and a list of all
documents referenced within.
There are webmail servers listed below which
run software other than Agora. The GetWeb servers
can handle web pages which contain fill-in forms.
Other webmail servers do not provide this ability.
Address; Syntax; how to get help files of the
GET <URL>; Send HELP or HELP FORMS
GET <URL>; Send HELP for usage info
GET <URL>; Send HELP command for info
Use 'Subject: info' for help
More details about accessing the Web by e-mail
can be found in "Accessing the Internet by E-Mail
FAQ, or Doctor Bob's Guide to Offline Internet
Access; 7th Edition - October 1997; http://www.cis.ohio-state.edu/
faq.html. Dr Bob warns that webmail servers
are sometimes unavailable for days (or weeks)
at a time without explanation, so retries after
a day or so might be needed. To get the latest
edition of Dr Bob's FAQ by e-mail, send a message
in the body: send lis-iis e-access-inet.txt
or to: email@example.com
in the body: send usenet/news.answers/
internet-services/ access-via-email (the path
is one word).
Notice to readers: Updating of the mailing list
Our readers are working for the improvement
of public sector information systems in developing
countries of Asia and the Pacific. They are
middle- and senior-level civil servants and
decision makers in ESCAP member and associate
member Governments, national information technology
policy makers in the public and private sectors,
international civil servants in intergovernmental
agencies, and staff of civil society organizations.
In order to reach our target group better,
we made a call in the previous hard copy issue
for pruning and updating of the mailing list
of the Government Computerization Newsletter.
Many thanks to those who already responded and
confirmed their subsriptions.
If you have access to a World Wide Web browser
in the Internet, you will be able to read the
web version of the Newsletter online at http://www.unescap.org/stat/gc/gcnl/gcnlhome.htm.
As the majority of our readers do not yet have
full Internet access, the primary mode of distribution
will continue to be by mail.
We can accept a limited number of new hard
copy subscriptions. Requests should be communicated
to us in writing, preferably including a short
description of the nature of the addressee organization
or the tasks of the addressee person related
to public sector computerization. Write to the
Government Computerization Newsletter
Statistics Division, ESCAP
United Nations Building
Rajadamnern Nok Avenue
*** Readership survey ***
Government Computerization Newsletter
In order to improve our service, we are conducting
a survey among readers of the Newsletter. We
would appreciate it if you could complete this
form, and mail or fax it to the Editor, Government
Computerization Newsletter, Statistics Division,
ESCAP, United Nations Building, Rajadamnern
Avenue, Bangkok 10200, Thailand; fax 66-2-2881082.
While most questions can be answered by ticking
multiple choices, elaborate feedback on any
aspect that relates to this newsletter, or this
particular issue, are also more than welcome.
Online readers can e-mail to the Editor,
Government Computerization Newsletter
Name and address of respondent:
A. I work in
B. My current position is in
- private sector
- general management
- information technology
- IT technical staff
(analyst, programmer, maintanance)
- Non-IT technical staff
(administration, statistics, government services,
- Education, training,
C. I find the TECHNOLOGY content in this
issue to be
- difficult to understand
- about right for me.
- I expect to find more
detailed information about individual technologies
D. I find the IT MANAGEMENT issues presente
- relevant for me
- irrelevant in my environemnt
- not interesting
E. I find the Government Computerization
- useful -- It contains
information that is useful for me and my organization
- somewhat useful
- not useful -- I find
the same information from elsewhere; it can
F. The frequency of the Government Computerization
Newsletter (twice a year):
- is about right
- should be more frequent
G. I would like to propose the following
issue(s) to be covered in the future:
H. Any other comments?:
Many thanks for your assistance.
Computerization Newsletter is
published twice a year by the Statistics
Division of the Economic and Social Commission
for Asia and the Pacific (ESCAP). It is
not an official publication of ESCAP and
has been issued without formal editing.
Opinions expressed in it do not necessarily
reflect the views of the United Nations.
The designations employed and the presentation
of the material in this publication do
not imply the expression of any opinion
whatsoever on the part of the Secretariat
of the United Nations concerning the legal
status of any country, territory, city
or area, or of its authorities, or concerning
the delimitation of its frontiers or boundaries.
Mention of any firm, licensed process
or product does not imply endorsement
by the United Nations.
News items, articles and viewpoints on
government computerization matters from
readers who wish to contribute to the
Government Computerization Newsletter
are most welcome. The Editor reserves
the right to edit and publish manuscripts
in accordance with the editorial requirements
of this publication. All correspondence
should be addressed to:
Please do share the Newsletter and
its URL with colleagues and associates.
- Mr Ilpo Survo
- Editor, Government
- Statistics Division
- United Nations
- Rajadamnern Avenue
- Bangkok 10200,
- Tel: (66-2) 2881234
- Fax: (66-2) 2881082
- e-mail: firstname.lastname@example.org