RE: Interesting question and debate on ddl tables with date fieldsthatwill not always have a value

[Terrence Enger <tenger@xxxxxxxxxxxxxxxx>]

On Tue, 2008-10-14 at 15:57 -0400, rob@xxxxxxxxx wrote:
> One - I don't see this as too tricky:
> if %nullind(termDate);
>   dsply 'employee is active';
> else;
>   dsply 'employee was terminated ' + %char(termDate);
> endIf;
> or any more lines of code than
> if termDate = MichelangelosBirthday;
>   dsply 'employee is active';
> else;
>   dsply 'employee was terminated ' + %char(termDate);
> endIf;

I am indeed an old guy, but I think my distaste for null-capable fields
is an orthogonal attribute <grin />.  

If Fld1 is a null capable character field, the each expression testing
the field must be prepared to deal with the counter-intuitive
possibility that the expressions
    Fld1 =  'X' 
and
    Fld1 <> 'X'
are both false.  Indeed, you cannot even assert that
    Fld1 =  Fld1
.  Who needs the hassle?  

(Yes, I am prepared to defend the thesis that Laziness Is A Virtue!)

> You do have some leg to stand on that if an incompetent programmer were to 
> check termDate without checking it's null indicator they can get into 
> trouble.  For example if I do
> termDate = date(); // set to current date
> %nullind(termDate) = *on; // set termDate off as employee is active
> dsply termDate;  // even though null, it will still display today's date
> But, who's to say that same programmer wouldn't figure that a date of 
> 0001-01-01 or Michelangelo's Birthday or whatever wasn't a valid date?
>
> Were you hoping that IBM had written the compiler so that if you tried 
> dsply termDate;
> and if termDate was null then you'd get a messy MCH type message as if you 
> tried to dsply a variable that wasn't passed into the program and you 
> failed to check %addr on that?

That sounds good to me.  


Eric Delong's suggestion to "propogate nullness" also makes
sense, and it has parallels in for example ...

(*) The Memcheck tool in
    Valgrind (<http://en.wikipedia.org/wiki/Valgrind>,
    <http://valgrind.org/>), which propogates an "is initialized"
    attribute throughout the execution of a propram.

(*) perl taint mode 
    (<http://gunther.web66.com/FAQS/taintmode.html>), which
    propogates "is untrusted input" throughout execution of a
    program.

But to do anything like this requires a concept of "variable"
entirely different the traditional concept of an RPG variable.


Cheers,
Terry.

> I take it you also have an issue with 
> select termDate 
> into :termDate :termDateInd
> from ....
>
>
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> "DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx> 
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 10/14/2008 03:04 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
> To
> "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> cc
>
> Subject
> RE: Interesting question and debate on ddl tables with date fieldsthatwill 
> not always have a value
>
>
>
>
>
>
> So, are you saying that you use null support for all your business
> applications?  From the perspective of your users, would they ever be
> able to tell the difference between an application using null support,
> and an application using legacy techniques?
>
> Seriously, my gripe is not the concept of null value, or even how SQL
> processes in the presence of null values, but is about how hard (messy)
> it is in a HLL like RPG.  The reality is, if you MUST support null
> capable fields in RPG, you must ALWAYS check the null indicator before
> you EVER access the field in question.  Did you know that even a null
> field will still return a valid value during a fetch?  It might be the
> default initial value for that data type, or it might contain some other
> value (assuming the field was set to null AFTER it had a value stored).
>
>
> If IBM made null support more transparent, I would probably recommend it
> usage.  As it is, I don't think most developers would be disciplined
> enough to always use it properly.
>
> JMO,
> Eric DeLong 
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
> Sent: Tuesday, October 14, 2008 1:02 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Interesting question and debate on ddl tables with date
> fieldsthatwill not always have a value
>
> Use nulls, that's what they're for! 
>
> Not to make this an state-of-the-nation discussion, but it's the very
> fact that many people aren't willing to use the "current" stuff, that
> makes an i look old. Imagine this question from an outsiders point of
> view... the rest of the world uses null, to a SQL Server programmer this
> wouldn't even be a question. Looking at an i, we'd see that we "can't"
> use nulls, so i must be old! Granted, it's not that the i can't handle
> them technically, but that our programmers can't handle them. Well,
> sooner or later the programmers have to upgrade their skills, or guess
> what, the machine IS old.
>
> -Walden
>
> --
> Walden H Leverich III
> Tech Software
> (516) 627-3800 x3051
> WaldenL@xxxxxxxxxxxxxxx
> http://www.TechSoftInc.com
>
> Quiquid latine dictum sit altum viditur.
> (Whatever is said in Latin seems profound.)
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Doug Palme
> Sent: Tuesday, October 14, 2008 12:06 PM
> To: Midrange Systems Technical Discussion
> Subject: Interesting question and debate on ddl tables with date fields
> thatwill not always have a value
>
>    I hope that subject description makes it clear.  We are having an
> internal
>    debate and discussion as we make the move towards sql tables and ddl
>    files; specifically using date data types.
>
>    An example, an employee file has two dates, HireDate and TermDate,
> self
>    explanatory.....one is when the person is hired and the other is when
> they
>    leave.
>
>    Obviously while they are an employee, they do not have a term date,
> so how
>    do we handle that?
>
>    suggestions? comments? thoughts?
>
>    This transmission may contain information that is privileged,
> confidential
>    and/or exempt from disclosure under applicable law. If you are not
> the
>    intended recipient, you are hereby notified that any disclosure,
> copying,
>    distribution, or use of the information contained herein (including
> any
>    reliance thereon) is STRICTLY PROHIBITED. If you received this
>    transmission in error, please immediately contact the sender and
> destroy
>    the material in its entirety, whether in electronic or hard copy
> format.
>    Thank you.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
> moment to review the archives at http://archive.midrange.com/midrange-l.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
> moment to review the archives at http://archive.midrange.com/midrange-l.
>
>
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.