RE: RPG IV not up to the task of reading and writing to DB files....

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Thursday, May 18, 2006 6:58 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: RPG IV not up to the task of reading and writing 
> to DB files....
> 
> 
> > Even with the above, the programs calling those top level procedures
> > have to jump through hoops to either OMIT or no OMIT the param.
> 
> Hmmm...  you aren't simply passing the whole record back to 
> the caller and 
> letting it manipulate the fields, make them null, etc, are 
> you?  

No.

> If so, I 
> wonder where the benefit is?  Does it save you anything over simply 
> chaining to the file in the routine that needs it?
> 
> I would think that you'd be writing something more like a 
> business model. 
> Something that corresponds directly to what your programs 
> will need to do 
> -- rather than just mimicking what the database routines do.

Yes, the routines are based on the business model, not simply mimicking
READ/WRITE/UPDATE.

> 
> If you do code it as a business model, does the caller still 
> need to set a 
> field is NULL?   Often times, fields are set to null when the initial 
> record is written, and then the fields are "filled in later." 
>  In that 
> case, you wouldn't really need to communicate that 
> information back, would 
> you?  Just write the initial record with null set, and turn null off 
> whenever the field is updated.

No, the callers sometimes need to communicate it.  Mostly, the NULL
capable fields in the DB are foreign key columns that may or may not
contain a value depending on the values of other fields.

In particular, since I've simplified the higher level business routines,
my low-level private helper functions would benefit from an easy way to
return NULLS.

> 
> But if you do need to communicate it, I'd typically use a 
> special value 
> (blanks, or -1, or zero, or 999999 depending on what the 
> field is) and 
> just set the %NullInd immediately before writing the record.

Yeah, I could do this, particularily since we're talking about mainly
about lower level helper functions.

But, I don't like the idea :-)  Mainly because what may be invalid now,
might not be invalid later.  Additionally, what may be invalid for one
field may not be invalid for another of the same type.  I really don't
want to have a couple of dozen "NULL" values.

I think what I'm going to do is define templates like the following:
     d t_StockRoom     s              5a   based(TEMPLATE)

     d t_StockRoomNULL...
     d                 ds                  qualified based(TEMPLATE)
     d  isNull                         n
     d  value                              like(t_StockRoom)

Which gives me a "required" version of the field and an "optional"
version.

Actually, I think I like the resulting code pretty well.  Instead of
     if %addr(stkrm) <> *NULL;
       MyFileDS.stockroom = stkrm;
       %nullind(MyFileDS.stockroom) = *OFF;
     else;
       %nullind(MyFileDS.stockroom) = *ON;
     endif;

I can simply have
     myFileDS.stockroom = stkrm.value;
     %nullind(MyFileDS.stockroom) = stkrm.isNull;

I also like
     if stkrm.isNull;

Better than
     if %addr(stkRm) = *NULL;

Now, the only thing missing from this solution is...initializing or
defaulting a new "instance" of a nullable variable to NULL.  Two choices
that I see, either make the template non-based and specify the INZ
values I want on the subfields or rename the isNull subfield to
isNotNull to take advantage of the default value of an indicator.  Not
sure I like the looks of:  
     myFileDS.stockroom = stkrm.value;
     %nullind(MyFileDS.stockroom) = not (stkrm.isNotNull);

Too bad INZ(*ALL'1') doesn't work for a DS!

> 
> I agree that null support right now is one of those ever-present 
> "half-finished" functions in RPG.  In every release there's 
> always stuff 
> where it seems like they started it, but never finished it. 
> Null support 
> is definitely one of those things!
> -- 

I have to agree with you here!


Thanks, 

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121