In article <[log in to unmask]>,
Chip Dorman <[log in to unmask]> writes
>OK, now I'm baffled...
>
>Is there someone out there who can explain the real issues with
>the Powerhouse versions and Y2K?
>
>We are currently on MPE/iX 5.5 pp4 and have been using Powerhouse
>version 7.09.  Based on recommendations by Cognos Tech Support,
>we have installed 7.29C8 and have been working to convert our
>code to handle dates and fiscal periods.
>
>We are a ManMan shop and the main issue has been the ability
>to convert between ManMan's integer date and Cognos date.  Well,
>we have discovered that our current version, with changes to
>the dictionary, will handle the date conversions past 2000.
>Also, it seems to even handle the leap year correctly.
>
>Is there someone, with no vested interest in Cognos, who can
>explain to me what the REAL issues are behind the Powerhouse
>products and Y2K.
>
>Incidentally, we received one of those FUD mailers from Cognos
>today titled "Year 2000 Alert."  Nice writing y'all...
>
Hi Chip, and others interested

I have no vested interest; we support customers by writing additional
custom reports for the HP3000 manufacturing system QED that we sell.
Some have Powerhouse, and where appropriate we (and they) will use that
in preference to COBOL.

Anyway, here's the 'outside' skinny.

7.29C8

This is the first Y2k-*compliant* Powerhouse; AIUI, it now looks at the
hardware clock in certain circumstances (hence the need for TZ) where
earlier versions would have looked at the software clock and got it
wrong.

COGNOS intend that you should be able to use 7.29C8 on and after
01/01/2000 with no problems.

But there are no new data constructs. You will have to 'roll your own'
where implied centuries are concerned, and it won't support those
squinky 'A0' dates in MM3000 and elsewhere.


8.19C1

This is the first Y2k-*friendly* version, with inbuilt support for
implied dates with a pivot year, and other goodies which ease
application development and upgrading.

e.g. INPUT CENTURY century FROM [YEAR] year

'INPUT CENTURY 19 FROM 70' shows that you want century 20 returned for
years 00-69, but century 19 for 70-99.

If you set this in your PDL dictionary system options, it then controls
the behaviour of DEFINE and CHOOSE with PARMS, adding this sliding
century instead of the Default Century when you only input six digits to
an eight-digit (implied CENTURY INCLUDED) date.

(Note that you will *not* find this in the 8.19 Powerhouse documentation
of these statements. Please treat this posting as a late-breaking
'readme' until COGNOS revise their Acrobatics for this acknowledged
omission).

There are other new options ALLOW CENTURY, FORCE CENTURY, and
NULLSEPARATOR which give you more control over how such date fields are
input and displayed, and generally try to let you get dates with
centuries through without having to extend existing date input fields.
These constructs are documented correctly.

Utterly infuriatingly, COGNOS have chosen NOT to modify the behaviour of
ADDCENTURY. So specifying only ADDCENTURY(Date) still gets you the
Default Century, not the sliding one.

However, a new function, CENTURY, can be used to get the 'sliding'
century for any date.

So the ADDCENTURY(date,CENTURY(date)) construct *does* give what is
effectively a sliding ADDCENTURY based on the PDL INPUT CENTURY.

The full syntax for CENTURY is actually
CENTURY([date-expression[,century-expression,start-year-expression]])

So you can optionally override the INPUT CENTURY by specifying a local
century and pivot year for this conversion only.

8.19 also supports Vendor-specific dates with the JDATE, PHDATE and
ZDATE types. ZDATE is what I know as 'A0'; I am sure the other two will
be valuable also.

HTH
--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'