RE: Null Capable Fields

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

Booth,

Don't think of null capable work fields as being any different from "normal"
work fields.  Why do we need ANY work fields?  Why can't we just use
database, workstation and printer field names?  The current NULL
implementation only allows database fields to be null capable.  This means
that you can't readily use externally defined data structures to temporarily
hold a database record, because you'd lose the null indicators.  Let me give
you an example:

Database file CUSTOMER stores end-user information.  It is keyed on CUSNUM.
Some customers are chain-stores, and their invoices go to the home office.
The home office information is also stored in CUSTOMER because the home
office can buy goods from us, too.  The chain-store points back to the home
office by a field called HOMNUM. The date of the last invoice is stored in
LSTINV.   Typical records look like this:

CUSNUM NAME          HOMNUM LSTINV
00001  Local Store 1 50000  *NULL
00002  Local Store 2 50000  19991012
00003  Independent   *NULL  19990601
50000  Home Office   *NULL  19991004

We're printing an invoice.  We have code to print the date of the last
invoice, or "Thanks for your first order!" if this is the first order
(%nullind(LSTINV) = *On)  We also need to go off to CUSNUM 50000 to get the
address of the home office.  This means that we need to save the contents of
LSTINV before doing HOMNUM CHAIN CUSTOMER.  Doing a MOVE or Z-ADD to a "save
field" doesn't quite work because we can't define a save field that's null
capable.  Remember that *NULL LSTINV fields *probably* have a default date
value of 0001-01-01.  The MOVE *would* work, but it would "save" the wrong
value of LSTINV because of the lost %nullind.  This means we need to do
something like this:

D LSTINVSave      S                   like(LSTINV)             
D LSTINVNull      S              1n                            
                                                               
C                   Read      Customer                         

 * This is a chain store

C                   If        %nullind(HOMNUM) = *Off          
C                   Eval      LSTINVSave = LSTINV              
C                   Eval      LstInvNull = %nullind(LSTINV)    

 * Get the home office address

C     HOMNUM        Chain     Customer                         
                                                               
 * Aggregate the chain and home office information for printing
C                   Eval      LSTINV = LSTINVSave              
C                   Eval      %nullind(LSTINV) = LSTINVNull    
...                                                               
C                   EndIf                                      

If there are many fields, the coding is unpleasant, tedious and error prone.
Of course, adding null-capable work fields only helps if MOVE, EVAL, Z-ADD
and their kin move the null indicator with the field value.   Currently,
they do not.  If you have a null capable field, YOU are responsible for
dealing with the checking, storing and setting of the null indicator in your
calculations.  RPG only touches the null indicator on I/O operations.  How
THAT decision was made would be an interesting discussion.  It was probably
a token effort to be able to say that DB2 supports NULL columns.  After all,
"support" would entail being able to read and write records, wouldn't it?
:-)

Buck Calabro
Aptis; Albany, NY
mailto:Buck.Calabro@aptissoftware.com

> -----Original Message-----
> From: boothm@earth.goddard.edu 
> Sent: Tuesday, October 12, 1999 12:06 PM
> To:   RPG400-L@midrange.com
> Subject:      RE: Null Capable Fields
> 
> ok, my curioisty is piqued.  What problem does a "null-capable" field 
> solve?  I thought it's only function was to signal a data field's 
> virginity, and I can't imagine a problem that solves.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---