Roy, et al, write:
> >>Well, if you have COGNOS Powerhouse 8.19, the 'Y2k-friendly'
> >>version, you will find it has expired.
> >>Makes you wonder what they thought people were going to *do*
> >>with this version :-)
> >
> >Really? Our 8.19.C has no expiration problems with the date set forward
> >using Stan's HourGlass product.
>
> How about if you *really* set the date forward?
...
> After all, Robelle were talking about different rules for different
> continents......

Different strokes for different blokes? :)

> > And Stan has asserted repeatedly that
> >HourGlass captures *every* date call. What's up?

Yep.  It does.

> I can never understand this.

Sure you can! :)

> Products like HourGlass are apparently
> supposed not to trigger expirations and such. Which is obviously
> desirable.

Actually, you *want* to trigger the exceptions initially, and then
you want to *not* trigger them later.

If a product would expire with the real date at 2000-01-01, then it
will expire with a simulated date of 2000-01-01.  If the product checked
the date by calling CALENDAR, all of the tools will successfully fool
it (even the free tool!).  If the product checked the date by calling
the POSIX time() function, all of the tools will successfully fool
it (AFAIK...HG3K certainly will).  If the product checked the date by
creating a session temp file, and then checking the creation date of the file,
<plug> only HourGlass fools it </plug>.

So...if a product has an expiration date, it is desirable to trigger it
*today* to find out about it!  You wouldn't want to be hit by the
unexpected expiration date when you come to work on Monday, 2000-01-03!
(I don't know about you, but I'm planning not to come into work that day)

If you determine that a product has an unwanted expiration date, then
you'll probably want to contact the vendor/provider/author to remedy
the problem.  But what about Y2K testing prior to that remedy?
What about vendors who are out of business or unresponsive?
Some of the date simulation tools provide mechanisms (e.g., "rules")
whereby you can say "I want this program to always see the date as
1998-01-01" ... which will presumably provide a workaround.  Of course,
the types of rules vary between products (ranging from none, to
(ahem) very good ones :), and the usefulness of the rules varies (e.g.,
a fairly good rule mechanism doesn't help if the product checks for the
date in a manner that the date similation tool doesn't intercept).

> But if they don't, they can't really be truly simulating setting the
> machine date forward.
>
> How'ja square *that* circle, Stan?

My guess is that Gille's answer is a good one:

> When Cognos ships Powerhouse 8.19, they do so with a TEMPORARY license key
> - which they are obliged to enter in order to render the product useable.
>
> The customer is also instructed to fax to Cognos information specific to
> their CPU, etc. - after which Cognos will fax back a PERMANENT license key,
> which in fact does make it fully y2k-compliant (according to Cognos).
>
> Perhaps the failure to apply the PERMANENT license key explains the
> expiring 8.19.



--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html