Re: Replacing Traditional I/O with SQL

Thanks Chuck and Micheal,

So issues with performance would be more on my decision of when to use SQL
or Traditional I/O or how I use them? Whether the data is on a DDS or DDL
defined file is not the issue? So, yes we possibly would see better
performance by moving to DDL or using INDEX, but until then that shouldn't
stop me from using SQL in my programs when I feel useful?

Thanks,

Jeff



From: cobol400-l-request@xxxxxxxxxxxx

To: cobol400-l@xxxxxxxxxxxx

Date: 01/26/2011 12:59 PM

Subject: COBOL400-L Digest, Vol 9, Issue 10






Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."


Today's Topics:

1. Re: COBOL400-L Digest, Vol 9, Issue 9 (Chuck Landress)
2. Re: Replacing Traditional I/O with SQL
(MichaelQuigley@xxxxxxxxxx)


----------------------------------------------------------------------

message: 1
date: Tue, 25 Jan 2011 13:15:39 -0500
from: Chuck Landress <clandress@xxxxxxxxxxx>
subject: Re: [COBOL400-L] COBOL400-L Digest, Vol 9, Issue 9

Using SQL to access DDS defined files shouldn't degrade performance
seriously but you will see a performance improvement from your programs
using both SQL and record level I/O if you redefine them with DDL. One of
the reasons for the performance increase is that indexes are processed in
larger blocks when files are defined using DDL.

Be sure you have indexes built with the keys you're using to access the
data
or performance will suffer on files with large record counts.

Chuck Landress, PMP
678-469-2326

A creative man is motivated by the desire to achieve, not by the desire to
beat others.
- Ayn Rand





On Tue, Jan 25, 2011 at 1:00 PM, <cobol400-l-request@xxxxxxxxxxxx> wrote:

Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."


Today's Topics:

1. Replacing Traditional I/O with SQL (Jeff Buening)


----------------------------------------------------------------------

message: 1
date: Tue, 25 Jan 2011 09:16:32 -0500
from: Jeff Buening <JeffBuening@xxxxxxxxxxxxxxxxxxx>
subject: [COBOL400-L] Replacing Traditional I/O with SQL


For people that have replaced traditional I/O including Read and Writes
with SQL, was there a significant hit on performance if the underlying

file

structure was still DDS? Just wondering if not even worth doing the
embedded SQL, unless we switch the file to DDL.

I have written some new programs that only do some selects and write to a
print file and have been fine still DDS structure. My concern is I start
replacing traditonal I/O Reads and Writes and I am going to see this huge
impact unless we switch to DDL first. Or this is my impression I have
gotten online. Does my concern seem valid or has anyone done this and

the

impact not as bad as I think?


Thanks,

Jeff



------------------------------

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) digest

list

To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



End of COBOL400-L Digest, Vol 9, Issue 9
****************************************

------------------------------

message: 2
date: Tue, 25 Jan 2011 13:23:15 -0500
from: MichaelQuigley@xxxxxxxxxx
subject: Re: [COBOL400-L] Replacing Traditional I/O with SQL

Indexes built in DDL use a larger blocking. This gives them better
performance, but from what I understand that holds true whether using
traditional I/O or SQL to access the data. I've not seen nor heard of a
big performance hit using SQL over DDS-defined files.

Michael Quigley
Computer Services
The Way International
www.TheWay.org

cobol400-l-bounces@xxxxxxxxxxxx wrote on 01/25/2011 01:00:10 PM:

----- Message from Jeff Buening <JeffBuening@xxxxxxxxxxxxxxxxxxx> on
Tue, 25 Jan 2011 09:16:32 -0500 -----

To:

cobol400-l@xxxxxxxxxxxx

Subject:

[COBOL400-L] Replacing Traditional I/O with SQL


For people that have replaced traditional I/O including Read and

Writes

with SQL, was there a significant hit on performance if the underlying

file

structure was still DDS? Just wondering if not even worth doing the
embedded SQL, unless we switch the file to DDL.

I have written some new programs that only do some selects and write to

a

print file and have been fine still DDS structure. My concern is I

start

replacing traditonal I/O Reads and Writes and I am going to see this

huge

impact unless we switch to DDL first. Or this is my impression I have
gotten online. Does my concern seem valid or has anyone done this and

the

impact not as bad as I think?


Thanks,

Jeff

------------------------------

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



End of COBOL400-L Digest, Vol 9, Issue 10
*****************************************



************************************************************************************

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************