Re: NULL's on the Iseries

["Raul A. Jager W." <raul@xxxxxxxxxx>]

In my opinion, nulls are better implemented in SQL than in RPG.  When I 
compare a field in SQL I don't need to wory if it is null, neither in an 
aritmetic operation.  Nulls compare always false, as they should and 
give null when added to someting else.  In RPG I need check for null 
(%nullind) before using the field.
____________________________________________________________________________________________________
Vernon Hamberg wrote:

> Marco
>
> I agree it is not as simple to deal with NULL attributes in SQL as it 
> is in RPG. So I'll go along with you, that it is not supported in a 
> way that is as easy to do. It is also harder in C/C++ - you have to 
> deal with a separate structure there for handling the NULL attribute.
>
> But does this mean it is almost not supported? A matter of semantics. 
> I find that "...almost not...' is an overstatement. You can handle 
> NULLs in any of these cases, therefore it IS supported. Easy to do? In 
> RPG IV, yes. In the other situations, no.
>
> Of course, you CAN do DSPFs & PRTFs in C, but it is not fun. Least 
> ways, not so much as in RPG.
>
> All in all, I think we've violently agreed too long on this topic.
>
> Long live RPG!
>
> ;-)
>
> Vern
>
> At 12:03 PM 9/4/2005, you wrote:
>
> > Ok Vern, take this example and tell me if this is "support".
> >
> > A PF like this (I use dates for null because are the most common null
> > fields):
> >
> > field1    10A
> > field2      L   ALWNULL
> > field3    30A
> > field4      L   ALWNULL
> >
> > when I use it in RPGIV the only thing I have to do is declaring in the H
> > spec ALWNULL(*USRCTL) and the use the biff %nullind to get or set the 
> > null
> > status. That's it.
> >
> > In sql/rpg I have to do something like:
> >
> > define e ds:
> >
> > d myfile        e ds                  extname(myfilepf)
> > d indnul          s              4b 0 dim(1000)
> >
> > prepare an sql statement:
> >
> > wstring = 'SELECT * FROM MYFILEPF WHERE .....';
> >  /end-free
> > C/exec sql
> > C+  PREPARE S1 FROM :WSTRING
> > C/end-exec
> > C/exec sql
> > C+  DECLARE CURS1 CURSOR FOR S1
> > C/end-exec
> > C/exec sql
> > C+  OPEN CURS1
> > C/end-exec
> > C/exec sql
> > C+  FETCH CURS1 INTO :MYFILE :INDNUL
> > C/end-exec
> >
> > Now to test if the two fields are null you have to to write something 
> > like:
> >
> > if indnul(2) <> 0;
> >   do something...
> > endif;
> > if indnul(4) <> 0;
> >   do something...
> > endif;
> >
> > Now try to modify the PF as follow:
> >
> > field1    10A
> > field1A   50A
> > field2      L   ALWNULL
> > field3    30A
> > field4      L   ALWNULL
> >
> > The code is still working?
> >
> > And before you suggest not use SELECT * remember that you have to 
> > build and
> > maintaine the list of fields in the select statement and in the 
> > receiving ds
> > to follow all your database modifications (removing and adding 
> > fields) and
> > not just re-compiling as with RPGIV.
> > Since we where talking about support this is what I mean for almost not
> > supported.
> >
> > HTH
> > Marco
> >
> > --- Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:
> >
> > > The NULL attribute of a column (field) is a bit flag stored in the 
> > record
> > > ahead of the actual data. If you are working in C, you need to use a
> > > NULL-indicator array. Same in RPG IV, and even in embedded SQL. The 
> > trick
> > > is to have an array of 4B 0 (according to the manual) and append it 
> > to the
> > >
> > > host variable array
> > >
> > >   :hostarray:indarray
> > >
> > > Then there is a value for each column that can be used to get or 
> > set the
> > > NULL attribute. This seems like pretty full support for SQL/RPG, if by
> > > that
> > > you mean embedded SQL.
> > >
> > > Later
> > > Vern
> > >
> > > At 02:41 AM 9/3/2005, you wrote:
> > >
> > > >If you plan to use:
> > > >
> > > >SQL, the support is complete
> > > >RPGIV, partial support for previous release, good for V5R3
> > > >SQL/RPG, almost not supported.
> > > >
> > > >HTH
> > > >Marco