Re: NULL's on the Iseries

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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