RE: DDS modernization - use of REFFLD

Eric,

Thanks for mentioning UDTs. I've seen them mentioned but have not worked
with them before.

In the case of a column like 'postal_code' or 'item_number', the technique
of identically-named columns works well. If one needs to expand the db to
allow for the new 27-char Elbonian postal code, then searching syscolumns
for all instances of 'postal_code' will do the trick. However, I was poking
around the db today and came across a "CUSTOMER_CONTACT" table which
contains two columns for UPS/FedEx billing accounts: one for parcels sent
internally and another account for parcels sent by a 3rd party. Yeah I know,
a truly normalized db would store separate account #s in a child table
but...well... it just wasn't worthwhile in this case, so both columns were
placed in the parent table with different suffixes on the column names. A
UDT defining 'account#' as a specific entity would do a better job of
identifying data types than relying on relationships between column names.

I'll have to take some time to tinker with that.

JK

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Friday, February 29, 2008 3:51 PM
To: Midrange Systems Technical Discussion
Subject: RE: DDS modernization - use of REFFLD

Well, maybe not quite the same, but what about UDTs?
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/sqlp/rbafyuddt
.htm

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of JK
Sent: Friday, February 29, 2008 2:25 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: DDS modernization - use of REFFLD


Years ago, the 2+4 field-naming convention was a great way to avoid
problems caused by accidentally overlaying the contents of similarly-named
fields in RPGII. The theory being that the programmer had to specifically
use a MOVE statement to populate an output field. This technique _reduced_
the possibility that a maintenance programmer would, at some later date,
accidentally trash the contents of NAME by chaining to CUSMAS, not
realizing
that NAME also held the item-name. Programming techniques and RPG's
capabilities have changed but database column names haven't necessarily
been altered.

What I'm gathering is that DDL simply does not address the concept of
REFFLD. There exist techniques to simulate it, but the concept of REFFLD
wasn't a part of ASNI SQL and DDL won't support it either. One could even
argue that REFFLD is more of a 'data dictionary' concept than a
'Structured
Query Language' concept and that there are 3rd-party utilities available
if your shop needs that capability.

Fair enough.

JK