|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.