× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



When I put the DDL in the qddssrc, I use one line for each field to make it easier to read. Also, it is easy to keep up to date when you use ALTER TABLE.

Try DMPOBJ, you will probably see some difference there.


On 02/24/2017 06:19 PM, Steinmetz, Paul wrote:
I created a table.

CREATE TABLE QGPL/PTFTBL (PRODUCT CHAR ( 7) NOT NULL WITH DEFAULT,
OSRELEASE CHAR ( 6) NOT NULL WITH DEFAULT, PTF CHAR ( 7) NOT NULL
WITH DEFAULT, PKG CHAR ( 6) NOT NULL WITH DEFAULT, AVAILDATE DATE
NOT NULL WITH DEFAULT, MRIFEATURE CHAR ( 4) NOT NULL WITH DEFAULT,
REPLACEDBY CHAR ( 7) NOT NULL WITH DEFAULT, CATEGORIES CHAR ( 3)
NOT NULL WITH DEFAULT, ABSTRACT CHAR ( 75) NOT NULL WITH DEFAULT)
Table PTFTBL in QGPL created but was not journaled.

Also create a PF using DDS.

A R PTFIMP TEXT('PTF IMPORT FILE')
A PRODUCT 7A COLHDG('PRODUCT')
A OSRELEASE 6A COLHDG('OS RELEASE')
A PTF 7A COLHDG('PTF')
A PKG 6A COLHDG('PACKAGE')
A AVAILDATE L COLHDG('AVAILABLE DATE')
A MRIFEATURE 4A COLHDG('MRI FEATURE')
A REPLACEBU 7A COLHDG('REPLACE BY')
A CATEGORIES 3A COLHDG('CATEGORIES')
A ABSTRACT 75A COLHDG('ABSTRACT')

When comparing the two objects, using WRKOBJ, you can't tell if the PF was created using DDS or DDL, is this correct?
On the surface, they "appear" to be the same.

Only if you DSPFD, can you see the extra line for those created vis SQL DDL vs DDS.

Data Base File Attributes
Externally described file . . . . . . . . . : Yes
SQL file type . . . . . . . . . . . . . . . : TABLE
File level identifier . . . . . . . . . . . : 1170224155740

Data Base File Attributes
Externally described file . . . . . . . . . : Yes
File level identifier . . . . . . . . . . . : 1170224105523

Is this correct?

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: Friday, February 24, 2017 4:01 PM
To: Midrange Systems Technical Discussion
Subject: RE: Storing source as DDL instead of DDS

Are those DDS LF's? The LF's are still OK if you insert columns in the underlying PF?



-----Original Message-----
From: Mike Cunningham [mailto:mike.cunningham@xxxxxxx]
Sent: Friday, February 24, 2017 2:49 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Storing source as DDL instead of DDS

We do all of our "classic" database IO access through logical files with one logical file unique to each application. Each logical file only has the fields that the application needs to use. So added a new field anywhere in the physical has no impact on any application because the application does not even know it exists until you also change the logical file used by that application.

SQL SELECT access to the database doesn’t care about the sequence of fields in the physical

email.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD


-- Este e-mail fue enviado desde el Mail Server del diario ABC Color -- -- Verificado por Anti-Virus Corporativo Symantec --

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.