Re: NULL's on the Iseries

Vern

At 06:59 AM 9/6/2005, you wrote:

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

--
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.