• attempts to create awareness about the year 2000 problem,
• clarify common misconceptions, and present practical steps to achieving Y2K compliance.
• Among the threatening and positive scenarios,
• legal and economic issues are also featured.
• You can also read what chief statisticians thought about the problem recently in Bangkok. Alarmed by lack of awareness and action in the region, they recommended that the ESCAP Commission discuss the Y2K problem at its forthcoming session in April 1998.
• You are invited to fill out a readership survey at the end of the document.
• For hard copy readers, the issue contained a request to update subscriptions.

Disturbing inaction while the millennium bomb keeps ticking

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 1999.

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 work.

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 costs.

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 results.  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 problem 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.)

Embedded chips that may contain faulty date functions are used, for instance, in the following equipment: telephone and telecommunication systems transportation equipment (cars, trains, aeroplanes, ships) and control systems security systems, locks video and audio equipment bar code readers bank cash machines, credit cards lifts factory machinery process control and monitoring equipment ventilation, heating and air-conditioning systems microwave ovens, etc. 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 the organization.

Time horizon 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.

...but misconceptions are common

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 - critical operations

Quick examples of year 2000 failures

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 problem

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/ hall_3-20.html].

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 system; and
• 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 they?
• 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 impact analysis

• Estimate the magnitude of the change effort required by
• counting how many applications and lines of code are affected, and
• 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
• restructuring,
• redevelopment,
• redeployment,
• replacement, and
• retirement.
• Resolve appropriate composition of in-house versus outsourced resources

Some of the visible indications of good planning include

• 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 maintenance programme.

4. Conversion

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 correctly.

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/ faculty/kappelma/critical.htm.

Techniques in 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. Windowing 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 years 1931-1999. For these and a few other techniques, see for instance http://www.pirkle-websites.com/sc_dcomp.htm.

Progress in the US Government 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 repaired; 13 % were being replaced; and 5 % were being retired. 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. Source: http://cio.fed.gov/y2krp897.htm

Will 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.

Sources:

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 government executives

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 article.

Government's liability

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.

Vendors' liability

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 Y2K inventory.

Sources:

Jeff Jinnet: Legal issues concerning the year 2000 "millennium bug" http://www.year2000.com/archive/ NFlegalissues.html

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/ archive/NFbeyond.html

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 resources allocated:

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 separate locations.

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 long programs.

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 problem.

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 early 1998.
• The secretariat to investigate if meetings on the Y2K issue could be held soon outside the standard project funding cycle.
• 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 of business.

http://www.itpolicy.gsa.gov/mks/yr2000/ g7yr2000.htm

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)

http://www.itpolicy.gsa.gov/mks/yr2000/ y201toc1.htm

Year 2000 Information Directory, CIO Council Subcommittee on Year 2000 & General Services Administration, Office of Governmentwide Policy (United States)

http://www.y2k.gov.au/

Australian Government's Year 2000 Home Page.

http://www.yardeni.com/y2kbook.html

Year 2000 recession? "Prepare for the worst. Hope for the best." by Dr. Edward Yardeni.

http://www.year2000.com

Year 2000 Information Center, de Jager & Company Limited and the Tenagra Corporation.

Lists Y2K vendors, lots of articles.

http://www.itanz.org.nz/year2000/main_pages/ year2000.html

ITANZ Year 2000 Page, Information Technology Association of New Zealand.

http://www.cssa.co.uk/cssa/new/millen.htm

UK Computing Services & Software Association,Year 2000 Information Service

How to obtain Web documents by e-mail

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

>> agora@dna.affrc.go.jp

 >> agora@kamakura.mss.co.jp

 >> agora@www.eng.dmu.ac.uk

 In the body of your note include

 >> send <URL>

 or

 >> 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

 >> agora@dna.affrc.go.jp

 with

>> 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 service

>> getweb@usa.healthnet.org; GET <URL>; Send HELP or HELP FORMS

>> getweb@unganisha.idrc.ca; GET <URL>; Send HELP for usage info

>> w3mail@gmd.de; GET <URL>; Send HELP command for info

>> wwwfmail@linux.netmor.com; Use 'Subject: info' for help

>> webmail@www.ucc.ie; GO <URL>

>> web-mail@ebay.com; <URL>

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/ hypertext/faq/usenet /internet-services/access-via-email/ 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

 to: mailbase@mailbase.ac.uk,

in the body: send lis-iis e-access-inet.txt

or to: mail-server@rtfm.mit.edu

 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 continues

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 |

Editor, Government Computerization Newsletter
Statistics Division, ESCAP
United Nations Building
Rajadamnern Nok Avenue
Bangkok 10200 THAILAND

*** Readership survey ***

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

1. government
2. private sector
3. other

1. general management
2. information technology (IT) management
3. IT technical staff (analyst, programmer, maintanance)
4. Non-IT technical staff (administration, statistics, government services, etc.)
5. Education, training, research
6. Other:

C. I find the TECHNOLOGY content in this issue to be

1. difficult to understand
2. about right for me.
3. I expect to find more detailed information about individual technologies

D. I find the IT MANAGEMENT issues presente

1. relevant for me
2. irrelevant in my environemnt
3. interesting
4. not interesting

E. I find the Government Computerization Newsletter

1. useful -- It contains information that is useful for me and my organization
2. somewhat useful
3. not useful -- I find the same information from elsewhere; it can be discontinued.

F. The frequency of the Government Computerization Newsletter (twice a year):

1. is about right
2. 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. 

The Government 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:  Mr Ilpo Survo Editor, Government Computerization Newsletter Statistics Division ESCAP United Nations Building Rajadamnern Avenue Bangkok 10200, Thailand Tel: (66-2) 2881234 Fax: (66-2) 2881082 e-mail: survo.unescap@un.org URL:  http://www.unescap.org/stat/gc/gcnl/gcnlhome.asp http://www.unescap.org/stat/ Please do share the Newsletter and its URL with colleagues and associates.