But you don't *have* to in SQL (and many other languages).
You have to check NULL values with SQL separately: WHERE conditions IS NULL
Embedded SQL Indicator variables that have to be added.
In RPG, null doesn't even really exist as a value. It's an add-on flag.
A NULL value is a value out of the valid range! That must be checked
separately in RPG as well as in SQL.
In the database the NULL value is a flag that is set if it is a NULL value
and it is not set if it is no NULL value
VARLEN fields are conceptually similar in structure to nullable fields.
No they aren't!
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im Auftrag von John
Yeung
Gesendet: Tuesday, 22.9 2015 16:30
An: RPG programming on the IBM i (AS/400 and iSeries)
Betreff: Re: Max date
On Tue, Sep 22, 2015 at 8:53 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:
In either RPG or SQL, when dealing with nullable columns, you have to
test for null before trying to look at the value.
You definitely have to test for null separately in RPG (using %NULLIND as
your example shows), which is part of why it's so clunky in RPG.
But you don't *have* to in SQL (and many other languages). You just have to
be aware of how null values interact. In SQL, NULL is a "first-class" value.
What I mean by first-class is that it is just as valid as any other value
(as far as the language is concerned); it can appear where any other value
appears.
In RPG, null doesn't even really exist as a value. It's an add-on flag. A
variable can be nullable or not, and if nullable, then its add-on flag can
be on or off. But it still has a value completely separate and independent
of this flag. That is, if you do a "straight test" of the value of a
nullable variable, it might be 5. Or 6. Or 'Hello world!'. Or complete
garbage. And in any of these cases, the nullable flag might be on. So it
*tests* as 5, say, but it really should be considered NULL, and you don't
know that it's NULL unless you explicitly check for it using %NULLIND.
Very, very clunky. And extremely prone to logic errors. I suspect
RPG-centric shops are much less likely to use nullable columns than
SQL-centric shops, in part for this reason. (In fact, I *hope* this is the
case!)
Maybe RPG will eventually improve its null support (by "improve" I mean make
RPG higher level, more like SQL and less like assembly).
VARLEN fields are conceptually similar in structure to nullable
fields: They have a "value" which consists of the bits stored in the
allocated data space, and they have an add-on attribute (length, in the case
of VARLEN fields; "is null" in the case of nullable fields).
The RPG compiler is smart enough to use the length attribute in most
contexts that involve a VARLEN field. I believe it shouldn't be too much of
a stretch for the RPG compiler to make similar use of the "is null"
attribute when working with nullable fields. (Though I think the current
behavior should stay as-is when the ALWNULL(*NO) compiler option is
specified.)
John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
