On 2/11/2017 10:12 AM, Nathan Andelin wrote:
The physical files (aka physical database objects) created via DDS are
essentially identical to the ones created by DDL.
The problem is how one defines 'essentially'.
The system I work on - in fact, ALL the systems I ever worked on - has
DDS-defined files which contain decimal data errors. For systems like
these, switching the file definition from DDS to DDL is hazardous. Here
is a simplified example:
QDDSSRC(DDE):
A R DDERCD
A ID 9B 0
A NUM1 9S 0
A CHAR1 20
QRPGLESRC(DDE):
* Test decimal data errors between DDS and SQL
h debug dftactgrp(*no) actgrp('QILE')
// 1) Create the DDS table DDE
// 2) Retrieve the DDL with IBM i Navigator
// 3) Change 'DDE' to 'DDL'
// CREATE TABLE BUCK.DDL (
// "ID" INTEGER NOT NULL DEFAULT 0 ,
// NUM1 NUMERIC(9, 0) NOT NULL DEFAULT 0 ,
// CHAR1 CHAR(20) CCSID 37 NOT NULL DEFAULT '' )
// RCDFMT DDLRCD;
// 4) Create this DDL table
// Now have two essentially identical tables; one DDS and one DDL.
// Let's insert some data and watch what happens.
fdde o a f 33 disk
fddl o a f 33 disk
*inlr = *on;
odde tadd lr
o 19 '123459789'
o 33 'Left out the binary
fld'
oddl tadd lr
o 19 '123459789'
o 33 'Left out the binary
fld'
You'll find that the DDS-described table 'insert' works flawlessly,
despite the 'ID' field not being output. For the sake of this example,
let's say that this field will be updated during a later step in the
batch process. But for now, the record is added with blanks in columns
1 - 4.
You'll also find that the DDL-defined table /will not allow/ the record
to be inserted. The job throws CPF5029 Data mapping error on member
DDL. Followed by Error message CPF4572 appeared during CLOSE (C G D F).
To summarise, going from CRTPF to CREATE TABLE for the exact same file
layout can and does result in my application going from 'working the
same as it has for 30 years' to 'will not run.'
So when someone says that DDS and DDL/SQL are like two windows into the
same database, I almost agree.
midrange.com
