AW: DDS modernization - use of REFFLD

Hi,

An other try, I was too fast last time.

I'd suggest not to use UDTs because:
1. They can't be used with native I/O.
It is also not possible to use them for DDS described display files or
printer files.
2. An UDT can only be changed if there is not a single reference on it.
That means before changeing an UDT, you have to delete all objects that
reference this UDT
and recreate them after having changed the UDT.
3. Fields defined with different UDTs cannot be compared directly,
i.e. one of them must be casted to the other data type.
For example: You defined an UDT for you delivery date (with data type
date)
and want to compare the delivery date with the current date.

Even though both are dates the delivery date must be first
converted
into a real date to compare it with the current date.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"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?
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/sqlp/rbafyuddt.h
tm

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

-----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
to:
SELECT SYSTEM_COLUMN_NAME, SYSTEM_TABLE_NAME, SYSTEM_TABLE_SCHEMA
FROM syscolumns
WHERE SYSTEM_COLUMN_NAME='ITEMNUM'

I suppose you could alter this to
SELECT SYSTEM_COLUMN_NAME, SYSTEM_TABLE_NAME, SYSTEM_TABLE_SCHEMA FROM
syscolumns WHERE SYSTEM_COLUMN_NAME like('%ITEMNUM')

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
http://www.dekko.com

"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

All,

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

Many thanks, JK