I'd suggest not to use UDTs because:
1. They can't be used with native I/O
2. An UDT can only be changed if there is not a single reference on it. That
means before chan

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les

"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: Friday, February 29, 2008 22:51
An: Midrange Systems Technical Discussion
Betreff: RE: DDS modernization - use of REFFLD

Well, maybe not quite the same, but what about UDTs?


-----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

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.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, February 29, 2008 11:57 AM
To: Midrange Systems Technical Discussion
Subject: Re: DDS modernization - use of REFFLD

Here's the rub. Many people still name their fields based on the file
they are in. For example, if I have a field called ITEMNUM in FILEA
and FILEB they will call it AITEMNUM in one and BITEMNUM in the other.
Rather silly. Especially with prefix, or qualified, now if you are
concerned about field name collisions. Even prior to prefix I've seen
system i vendors who named the field the same. Naming it the same
would allow you
FROM syscolumns

I suppose you could alter this to

You still can do the DSPFFD on printer and display files. There's
currently no plans to convert that to DDL that I am aware of.

Rob Berendt
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755

"JK" <johnking@xxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/29/2008 12:43 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject DDS modernization - use of REFFLD


Yesterday I received a change request that requires an existing PF
field to be increased in size. The actual program changes are trivial
- the main effort will be to identify which display files and printer
files use that field and verify that no other information will be
overlaid by the new, longer field.

Even if we didn't have a cross-reference utility, in our DDS-defined
system this would be fairly simple - dump the DSPFFD to an outfile and
query for the appropriate REFFLD.

Without a utility, I'm not sure how you'd do the equivalent task in a
DDL-defined system. Query the column-label or column-text and hope
that the designer specified everything consistently?

This is not intended as a criticism of DDL, I'm only trying to
understand how you DDL-guys tackle situations like this. If we end up
redefining everything in DDL, what other things should we watch out

Many thanks, JK

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].