Birgitta,
Thanks for your comments. I plan to test this soon, so perhaps I will revise my opinion of null support. However, I still feel that null is too easy to make mistakes with. I appreciate you opinions on this topic...
Eric
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Birgitta Hauser
Sent: Wednesday, October 15, 2008 12:29 AM
To: 'Midrange Systems Technical Discussion'
Subject: AW: Interesting question and debateon ddltables withdate fieldsthatwill not always have a value
Hi,
copied from the RPGIV Reference (Release V5R4):
When OPTIONS(*NULLIND) is specified for a parameter, the null-byte map is passed with the parameter, giving the called procedure direct access to the null-byte map of the caller's parameter. Note the following rules for OPTIONS(*NULLIND).
- ALWNULL(*USRCTL) must be in effect.
- OPTIONS(*NULLIND) is not valid for parameters passed by value.
- The only other options that can be specified with OPTIONS(*NULLIND) are *NOPASS and *OMIT.
- Only variables may be passed as the parameter when OPTIONS(*NULLIND) is specified, and the variable must be an exact match
even when CONST is specified. Definition-Specification Keywords
- If the parameter is a data structure, the passed parameter must be defined with the same parent LIKEDS or LIKEREC
as the prototyped parameter. Furthermore, the null-capability of the prototyped parameter and passed parameter must match exactly.
- A prototyped data structure parameter can have OPTIONS(*NULLIND) specified whether or not there are any null-capable subfields.
- If a non-data-structure prototyped parameter is defined with OPTIONS(*NULLIND), the parameter in the procedure interface is defined as null-capable.
See WebSphere Development Studio: ILE RPG Programmer's Guide for information about using OPTIONS(*NULLIND) when the calling procedure or called procedure is not written using ILE RPG.
BTW: A NULL value is out of the valid range and must be checked separately.
If a column is NULL-capable one byte of the field is reserved to set the NULL flag to *ON or *OFF. That's for example why a not NULL capable fixed length character field can be defined up to 32,767 Byte while the maximum length of a NULL capable character field with fixed length can only be defined up to 32,766 Bytes.
In the where clause of an SQL-Statement, NULL values must be selected by :
MyFld IS NULL or MyFld IS NOT NULL (the equal sign is not allowed for NULL values).
With (embedded) SQL a NULL value in a column must be checked by an indicator variable which is set to -1 if a NULL value is returned.
The indicator variable can also be used to set a NULL value. That means if you pass an indicator variable in an Update or Insert statement and set this variable to -1 a NULL value gets written to the appropriate column.
With RPG the NULL-value can only be checked if the keyword ALWNULL(*UsrCtl) is set in the H-Spacs.
With this keyword the NULL-byte map gets integrated into the program/module object.
To check or set a NULL value the built-in-function %NULLIND must be used.
Because a NULL value must be separately checked, using NULL capable columns may decrease performance.
In this way a column should only be defined as NULL capable if needed.
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: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von DeLong, Eric
Gesendet: Wednesday, 15. October 2008 00:41
An: Midrange Systems Technical Discussion
Betreff: RE: Interesting question and debate on ddltables withdate fieldsthatwill not always have a value
Really? Do you happen to know which version that came with? I don't think I've heard that mentioned on the list before today, but I'm sure I could have missed it.
Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Tuesday, October 14, 2008 5:26 PM
To: Midrange Systems Technical Discussion
Subject: Re: Interesting question and debate on ddltables withdate fieldsthatwill not always have a value
DeLong, Eric wrote:
No, I would want IBM to allow me to propagate the "nullness" <g> of
any given value throughout my application. If I need to pass that
field into a subprocedure, should I also need to explicitly declare an
extra parm just so I can pass it's null flag? Ideally, null should
just be an attribute of the field, and implicitly passed along with
its addressing pointer.
Is a null attribute passed in OPDESC?
Now, despite my personal bias against null fields, I must say that RPG has gotten better at handling them. Barbara managed to introduce the *NULLIND option on procedure parameters, which does pretty much exactly what you need.
Joe
--
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.
--
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.
midrange.com
