RE: Allow *ZERO in a date (and timestamp) field? IBM?

A compromise is to convert to date data-types and test against *LOVAL where
you are now testing against *ZEROS.  Still requires you to change code, but
swapping *LOVAL for *ZEROS is the least impact, without getting into all the
complexities of *NULL.

> -----Original Message-----
> From: Goodbar, Loyd (AFS-Water Valley) [SMTP:LGoodbar@afs.bwauto.com]
> Sent: Thursday, August 22, 2002 10:19 AM
> To:   'midrange-l@midrange.com'
> Subject:      RE: Allow *ZERO in a date (and timestamp) field? IBM?
>
> For a "from-scratch" application, I agree this is how it should be done.
> One
> problem is most RPG programmers have not encountered nullable fields
> before.
> Can/does RPG/III support null capable fields? I know RPG/IV has %nulind to
> check against. Convert all programs to RPG/IV, recompile with
> ALWNULL(*USRCTL), and bracket date operations with %nulind. I agree
> technically that one shouldn't use a "real" date to represent no date, but
> with as much legacy code with 6,0 or 8,0 numeric with 0 for no date, I
> think
> the "0001-01-01" is reasonable.
>
> Loyd
>
> -----Original Message-----
> From: R. Bruce Hoffman, Jr. [mailto:rbruceh@attglobal.net]
> Sent: Thursday, August 22, 2002 9:00 AM
> To: midrange-l@midrange.com
> Subject: Re: Allow *ZERO in a date (and timestamp) field? IBM?
>
>
> ----- Original Message -----
> From: "William A.(Tony) Corbett" <corbett@ASRESOURCES.COM>
> To: "MIDRANGE-L@midrange. com" <MIDRANGE-L@midrange.com>
> Sent: Thursday, August 22, 2002 9:05 AM
> Subject: Allow *ZERO in a date (and timestamp) field? IBM?
>
>
> > If the "date field restrictions" could be eased up to allow only valid
> dates
> > (as it is now) OR zero in a date field, this would help us a lot.
> >
> > I am currently having to using a packed field to store dates on the
> > db, primarily due to this restriction.  Oftentimes, I need to allow a
> > zero in
> a
> > date field, and current restrictions will not allow this.
>
>
> while I understand the wish, it is not likely to ever be changed. And I
> think "help us" is a key mentality here... it sure won't help the
> developers
> that follow us.
>
> One should never use a value to represent a "no value" condition and
> that's
> what you are doing. A null value is what is used to represent that
> condition. Since nulls are viable in date fields, you would/should convert
> your dates and null those dates that are zero.
>
> And, yes, application code would all have to change then too.
>
> ===========================================================
> R. Bruce Hoffman, Jr.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************