Y2K - The cost-effective solution to tackling "The Millennium bug"
To this end, though, the necessity of making this change is open to debate. The likelihood of any application failing to process dates correctly because only 2 digits are displayed is actually extremely small, as programs usually store and process date values in a different format behind-the-scenes such as "days-since-1900" or "yyyymmdd".
Y2K does actually check this within the Windows date settings & offers to correct it, but to be perfectly honest we built in this option as an extra "frill" because it was easily implemented and most of the other compliance-test utilities also provide it, rather than because of any great practical value.
What are the command-line options, and how can I use them ?
Y2K supports a number of command-line options which influence it's behaviour. These are:
4 for the Windows date
8 for the O/S clock
16 for BIOS Leap-year recognition
32 for BIOS rollover
A return value of 36, for example, would mean that both the BIOS and Windows date tests failed.
How will Y2K affect my Novell Netware workstation ?
On DOS-based workstations the Novell LOGIN program normally synchronises the date & time with the currently-connected file server, which means that the effects of Y2K.EXE will immediately be reversed if the date on the server has not been corrected - the workstation will be set back to 1980 again. Worse still, even if you're using brand new machines with a millennium-compliant BIOS that don't need Y2K.EXE installed, these may also be affected if you're using an older server. However, Windows 95 workstations that use the built-in Netware client (rather than Novell's own 32-bit client) do not automatically synchronise date & time with the server, so they will benefit from the installation of this utility. Whatever O/S you're using on the workstations, the date on the server can be corrected by running the FCONSOLE supervisor utility & selecting the "Status" option.
Which clocks does Y2K test - a technical explanation
There has been some confusion over how many clocks "exist" in a PC due to the way in which they're accessed through software.
The first, which exists all the time (assuming the battery is not dead) is the BIOS clock. This is stored in the CMOS non-volatile RAM, which is maintained by the power from the battery. The CMOS is just a small area of memory which holds a variety of very important information about the PC, such as what sort of hard & floppy disk drives are attached to it. You can look at the value of the BIOS clock by going into the BIOS setup utility (usually by pressing DEL) when the machine fires up. Because accessing and updating the CMOS is only ever done by BIOS routines (as motherboard configurations vary), the terms BIOS and CMOS are always closely linked.
From a programming perspective, the clock value maintained in CMOS memory can be accessed in two ways. The easiest and most common method is to use what are called Interrupt calls to the BIOS. However, the value of the bytes in the CMOS memory can also be interrogated directly using what are called I/O ports, albeit in a rather more long-winded manner, and this manner has also changed occasionally over the years (such as when IBM introduced the PS/2). No-one would normally bother with this second technique, as the guys who wrote the BIOS routines in the first place have already done all the hard work so a programmer would just use the BIOS routines instead. But from the point of view of someone who doesn't realise they're exactly the same thing, this could be seen as two separate clocks, which is why the apparent distinction is made.
The "Real Time Clock" is exactly the same thing, just another name for it. The reason this term is used is to distinguish it from the processor's own internal "clock" which regulates sending of digital signals between the various peripherals inside the machine. It's just a term that a non-techie picked up on and has managed to get into circulation.
The other genuinely distinct clock in a PC is the one maintained by the Operating System. The O/S clock is "created" and initialised to the current value of the BIOS clock whenever the machine is switched on or the O/S is reset (but thereafter it's updated and maintained by the O/S) so it's ability to correctly process the century rollover is only relevant if the PC is to be left switched on over the crucial night. Anyway, from the results of the tests we have conducted, the clock in DOS version 3.20 was apparently afflicted in the same manner as some BIOSes but it's very unlikely that this is still in use anywhere (it can only cope with 640K of RAM and 32Mb hard disks).
The BIOS clock passed, but the O/S did not. What do I do?
Y2K does not try to correct the problem in the O/S, but this probably will not affect you anyway. You only need to be concerned if you normally leave your PC switched on overnight, running automated processes. If it is off over the New Year, the O/S clock will be set from the BIOS clock next time you switch on so the O/S rollover will never happen & you are in the clear.
Any other questions
If you have a more complicated problem, please mail it to email@example.com.
Click here to return to the Y2K home page.