So you are suggesting iseries-based organizations with limited close-to-retiring staff write a data dictionary generator for their company?
What happened to iseries having a robust database built-in?
This is akin to buying a Chevrolet and being informed that - oh-by the way, it will arrive without an engine, you will have to build your own! GM will throw in a few pistons to get you started.
:)
So bottom line my choices are:
1) Stay with DDS to describe files & fields, and make future mods easier because I can inherit fields from a single crude "data dictionary" - a field reference file. Con: DDS is dead, no more vendor enhancements.
2) Switch to SQL for data definition, but future database mods will become more and more difficult and costly because attributes can no longer be inherited from a single point of definition.
Doesn't seem like there is a winning option???
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, October 30, 2012 11:14 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: DDS field reference equivalent in SQL
On 30 Oct 2012 10:10, Stone, Joel wrote:
An important part of making field length changes easier on iSeries
is to use a field reference file to inherit attributes from other
fields and files.
Is there an equivalent in SQL?
Add a "data dictionary" abstraction layer between the database SQL
and the application programming, and then use that /dictionary/ to
generate DDL instead of composing the SQL directly. I would avoid ever
using them, but the SQL did offer a DATA DICTIONARY which does have some
[slow and limited data type] support, provided by the IDDU feature's
Data Dictionary [*DTADCT] object type as an implementation object; e.g.
CREATE COLLECTION "DEPRECATED" WITH DATA DICTIONARY
I had advocated for making the WITH DATA DICTIONARY clause become a
no-op, but I am not aware if full elimination of the support [aside from
possibly allowing restore from older releases] had ever come.
midrange.com
