RE: RPG - conversion vs re-write

[Bob Cozzi <BobCozzi@xxxxxxx>]

Okay, here's some code that saves absolutely nothing, but is more 
English-like that %NULLID(ddd)=*ON


     D IsNULL          PR             1S 0
     D   TestDate                      L   Const

     PIsNULL           B                   Export
     D IsNull          PI             1S 0
     D  TestDate                       L   Const
     C                   Return    (%NULLID(TestDate)=*ON)
     PIsNULL           E

Using this procedure, you can then do this in Calcs

C                  If            IsNull(MyDateFld)
C                  /*  do your null-date routine here */
C                  endif


This would be the same as:

C                  If            %NullID(MyDateFld)=*ON
C                  /*  do your null-date routine here */
C                  endif


Now, I suppose the thing that might byte me is the return type on the 
procedures. I used a 1-digit signed numeric. I don't know if Indicators can 
automatically be cast to zoned decimals, so if it doesn't work, do a Z-ADD 
deal right before the return, or similar.


Bob Cozzi
Bob@RPGIV.COM
www.rpgiv.com
AS/400 Books:  http://www.rpgiv.com/as400Books.html


On Wednesday, September 10, 1997 7:06 PM, Vern Hamberg 
[SMTP:hambergv@goldengate.net] wrote:
> At 03:31 PM 9/10/97 EDT, Hans wrote:
>
>
> >Bob:  There's nothing wrong with the implementation of null-capable
>
> >fields in RPG.  I have my concerns about the design, but the
>
> >implementation is just fine!
>
> >
>
> >Actually, my concern with the design is that we did not go far enough
>
> >in supporting the concept.  (And perhaps someday, we'll provide a full
>
> >support for null fields.)
>
> >
>
> >But I suspect that that's not what you are complaining about.  Is it
>
> >that you don't like the whole concept of what a null-capable field
> really
>
> >is?  As you know (or should know), the "nullness" of a field is not a
>
> >value of the field, but rather, some sort of dynamic attribute of the
>
> >field.  It is an indication of the presence or absence of data within
>
> >that field.  That guided our design of %NULLIND in RPG.  We did not
>
> >want to "nullify" a null-capable field by allowing something like
> *NULL
>
> >to be assigned to it.  *NULL is a value, and not an attribute.
> %NULLIND
>
> >emphasizes the point that nullness is an attribute, and is independent
>
> >of the actual data.
>
> >
>
>
> Hans
>
>
> This seems to me too fine a distinction. I understand what you're saying.
> However, in everyday usage, which is where I live, could not the nullness
> of a field be treated both ways? My example is SQL, where, on the one
> hand, NULL is a predidate, with usage like '<italic>expression</italic>
> IS NULL'. On the other hand, NULL can be assigned to a column. There's
> even the statement 'All data types include the null
> <bold>value</bold>.'
>
>
> I just think that NULL is more often handled as a value, although it is,
> technically speaking, an attribute.
>
>
> MHO
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
> | To unsubscribe from this list send email to MAJORDOMO@midrange.com
> |    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
> | Questions should be directed to the list owner/operator: 
david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---