December 22, 1999
It seems that the more responsive & responsible manufacturers
are creating special web pages where they going to post last minute information.
These pages are usually separate from the normal compliance pages. For
example, see IBM (http://www-4.ibm.com/software/year2000/alert/),
(http://www.hp.com/y2ktim/) and others. Some
others are planning to use email servers to broadcast emails to those who have registered
to receive these special emails over the turn of the century.
I hit a problem with this and have had to pull our tool temporarily.
It seems that several manufacturers are placing date/time stamps for the
last time the page was re-uploaded on the web page itself (like HP). This
serves as positive feedback to the user that the page is being maintained
and contains up to the minute information. What that means is that any
standard web tool that currently exists are likely to flag a change every
time that a manufacturer uploads his web page saying that there are no
changes. Ideas like the checksum or file stamp methods that Aaron
recommended below won't work for these manufacturers. Even tools that rely upon
masking require you to know exactly that information is going to be
presented on the web page, so that you can set up the masking - so masking
doesn't even work.
This weekend I am going to try to attach our date file comparison engine
used in our fileCompare utilities to the web tool and create a web
comparison tool that automatically detects (and ignores) these non-important
date/time stamps (while still flagging any actual change in the page,
including just in a single date/time stamp). The only problem I foresee is
that the engine is not set currently set up as DLL, so there is a little bit
of re-designing that has to be done.
If everything goes well, we plan to re-release the tool then as shareware
next week with a trial period of 30 days to allow people to use it through
the New Year. It will make excellent advertising for our file comparison
process that you don't have to specify where the dates are within the files
being compared, nor the format of any specific date and still be able to
detect when the important date stamps change without masking. The only
problem is that with this short time period, I have no idea how to get the
word out of the tool being freely available.
We do this without masking out any information from the files until the
engine has determined that it is not significant. I had a gentleman call me
one day asking if our tool has the feature to mask out unwanted fields (i.e.
dates that he expected differences in). I told him "No, that was
unnecessary for our process. Masking creates lots of setup time and
eliminates the first indication of something like a leap year problem where
the dates will be off by one day. Why would you want to mask out the first
indication that you had a problem?"
> Date: Sat, 20 Nov 1999 11:26:04 -0500
> VF> > <vic@dateWise.com>
> VF> >Now here is the question: how am I going to find out that any
> VF> >manufacturer has posted a fix that I need to their web page so
> VF> >that I can apply it in a timely manner [especially for any
> VF> >last-minute updates from vendors taking place in the hours
> VF> >shortly after the end of the year, as Y2K problems crop up in
> VF> >COTS].
> KL> >"Kathy L" <address deleted> replied:
> KL> >Try a web tracker service such as "Mind-It" set up the
> KL> >manufacturer's Y2K Compliance page:
> KL> >
> KL> >http://www.netmind.com/html/url-minder.html
> I use Mind-It, in fact some of my web pages have a notification
> built into them so people can sign up for Mind-It to watch the pages for
> changes. But, IMHO Mind-It is not suitable for the Y2K rollover.
> I want to avoid problems, not reproduce them on my system. Mind-It visits
> web pages at most once every 24 hours. In the scenario laid out, there is
> much less than 24 hours available, so I am not guaranteed that I will have
> the notification until as much as 24 hours after I have brought
> up my systems (assuming that email is 100% reliable). Also, I am not sure
> what Mind-It's schedule is for holidays or weekends.
> As I implied, email is not 100% reliable. There is no guarantee that an
> email message will be delivered or will be delivered in a timely manner.
> I have noticed emails being received as much as 48 hours after
> they were sent. (Most of the time I don't even look when they are sent -
> but when I have been urgently awaiting vital information that
> I was told on the phone was already emailed, I have seen it. In fact, if
> you look at the RFC for the email protocol, there is no guarantee that it
> will ever be delivered - how would you like to loose the single email
> notifying you of a Y2K patch?
> Finally, the Y2K compliance page may not be where the last minute
> notifications will be posted. You need to check with each individual
> manufacturer to see what their plans are to post information. Some of
> the checking I have already done seems to indicate that manufacturers
> haven't thought that far ahead yet, check with them in the middle of
> December. You don't want to be monitoring the wrong page.
> AR> "Aron R" <address deleted> replied:
> AR> Another alternative for receiving more frequent
> AR> be to create an in-house tracking service, or to look for other
> AR> existing services, programs, or scripts for this purpose. As just
> AR> one off-the-cuff example, programming and scripting languages such
> AR> as Java and Perl have libraries containing routines which can
> AR> essentially simulate the action of a Web browser (e.g. java.net.URL)
> AR> and Perl (libwww-perl at
> AR> respectively. One could write a program to connect to various
> AR> vendors' Web servers and download the contents of various
> AR> vendors' Y2K Web pages. One could then compare these pages'
> AR> contents, checksums based on these contents, and/or modification
> AR> dates and times to those of the same pages when they were
> AR> previously accessed, say, eight hours earlier.
> I have something like that (except mine is in VB) that is about
> should be available at (http://www.dateWise.com)
by December 1.
> Everyone could write their own, or you could use one off the shelf.
> Properly done, you can avoid every losing a notification of change.
> AR> Another possibility might be to look
> The only possibility I see as able to work is something that
> when the web pages are checked (IMHO, there are no other possibilities).
> Any third party service will have the same limitations - how often do
> they check for your specific products, is there some guarantee of timely
> notifications (how will you be notified if you miss an email, etc.). If it
> is something you run from in-house then you have the proper solution that
> overcomes all these types of problems
> IMHO, checking every 8 hours is the wrong solutions for most everyone.
> At the zero hour, there is too much chance that someone will post a patch
> right after you check their web page and you won't find out about until 8
> hours later. It would also be disastrous to check once every five minutes
> because you would tie up the servers just serving your queries. I would
> suggest tying your checking schedule to your schedule of when various
> processes will be started at zero day (such as 30 minutes before bring
> up the mainframe would be an excellent time to check if there are any
> new patches required); when your system will be down for a few hours,
> there's little need to check COTS notifications; and checking every two
> hours starting at some random time within a couple of hours after the
> first time zone reaches the new year while your system is up. (The
> random starting time avoids collisions from 5,000 robots checking
> the servers at exactly every two hours on the the hour.)