Re: IBM DDS to DDL and native file structure to RDBMS table direction -- MIDRANGE-L

Dave

Do you have a link to the presentation? Maybe on the iSereis DB2 site?

One of the statements seems a little weird--"from the current native flat file, keyed-sequence file structure created by DDS to RDBMS tables created by DDL". Why this seems strange is, the RDBMS tables created with DDL are exactly the same as the files created by DDS. An SQL table is a physical file, after all. Some attributes differ - an SQL table can have only one member, where a PF can have as many as allowed. There are other small distinctions, but to suggest they are as different as this statement does is just not true. Besides, PFs created via DDS are treated by SQL exactly the same as tables created via DDL, and vice versa. Views and indexes are variants of the good old logical files, and can be used interchangeably with standard LFs in many situations.

it is true that IBM is not going to add anything to DDS - OK. And suggestions for how to manage SQL objects are welcome. It seems to me these things must already exist for other databases. And database modelers like ERWin and Popkin have been around for awhile - Popkin has handled reverse-engineering AS/400 stuff for years, and it has generated either DDS or DDL for database models you set up in it.

Rob has presented many of the points. I believe that it is best to use the tool that fits the need best. I'm convinced that single-record activity, native I/O will outperform SQL. OTOH, blocked, recordset processing is just what SQL was made for.

JMHO
Vern

At 03:05 PM 8/19/2004, you wrote:
-snip-

I went to a local iSeries user group meeting yesterday and an IBMer
from Rochester gave a presentation about IBMs direction concerning DDS
vs. DDL and ways to migrate from the current native flat file,
keyed-sequence file structure created by DDS to RDBMS tables created by
DDL.   He said that IBM's direction, and where their money is being
spent, is on SQL enhancements and not to DDS when it comes to data
structure definition.  The same is true for data access and manipulation
vis-a-vis SQL Data Manipulation Language (DML) vs. native READs, WRITEs,
CHAINS, etc.  In addition, the jest was that customers should make plans
to move both their data structure definition and application functions
to an SQL oriented world and away from, for the most part, the native
methodologies that have been around since S/38 days.