This column deals with three subjects: an authoritative book about the Year 2000 problem, an introduction to Windows 98, and the ultimate tool for creating online help systems.
Time Bomb 2000 -- What the Year 2000 Computer Crisis Means to You by Edward Yourdon and Jennifer Yourdon (Prentice Hall, Upper Saddle River NJ, 1998, 442pp, ISBN 0-13-095284, www.phptr.com, $19.95)
Ed Yourdon is a world famous and highly regarded specialist in the design of software systems. His daughter Jennifer is a financial analyst with an investment bank. They have written an informative but widely accessible account of why there will be growing problems over the next year and a half, culminating in widespread difficulties in the weeks and months starting at 12:00:01 am, 1/1/00. These problems are known collectively as "the Y2K problem."
The problem arises from the fact that computer systems store and process large numbers of dates. A simple accounting system must keep track of when each transaction is posted, invoiced, due, and paid. A credit card system needs to keep track of the dates of issue and expiration for each card number in its files. An inventory control system needs to keep track of when each item is stocked and when it must be discarded. Your VCR stores the dates of upcoming programs you want to record.
Because computer systems store large numbers of dates in limited storage space, designers have devised ways to limit the amount of memory space a stored date occupies. One such scheme in widespread use today is to store only the last two digits of the year. Under this scheme, 1998 becomes 98.
I first confronted this problem in 1974, when I worked on a retrieval system for radiology films. Patients supply their name, birth date, and mother's maiden name. The system replies with a list of filing numbers and thumbnail descriptions for that patient's radiology films. A birth date of '77 clearly meant 1877, but what if the system survived until 1980? What would '77 mean then?
We solved this problem by storing the date as a 16-bit binary number, giving us a range of 179 years, which we set arbitrarily to 1850-2029. If the system survives into the next century, we can change the range to a different 179 years, say 1880-2059. Any records with dates of birth in the range 1850-1880 will have to go, but by that time those records will probably be obsolete anyway. Making the change requires a single pass over the database and a change in the contents of one memory location. The memory location is shared by the routines that handle all conversion between internal and external date formats.
Unfortunately, this ant-like concern for the future was the exception. Grasshoppers designed most business computer systems of the 1970s. These systems store dates as character strings, with two digits dedicated to the year. To obtain the actual year they add 1900. It's easy to see when that will stop working. In fact, some older programs use "impossible" dates like 99 and 00 as special codes to convey other information about the associated information.
Worse yet, the grasshoppers make no distinction between internal and external date formats, and they do not encapsulate date handling. Many remote corners of their systems contain instructions and constants that depend on the date representation.
I don't think the retrieval system I worked on is still in operation, and I don't believe it had descendants, so all that foresight was wasted. Many grasshopper systems, on the other hand, survive to this day. In fact, designers used the same techniques through the 1980s and early 1990s. Some may still be doing so.
Work on identifying and solving Y2K problems has been going on seriously in the USA since about 1995. In other parts of the world, awareness of the impending problem has been slow to develop. For example, the following reports appeared in the May 3, 1998 London Times (quoted by Declan McCullagh, www.well.com/~declan/politech):
Last week a source at a north London hospital disclosed that an operation had to be postponed because the computer system told doctors that the swabs needed during the surgery were out of stock. In fact there were plenty available.The confusion occurred because the swabs had a use-by date early in the next millennium. Instead of reading the date as 2001, the computer could recognise only the last two digits and believed the date to be 1901.The Action 2000 survey reveals that National Health Service executives are so worried about the implications that almost two-thirds have drawn up contingency plans for a widescale failure of systems.
I like to think that the USA is further along, but I have heard people say that their credit cards with expiration years of 00 have been rejected by merchants.
The Yourdons don't spend a lot of time on the technical details of the Y2K problem. They conclude that it is already too late to avoid the problem completely. They focus on the possible effects. They point out that even though many people thought about what would happen to their own programs on 1/1/00, few people until recently thought about the consequences of having so many programs fail simultaneously.
The Yourdons don't foresee catastrophic failures of individual software packages, but they believe that small failures will have a ripple effect as they propagate through our communication, transportation, medical, utilities, governmental and other systems. By the time the ripples make the rounds of these thoroughly interdependent systems, they may grow into a tsunami.
So how long will the tsunami's effects last? The Yourdons say two to three days in most cases, a month in a significant number of cases, and a year or more in a few cases. Starting from those assumptions, the book identifies specific steps to prepare for the kinds of disruptions that are likely to occur.
I think the Yourdons take a pessimistic but believable view of what will happen. They don't predict airplanes falling out of the sky, and they don't just say "don't worry, be happy." Their view is somewhere in between.
It's a short book, and it's easy to read. The preparations they suggest are not costly or difficult. I think it's good insurance.
Introducing Microsoft Windows 98 by Russell Borland (Microsoft, Redmond WA, 1997, ISBN 1-57321-630-6, mspress.microsoft.com, 800-MSPRESS, $19.99)
Russell Borland is one of my favorite computer book authors. His books about Word for Windows 2.0 are models of clarity and great sources of in-depth information (Micro Review, Dec 92).
As I write this, Windows 98, barring government action, is about to appear. I have installed and used pre-release versions, and they are impressive. I don't think it's a good idea to review beta software, so I'll defer further comment until I see the shrink-wrapped version.
Borland's book lives up to the promise of his earlier works. It goes systematically through everything you need to know about Windows 98. It reveals the underlying logic and structure.
Windows 98 will be here for a long time. Reading this book now is a good investment in the future.
RoboHELP 5.5 (Blue Sky Software, 1998, www.blue-sky.com, 800-459-2356, $499.00)
I first reviewed RoboHELP (version 2.6) in October 1994, when help authoring systems were a novelty. I have come back to it from time to time. The product has evolved substantially over the intervening years. It once had serious competition, but now it is the clear leader in help authoring tools.
Online help is rapidly becoming the principal medium for procedural and reference support of software users. Most such help uses Microsoft's winhlp format. This format is native to the Microsoft Windows operating systems, but software exists to run winhlp files on other platforms.
Blue Sky implements RoboHELP within the environment of Microsoft Word. This ties RoboHELP to the Windows platform, which limits Blue Sky's potential market share. This becomes less and less a problem as time passes.
Microsoft, as part of its integration of the web and the desktop, is moving to HTML-based online help. Netscape was the first to announce a scheme for HTML-based help, but they have done little with it. Microsoft announced a similar scheme about the same time as Netscape. They have developed and refined the idea considerably, and tailored it to the Windows environment.
Blue Sky has worked hard to support all of these help formats and has even introduced a cross-platform HTML-based help format of its own. The need to support a rapidly evolving field has led Blue Sky to innovate continuously. As a result, some of their releases have been more complete, consistent, and stable than others. Many users continue to use version 4 and have been reluctant to upgrade. Even though version 5 represented a major step forward in RoboHELP's user interface, many users reported problems with it. Version 5.5, on the other hand, strongly resembles version 5 but is a lot more stable.
RoboHELP version 5.5 differs from version 4 in two major ways: it allows generation of different help formats from a single source file, and it provides a suite of productivity tools through a new window called the RoboHELP explorer. As a separate entity the RoboHELP explorer is not as intimately symbiotic with Microsoft Word as RoboHELP itself is.
The RoboHELP explorer provides drag-and-drop management of a project's contents, index, and related topic structures. Current RoboHELP users will love the new way of handling these structures. People who start out using version 5.5 will be astonished if anyone ever tells them the byzantine procedures -- involving unlikely footnote symbols -- that these tasks used to require.
The RoboHELP explorer also provides a graphic navigation scheme that clarifies the relationships among topics. With previous versions it was possible to work with a topic but have no idea how to get to it from within the help system. Now you can see instantly which topics point to it and which topics it points to.
Another improvement in version 5.5 is support for large projects with several developers sharing files and using standard source control packages.
One issue many producers of online help systems face is printed documentation. This was once an advantage for Wextech's Doc-To-Help, a RoboHELP competitor, which offers a single-source approach in which the printed document is the master. Earlier versions of RoboHELP had no corresponding feature. RoboHELP 5.5 makes the online help the master and uses a wizard to produce printed documentation. I think using the online help as a master and generating the printed version from it is the more promising approach. I don't know how well it works in real systems.
If you need to generate online help systems and you have access to a Microsoft Windows operating system running Word 95 or Word 97, RoboHELP is your clear choice for a help authoring tool.
