Externally-described files were one of the most important time-saving innovations of the System/38 and have continued to serve S/38, AS/400, and iSeries developers well. But it’s time to ask whether DDS is “dead.” The question isn’t whether IBM will drop support for existing DDS-created files (they won’t anytime soon), but whether you should quit using DDS and start using SQL for new development.
DDS (the familiar acronym for Data Description Specifications) provides the source language to describe database, display, and printer files. When you create an externally-described file from DDS, OS/400 stores the file’s description in the file object. High-level language (HLL) compilers can subsequently use the file’s description to generate record structures for I/O operations. That raises the companion question: Is HLL “native” database I/O also “dead?” Should you start using SQL instead of built-in RPG or Cobol I/O operations to access your database?
I think the answer to these questions is yes, you should use SQL for your iSeries database definition and access. The reasons are simple:
- IBM has essentially stopped enhancing DDS and “native” database I/O operations.
- The entire industry uses SQL for database definition and access.
- SQL is generally more functional than DDS and “native” database I/O operations.
By using SQL, you put your applications on a more solid footing both on the iSeries and across other platforms. Also, if you plan to have Web applications, you’ll find SQL is the language required by both the JDBC and ODBC standards that are part of most Web application architectures.
The major disadvantages of using SQL instead of DDS are:
- SQL/400 doesn’t provide anything comparable to the DDS field reference feature.
- a few specific features are available only in DDS.
- in some situations, “native” I/O is significantly faster than SQL for iSeries database access.
And, of course, you or your staff may have to spend some time learning SQL if you’re not already familiar with it.
IBM has done a truly exceptional job of making an incremental transition to SQL as easy as possible on the iSeries, but it does require planning. You can use SQL to access most physical and logical files created with DDS, and you can use built-in HLL I/O operations to access most tables and views created with SQL. You can also use DDS to create logical files over SQL tables, and you can create SQL views over physical files that were created with DDS.
This OS/400 capability means you can generally use SQL for database access in any new parts of an application you create. You can also replace built-in I/O operations when you make major revisions to existing applications. In both cases, the SQL can access most existing files created with DDS.
Using SQL for database definition requires more thought. SQL is, of course, the right choice for creating new tables and views that will be accessed only by SQL statements. For most existing (or new) physical files that will be accessed by built-in I/O operations, you can generally use the SQL Create Table statement instead of physical file DDS and still access the data with existing programs. (One hurdle you have to overcome is that SQL tables normally have the same record format name as the underlying file name, which RPG doesn’t allow. To satisfy the RPG requirement, you can use an SQL Rename statement to change the table name, but not the record format name, after you create the table.)
SQL views don’t have keyed access paths, so replacing keyed logical files with views isn’t usually viable when an application uses built-in I/O operations to access the logical file. You’ll have to replace the built-in I/O operations with SQL first.
There’s no need to immediately rip out all the DDS and “native” I/O in your current applications. But you should be developing competency in SQL and using SQL wherever feasible in new applications or major application revisions. Whether or not DDS is “dead”, SQL is very much alive and is the future of the iSeries database.
Paul Conte is co-author with Mike Cravitz of SQL/400 Developer’s Guide (29th Street Press) and author of Database Design and Programming for DB2/400 (NEWS/400 Books). Paul is also co-author with Mike Otey of SQL Server 2000 Developer’s Guide (Osborne/McGraw-Hill).