year 2000 vax 610?

[Deskin, Bob]

I agree with everything but the first sentence. PowerHouse understands
that Feb 29, 2000 is a valid date. When you're entering a date with a
2-digit year format (century included or excluded), PowerHouse checks
the date using the default century (unless you're using the new INPUT
CENTURY feature). Since Feb 29, 1900 is not a valid date, it's rejected
if the default century is 19. However, if you have a century included
date and use a 4-digit year format, you can enter any date regardless of
the value of the default century. I know this is picky and comes from
the fact that most applications use a 2-digit year date format, but I
want to make sure that people understand where the problemn is coming
from.

As for the use of windowing, while I agree that every application is
different, based on our experience, I strongly urge the expansion
approach rather than windowing. Remember that expansion includes the use
of HP's A0 date format which PowerHouse now supports. I just heard from
someone in the UK that a project that should have taken a month took 4
to do with windowing. I'm not saying that it should never be done, but
do your homework first and make sure that it's the only way.

Bob Deskin              
Senior Product Advisor  bob.deskin@cognos.com
Cognos Inc.             (613) 738-1338 ext 4205 FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


> ----------
> From: 	Oran Shapitka[SMTP:shapitka@cips.ca]
> Sent: 	Thursday, July 23, 1998 1:11 PM
> To: 	mclsys@home.com; David Hood
> Cc: 	'Wilkins, James'; 'powerhouse list server'
> Subject: 	RE: year 2000 vax 610?
> 
> In addition to these comments, the default century of the dictionary
> must be
> set to '20' before your users will be able to enter the date
> 2000-Feb-29.
> 
> We have done several Y2K conversions.  Our experience has been that a
> different approach for each application is required.  There are
> numerous
> variables that range from whether data entry windowing is chosen
> (1949-2050
> or 1920-2021[HR Applications]), do users input CCYYMMDD or YYMMDD,
> does the
> database store the century or is the client willing to change the
> database
> to store the century, will screen/report real estate changes be
> allowed or
> required on external reports.  There are many more considerations for
> each
> conversion.  IT IS DANGEROUS TO MAKE A BLANKET STATEMENT TO COVER ALL
> PH
> APPLICATIONS.
> 
> Once you have identified your requirements, then evaluate your
> options.
> TEST, TEST, TEST before going to far with your changes.  What happens
> when a
> user inputs a zero date, what happens when a none date value is input
> (i.e.
> 20000243), what happens when the user gets an error message and then
> presses
> return?  Our experience has been to know all the possible ways a user
> can
> get around an entry, and then test your approach for that application
> to
> ensure that they can't get around it.
> 
> Oran Shapitka, ISP
> Intertech Business Systems, Inc.
> 1564, 10303 Jasper Ave
> Edmonton, AB  T5J 3N6  Canada
> 
> Email:	shapitka@cips.ca
> Voice:	(403) 413-0400
> Fax:		(403) 413-0398
> 
> -----Original Message-----
> From: owner-powerh-l@sphere.swau.edu
> [mailto:owner-powerh-l@sphere.swau.edu]On Behalf Of Michael C. Lee
> Sent: July 23, 1998 9:34 AM
> To: David Hood
> Cc: 'Wilkins, James'; 'powerhouse list server'
> Subject: Re: year 2000 vax 610?
> 
> 
> There seems to be something missing here. I took a FORMAT YYMMDD date
> and
> added
> code to the INPUT procedure to add the century based on the year. The
> problem
> with this was, as you mentioned, it then passes that date to the EDIT
> procedure. Between the INPUT & the EDIT procedure Powerhouse does it's
> own
> editting and one of the things it checks for FORMAT YYMMDD fields is
> that
> the
> century has NOT been entered. For FORMAT YYYYMMDD fields any checking
> is not
> necessary. I found that I had to add the code to the EDIT
> procedure-after
> Powerhouse does it's internal edit checks.
> 
> 
> David Hood wrote:
> 
> > One of our clients had similar versions of VMS and PowerHouse. We
> > introduced code to be "used" in the INPUT procedure for date fields
> on
> > QUICK screens. This code applies a default century of "19" if the
> year
> > is greater than "50", or a default century of "20" if the year is <=
> > "50". (This code would not be necessary, if you were able to upgrade
> to
> > v7.10G of PowerHouse.)
> >
> > Code in the INPUT procedure gives a valid date, which is then passed
> to
> > the EDIT procedure. There were a few other problems on screens,
> which
> > used different formats for dates, such as MMYY, so these required
> some
> > extra coding.
> >
> > Regards,
> > David Hood
> > Director of Systems Solutions
> > Hexagon Computer Systems Pty Ltd
> > TEL: +61 2 9968 5665
> > FAX: +61 2 9968 5656
> > Mobile: 0412 750 950
> > http://www.hexagon.ca
> > mailto:dlhood@hex.com.au
> > Sydney  Boston  Dallas  San Francisco  Toronto  Ottawa
> >
> >         -----Original Message-----
> >         From:   Wilkins, James [SMTP:Wilkins@ariver.com]
> >         Sent:   July 23, 1998 12:38 AM
> >         To:     'powerhouse list server'
> >         Subject:        year 2000 vax 610?
> >
> >         I am currently running PowerHouse version 610E on a Vax
> cluster
> > with the
> >         operating system version of 5.5-2. I cannot upgrade my
> operating
> > system
> >         version due to other non-PowerHouse applications awaiting
> > upgrade.
> >
> >         I am in process of converting my Powerhouse applications to
> be
> > year 2000
> >         compliant(using Power2000). However, I understand there are
> some
> > outstanding
> >         Y2K issues in my version of Powerhouse and the Vax operating
> > system. Can
> >         anyone tell me the gotcha's with this situation?
> >         = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = =
> > = = = = = =
> >         Subscribe: "subscribe powerh-l" in message body to
> > majordomo@lists.swau.edu
> >         Unsubscribe: "unsubscribe powerh-l" in message to
> > majordomo@lists.swau.edu
> >         powerh-l@lists.swau.edu is gatewayed one-way to
> > bit.listserv.powerh-l
> >         This list is closed, thus to post to the list, you must be a
> > subscriber.
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = =
> =
> > Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> > Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> > powerh-l@lists.swau.edu is gatewayed one-way to
> bit.listserv.powerh-l
> > This list is closed, thus to post to the list, you must be a
> subscriber.
> 
> 
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a
> subscriber.
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a
> subscriber.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.