Re: SFL Load - SQL vs. LF -- MIDRANGE-L

I must admit to being a tad confused by the Data validation on input - I wasunder the impression that this was under the control of the program issuingthe read.

For example, if you internally describe a file in RPG and simply define therecord as a single field, will the fields be validated by the DBM on input?Is it that no validation is performed or is validation performed but theerrors ignored because the file is internally defined?

I am with you on the schema/collection issue, Vern. It is fine in adevelopment environment but is very much against the grain for production.It would be nice to have CREATE SCHEMA... USING JOURNAL...


Paul

----- Original Message -----From: "Vernon Hamberg" <vhamberg@xxxxxxxxxxx>

To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, September 09, 2005 3:23 AM
Subject: RE: SFL Load - SQL vs. LF

Data validation code is the part of the database code that checks whetherdata is valid - you know, like decimal data errors. According to what issaid below, the extra overhead is added on reads in DDS-based files(non-SQL), on the writes on DDL-based files (SQL). If, in fact, your appsdo more reads than writes, it could be somewhat advantageous to change toSQL-built tables. But I think the jury is still out, and you should useDSPFD on the various files to see what the actual behavior has beenhistorically - it's all in there. Remember, updates are a combination of aread and a write, basically, so add that to both the number of reads andthe number of writes, I think.
All this talk of converting to SQL-based tables does not take into accountthe issues around the journals associated with SQL collections (read thatto mean a library, the various SYS* views in said library, and attendantjournals and journal receivers). If you need to copy them to a differentlocation, it is not pretty. There have been several posts here about this,and Kent Milligan has a white paper on this - I forget the link, trydigging around at www.iseries.ibm.com/db2 - I find that SQL Server hassome really nice stuff in its RESTORE DATABASE... functionality, but thenit doesn't use journals, AFAIK, for transaction processing (commitmentcontrol to us iSeries folks).
I think we need something from IBM to handle this better. Maybe a way toput new library references into the journal receivers, and into the SYS*views - I don't know. They're smart folks and ought to be able to find away for moving/copying a collection not to be so hard. I mean, they wroteCHGPF over a source member, right?
Whew!!!
Vern

At 01:11 PM 9/8/2005, you wrote:
Is there anyone who can explain this? Data Validation code!  Or point to
the original article?

Thanks
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Wednesday, September 07, 2005 4:22 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: SFL Load - SQL vs. LF

IBM has changed the data management rules for files created via DDL,
which
effective improves DB thruput for all applications using the file.
Performance gains come from where IBM has chosen to implement the data
validation code.  Under DDS rules, data is validated when it is read
from
the disk, where DDL moves the validation to DB writes and updates.

The theory is that a typical application will read data much more than
it
writes data.  If we validate on write, then we've reduced IO overhead.

iSeriesNetwork had an article about this.....

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of James H H Lampert
Sent: Wednesday, September 07, 2005 1:09 PM
To: Midrange Systems Technical Discussion
Subject: Re: SFL Load - SQL vs. LF


Billy Rowe <billyrowe@xxxxxxx> wrote:
> No matter which presentation method you decide to you,
> definitely create the tables/indexes/views with SQL.

Why?