Re: modernize problem with DDS logical

On 19-Dec-2014 11:32 -0600, Dale Janus wrote:

We are slowly modernizing our database and programs as business
needs arise. We would like to leave some of our old RPG III programs
alone since they work and will eventually be replaced. We are trying
to do this by using DDS logical files over the newly modernized data
base.

We modernize the database with DDL in ops navigator and add new
fields to the end like real dates, identity columns, sometimes a time
stamp, and new stuff with long field names. We keep the original 6
character field names on the existing fields as system name. Any new
fields get both a long name and a system name that is longer than 6
characters. Then we use the old physical file name as a logical
file. The new physical, since created with DDL, does not have any DDS
specs. (AROPENSY in the example below)

We then modify this new DDS logical (that used to be a physical) to
include only the old fields with each old field name listed. And of
course the key, which has not changed and is an old field. New
fields are not listed in the DDS. sample:

A* RECORD FORMAT LEVEL
A UNIQUE
A R ARREC PFILE(AROPENSY)
A*
A ARCODE
A ARPRFX
A ARMNTH
A ARSNBR
A ARCMCD
A ARSUPL

Seems the K-spec to define the key is missing.? Does an LF with a file-level UNIQUE keyword actually compile when there is no Key; should fail with CPD7909 "FIFO, LIFO, FCFO, or UNIQUE keyword requires key field."?

The RPGIII programs get compiled for the new logical and some but
not all programs got errors.

We get errors like: External-Field-Name entry longer than 6 or
Message . . . . : The record format contains DATE/TIME/TIMESTAMP
fields. DATE/TIME/TIMESTAMP fields ignored.

When we run DSPFFD on the logical, it shows all the fields, the old
with old names, but also the new fields longer than 6 characters that
RPGIII does not like.

That seems to imply that the Create Logical File (CRTLF) did not effect what was requested, according to the above\included DDS [which has errors; perhaps does not reflect accurately what was used for the DDS source per the SRCFILE() SRCMBR() specifications on the CRTLF request?

How can I create a logical file with only the old field names yet
points to my new modern database defined by DDL?

The given DDS source for an LF [without the UNIQUE or including a K-spec] should include only the "old field names" just as coded.

Do I have to create views in DDL?

The SQL CREATE VIEW statement is Data Definition Language (DDL) and that is the only way to create an SQL VIEW. The Database Logical File (LF) that is not a VIEW, can be created with the CRTLF using DDS source. An alternative DDL that effects the creation of a logical file [as a logical _view_ of the data; lowercase to distinguish from a VIEW] of the data [though not in other databases] is the SQL CREATE INDEX statement.

Is it not possible to mix DDL with DDS?

The DDS and DDL can be mixed in the sense that the /objects/ created by each, can refer to the objects created by the other. Of course the definitional languages [DDL and DDS] are distinct, such that for any one object being created, either one is used in a request to effect the creation of the object in its domain; the SQL domain with SQL DDL or the non-SQL domain wherein the DDS is effectively all there is available.

I was hoping to ease into some of these new features, without having
to change every program all at once. So far, I am not doing so well.
Yes, I realize I should just change everything, but there is never
enough time.

Should be possible to effect what is described as the desired effect. Seems, figuring out why the effect of the CRTLF does not match what was shown with the Display File Field Description (DSPFFD), is paramount for moving forward.