Chapter 22: Data Description Specifications

Overview

The abbreviation DDS stands for Data Description Specifications. DDS is a programming language that originated with the System/38. DDS is used to describe records in files by giving a name to the record and listing all the fields that will be considered part of the record. DDS enables the eServer i5 to have a relational database that is fully integrated with the system. The i5 also supports SQL for database definition and manipulation, but that interface is not discussed in this chapter.

No matter what language you use to write your programs, the system always knows the record layout of your data files if they were defined using DDS. And, as you will see, many tools are available to you if your data files are externally defined using DDS.

There is an alternative, however. You can also describe the file inside each program that uses it. Older systems often describe files this way because no other choice exists. The problem with program-described files is that they have a tendency toward lack of standardization. For example, the first field of the file (which holds a vendor number) may be called VNDNBR in one program, VENDOR in another, and VENDNO in a third.

Because each program must contain the entire definition for the record, the effort is multiplied by whatever number of programs use the same file. Although using compiler directives such as /COPY in RPG alleviates the problem, files created with DDS are fully defined to the system. The system knows what fields make up the record, so it can make use of this definition everywhere a file is used. For example:

• CL programs have no compiler directive to copy source code (like /COPY in RPG). If you use a file in CL, you must declare each field separately or at least know its absolute position within the record. If the file were created with DDS, however, the CL program already knows the definition of the file.

• Products and features such as Query/400, SQL/400, OPNQRYF, and Query Management also can make use of the definition of the file provided by DDS. Without this file definition, it would be impractical (to say the least) to use any of these products (except Query/400, which can use IDDU file definitions).