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

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

 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

Difficulties in finding fixers and organizing the work

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.

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.

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

• 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

5. Testing and implementation

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

 
 
 
 
 
 

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?

Costs add up easily...

... and will not cease in the year 2000

• 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

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

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

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?

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
 
 
 

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

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

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.

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

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

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

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 presented

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.