× 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.



That makes sense

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Luis Rodriguez
Sent: Wednesday, February 02, 2011 10:47 AM
To: Midrange Systems Technical Discussion
Subject: Re: PF Compiled Files with Dictionaries vs. SQL-Created Tables

Mike,

ADDPFCST adds a key to your PF, akin as specifying a K-spec in your DDS. In the example Rob mentioned, it would be something like:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(MYLIB/USROUTFILE) ADDPFCST FILE(MYLIB/USROUTFILE) TYPE(*UNQCST) KEY(UPUPRF)

So in your RPG program you would specify USROUTFILE.

HTH,

Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries
--



On Wed, Feb 2, 2011 at 10:42 AM, Mike Cunningham <mike.cunningham@xxxxxxx>wrote:

So ADDPFCST actually creates a logical file? What do you use on the "F"
spec in RPG in this example?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 02, 2011 9:51 AM
To: Midrange Systems Technical Discussion
Subject: Re: PF Compiled Files with Dictionaries vs. SQL-Created
Tables

You're right, referential integrity is not supported by DDS. You can
add it after the fact with ADDPFCST. But remaining with DDS and using
ADDPFCST is dangerous because it implies some sort of MAKE tool and
when you get that big pay raise and promotion with a move to another
plant and that new hire with 20 times of 1 years experience of i comes
in to replace you he will just see the DDS and try compiling that.

ADDPFCST is cool for adding keys to output files. DSPUSRPRF followed
by ADDPFCST and boom, traditional RPG can do a CHAIN by user profile.
No need to create a DDS LF. There are solutions to workaround format
level checks after your os upgrade you need to be aware of.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jason Abreu <jason.abreu@xxxxxxxxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 02/02/2011 09:05 AM
Subject: Re: PF Compiled Files with Dictionaries vs. SQL-Created
Tables
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Isn't referential integrity one feature supported by DDL and not by DDS?
I can't say I've ever seen a foreign key constraint in a DDS source file.

Jason Abreu
Abreu Innovations, Inc.
jason.abreu@xxxxxxxxxxxxxxxxxxxx
http://www.abreuinnovations.com/

On 2/2/2011 8:20 AM, Vern Hamberg wrote:
I found that the website listed for NiceSQL seems not to come up
today - it's been years since I tried. The product is downloadable -
haven't tried to buy it lately - CNet has it for download - just
google for NiceSQL if interested.

On 2/2/2011 6:53 AM, Vern Hamberg wrote:
Chuck

There are SQL formatting apps out there - I use NiceSQL - that take
any statement and "pretty-print" it. Very nice for readability.

NiceSQL is very nicely supported - several years ago the developer
even added stuff for AS/400 - was it that long ago? Maybe it was iSeries.

Anyhow, 20 bucks - free to try. It's been good for me, quite
satisfied
I
am. Simple example -

before:
SELECT DISTINCT CR.COLOUR_ID, DBO.GETRECIPE(CR.COLOUR_ID,
CR.RECIPE_ID, CR.RECIPE_VERSION) AS RECIPE FROM PRODUCT P,
COLOUR_RECIPE CR WHERE (CR.COLOUR_ID = 11000001005 AND P.STATUS_ID
= 'P')

after:
SELECT
DISTINCT
CR.COLOUR_ID,
DBO.GETRECIPE(CR.COLOUR_ID, CR.RECIPE_ID, CR.RECIPE_VERSION) AS
RECIPE FROM PRODUCT P, COLOUR_RECIPE CR WHERE ( CR.COLOUR_ID =
11000001005 AND P.STATUS_ID = 'P'
)

Vern

On 2/1/2011 7:05 PM, CRPence wrote:
On 2/1/11 1:13 PM, hockchai Lim wrote:
I know I'll probably get blasted for saying this. But I must
admit that I've never been a big fan of using SQL to create
tables. I understand that using SQL will allow me to create table
with feature that is not supported by DDS (such as Identity
column). But that is IBM's fault not mine :). The main reason I
didn't like SQL is because it strains my eye to read that SQL
create table statement. DDS is just much neater and easier to read.

And DDS even supports some features which SQL does not. I find
little value to change from DDS to use SQL DDL for existing
database *FILE objects, without some obvious need to access some
new feature provided by the TABLE; e.g. either data types
supported only in the
SQL,
or better integrity for numeric data. Without any specific goal to
be achieved by changing, what point is there in change except
change for the sake of change? That is, change without
justification is intuitively, not justified. Best to understand
what will be lost and what will be gained by the change, to avoid
remorse for having made
the
jump, and even more regrets for having to move back in order to
"recover" from the first change. Changing "just because" to using
SQL DDL versus DDS is, for lack of a better word, daft.

While many DDS PF source may be very clean and concise, I mostly
disagree that DDS specifications would be generally easier to read
than
the SQL, except to those who have some experience coding to
fixed-format
source specifications. I think difficulty in reading the SQL DDL
would probably be caused mostly by poor formatting of the
statements, exacerbated by [typically self imposed] limitations to line length.
FWiW the LABEL ON statement for column headings and text being
moved outside the functional field definitional attributes could
be
considered
by many to be much nicer than having them intermingled and even
line-wrapped from and back into the functions area of a DDS source
member.

Regards, Chuck
--
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.


--
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.

--
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.


--
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.


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.