Y2K.HTM  -- 19980527 -- Information on Year 2000 Issues

Feel free to add or edit this document and then email it back to faq@jelyon.com

Novell Specific information on Year 2000 Issues

For information on Novell's Year 2000 effort, known as "Project 2000," is available at the following url:  http://www.novell.com/p2000/   (jel)

You can also find Year 2000 information on specific Novell products by searching the Knowledge base (http://support.novell.com)   for "Year 2000". (jel)

General Comments on Year 2000 Issues by Arthur B.

Date sent: Thu, 21 May 1998 23:50:14 +0200
From: "Arthur B." arthur-b@ZEELANDNET.NL
Subject: Re: Y2K Workstation Testing

Richard Letts wrote:

>
> ARGH!!!!!
> can someone please write something for the FAQ on this topic so we
> can just redirect people to it. I'm sick of Y2000 questions and
> people looking for magic bullets. there isn't one.
>
> Richard

Good idea.

Here are some ideas...

  1. Nothing is Y2K compliant until proven otherwise.
  2. Y2K can be in anything that works on electricity.
  3. Details count. Right down to the revision level of the RTC.
  4. Determine critical (parts of) systems and test them yourself.
  5. Test critical systems in whole. As they are. Do *not* test components seperately! Be sure you can recover from scratch before testing.
  6. Have alternatives ready and tested for critical systems.
  7. An Y2K compliant memo alone isn't an insurance. Ask for detailed test reports.
  8. Don't forget about in-house (macro's, reports), spare parts and import/export and diagnostic/repair/restore tools.
  9. Stop buying things that aren't Y2K compliant.
  10. Talk to companies yours is dependant on.
  11. Create a paper administration to keep track of progress.
  12. There's also this "Euro" problem starting Jan 1, 1999...
  13. Is your budget for 1999 Y2K compliant? Is it big enough?

Don't think that you can prevent all problems. In the best event you can reduce problems with 99.99%. And since time is of the issue you need to make priorities. Handle the most critical parts the company as a whole is dependant on first. Don't do that alone though. You only have expertise in a few areas (IT for one) at most.  The Y2K problem isn't over after Jan 2, 2000. Expect problems for months after. IOW sit on backup tapes longer before re-using them for starters.

The Y2K problem doesn't start on Dec 31, 1999. It's already started.

Think of long-term calculations for example. Or simple things like "best used before...". And there are those endcodes (99/99/99 for example).

Don't solve Y2K within your own departmant alone. Help others if you can. Don't keep information for yourself or think "that's not my problem".

As an example: think about what's involved to enable you to receive your salary. Isn't it amazing how much needs to be working correctly before you get your salary? It's not computers and software alone... And it involves more then just you, your department or even your entire company.

Also. Solving Y2K requires huge amounts of manhours. Because it needs to be done hugely by hand. Unless someone can make a software tool that tests every server, every PC's, every embedded system, every RTC, every bootdisk, every peace of software in-house or bought and all the functionality it *can* have (what you don't use now you may need later), all repair/restore and diagnostic tools, every spare part, every (future ) upgrade and patch, all spares including the ones outsiders bring in (support contracts), all printers, all forms, etc.

If you miss the manhours needed to tackle this hire someone before prices go skyhigh. Holland alone is recruiting and training around 50000 extra people to tackle Y2K in time. What you don't want is number 50001 to solve your Y2K problem and you wont believe his/her salary demands by that time.

For example: a company with stucked elevators, failing alarm systems, UPS, keycard systems, telephones, faxes or atomic clock is bound to have some problems. For all you know your highly electronic car may even refuse to start... Or did you proof otherwise?

Don't wait for Y2K compliant forever. If a manufacturer fails to convince you before mid 1999 replace the part. Because waiting any longer then is a risk and new things take time to integrate and settle down.

A company is dependant on more then just computers and software. A company can't solve everything. But if it's aware of possible problems it can at least take precautions. Or accept the risk instead of blaming someone. Not that all companies await disaster. It just that companies don't know without testing if they are awaiting disaster.

There's more. I could write a book or two about this.

Still, Y2K isn't the end of world. It may even be an oppurtunity to do things right for once. Common sense helps best. Hear everybody out and then proceed how you see fit. Be sure that vital parts of your company keep on functioning. What you learn from that you can then use on the rest of the company.

Keep in between overreacting and underestimating Y2K and make time and budget space for it.

Arthur B. arthur-b@zeelandnet.nl
http://people.zeelandnet.nl/arthur-b/index.htm