#====================================================================
# some thoughts on what to think about as you think about your 
# contingency plan, and what to put in it and what not to put in
# and how to build your computing & information resources for valid
# alternatives in the event that your planning & testing & your 
# vendor's assurances that their items are "compliant" turns out
# to be ALL WRONG --- 
#=================================================================
#
# as of: Fri Apr 16 06:01:30 UTC 1999
#
These are some thoughts in no particular order - highlighting items
that I have seen in several plans & draft plans both inside and out-
side of Motorola & Motorola GSD...



1.) if you have this phrase:

       "It has been tested and it had no Y2k issues"

is redundant and needs not be included in a "Contingency Plan"
it has nothing to do with "Contingency" -

  the whole basis of the Contingency plan is:

    If it had been "adquately" tested then you wouldn't be engaged in
    implementing a contingency plan, because if it had been "adequately" 
    tested - it would have failed under testing, not when the Year2000 
    actually turns over, and it failed "against all possible odds".

So - please remove any reference to testing, and write a plan that
includes wording and "action items" about what you will do WHEN
 it fails, not try to tell the reader of the plan it is not going to fail.


2.) Some have items listed, generically as, "move the application
to another server", but the whole basis of the underlying principle
to the contingency plan is that the server and/or the application
has failed.

Please understand that if you have a bunch of FrameMaker files and
FrameMaker fails to function in the Year2000, then moving the FrameMaker
application to another server achieives nothing - since FrameMaker
will likely fail on the other server. (on the other hand - maybe not?)
Maybe Frame on one platform (Sparc-Solaris) would fail, but on Sparc-
Linux it would work? _ who knows...

Remember - also - that if you move the application to another platform
for instance Frame from NT to Solaris (or vice-versa) what happens
to your data files in User's home directories, if you're moving
those from platform "a" to platform "b"... is a dual-platform 
backup one methodology to build some contingency into your Year2000
strategy?

3.) Hardware/OS failure:

NOW _ if it's a Solaris 2.61 on Sparc hardware that fails
and you have all your home directories on that platform
then moving your hard disk to another Sparc computer running
Solaris 2.61 is not going to do you a lot of good, is it?

AND - those Solaris 2.61 backup tapes will be worth what,
if Solaris 2.61 / Sparc proves to fail?


4.) File storage formats:

So - the alternative here - is to have key files backed-up on several
different sorts of media, and in several different file-formats, or
does this not sound like a good "contingency" to you?

Also - think about this - what is the single most common document 
format, globally, as well as over time and as well as across any 
and all operating systems & platforms, 

         - it's ASCII Text, - isn't it?  

Name a single computer platform that cannot read ASCII text? 

   - can't do it , huh? 

Does that tell you what format your files (critical ones at least) 
should be stored in?  Maybe even what format they should be 
written & archived in?

Second most popular & versatile file format is what? 

    HTML (which is just a "gloified" form of ASICII text, isn't it?) 

How many computers can NOT read HTML? - can't think of one, can you?

So does that also tell you what format you might want to store 
other critical files in?

Does this tell you what format you might want to publish 
critical documents in?- (does any of this sound familiar with what 
I've been preaching for years (take a look at my web-site - 
how many Word or Frame documents do you see?


5.) cross-platform restores: - by thinking about the above items,
Hardware / OS failure,  Applications failures, and the formats
your documents are stored in - you may get a bit better appreciation
for just a few of the finer-points of Contingency Planning.

IF this fails and you have to move user's project directories to
a platform they were not created on, then how do you do that, and 
ensure that the user's files are still useable?


Yes - I agree mountains & mountains of
data need to be in Frame or whatever - tables / graphs / 
...gifs, ...jpgs, etc. etc. etc.  we're never going to restore
everything overnight.  Additionally - there are obviously a 
much much larger percentage of documents that have too many,
too much graphics / table / etc content to be stored in an 
ASCII - mulit-platform format.  - BUT - where you CAN store
things in ASCII - interchange formats - isn't it a good 
strategy to do so? - 


some of your more critical 
documentation should be stored in non-platform-specific formats 
- such as ASCII, HTML, RTF, etc. etc. on platform independent 
media (perhaps - need I say it - floppy disks - 

Virtually every computer you have (and virtually every computer 
anyone else has), regardless of OS can read a PC formatted floppy 
- Unix machines read them, PCs read them, Mac's read them  

SO - again - moving a hard disk, with Windows NT data on it to 
another Windows NT computer (nei - Intel box) if it proves 
Intel is a problem, again - doesn't gain you anything 
- it's not a valid response to a Contingency Planning exercise.


You may find that PDF (if a document really needs graphics in it)
or HTML (if a document is mostly text) are the best ways to 
store your data on PC-floppies or PC and Unix-compatible hard 
disks (Jazz/Zip/other optical or mag-optical media).

Even multi-platform recordable CD-ROMs would be an excellent way
to be able to restore from any platform to any platform - CD-ROMs
are fairly universal - and perhaps a set of document archives
created in Mid-December would be a huge crutch against platform
failures on December 31 / January 1.  

- Also - Recordable CD-ROMs
hold tons of data in one place - and are fairly inexpensive compared
to hours of lost work and / or systems admin time...



there will, undoubtedly be more sections to this document as I have
a chance to read more plans - but forn now this  / these items 
will get you started thinking as to what you need to not only DO
to prepare for Year2000, but what you need to write-into your Plan
for year2000 Contingencies.


What you need to do is to figure out where your critical data IS
 - and what format (ASCII / ClearCase VOB's, source code
 (it's ASCII Text, isn't it?)) it is in, and what PLATFORM's 
file-system it is in (PC-NTFS / PC-DOS / Unix-Solaris2.61 / 
Linux-RH5.1 / etc. etc. etc. - and figure out what your "options"
 are for storing that data in alternate forms that can be 
recovered if your "main-stream" Operating System crashes and you
 need to restore that data into a different OS, and a different 
file-system type, and manipulate it with a different application?

so - please think more about this - I would suggest that Contingency 
planning is probably about 80% "thinking" and only about 20% writing
 - don't write before you think, think before you write...

I HOPE this has been helpful in outlining to you what you need to 
do in this exercise & report

if not - please let me know where you have questions or issues and 
I'll write you some more, or call and answer questions over the phone?

bill