Re: Speed in Reading

[Luis Rodriguez <luisro58@xxxxxxxxx>]

You are right, of course. Haven't created a DDS file in a long time, and
mixed up the  terms...

My apologies for the confusion.


Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries


On Fri, Jun 4, 2010 at 4:16 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

> Not quite right...
>
> It doesn't matter if you use SQL or RPG RLA to read or write the file.
>
> What matters is if you use SQL DDL or DDS to create the file in the first
> place.
>
> HTH,
> Charles
>
> On Fri, Jun 4, 2010 at 4:26 PM, Luis Rodriguez <luisro58@xxxxxxxxx> wrote:
> > You are right, SQL checks during Writes, RPG native I/O checks during
> reads.
> > I like to refer people to this nice Dan Cruikshank paper: "Modernizing
> > Database Access The Madness Behind the Methods ",. You can find it at:
> http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf
> > HTH,
> >
> > Luis Rodriguez
> > IBM Certified Systems Expert — eServer i5 iSeries
> >
> >
> > On Fri, Jun 4, 2010 at 3:31 PM, Bryce Martin <BMartin@xxxxxxxxxxxx>
> wrote:
> > > I'm not sure what SETOBJACC is or what effect it has on reading a
> file...
> > > but....
> > >
> > > Doesn't RPGLE do its checks on Read as opposed to SQL that does checks
> on
> > > Write?  So as I've heard it the general idea goes that reading with SQL
> > > should be faster than RPGLE but writing would be the other way around.
>  So
> > > why not write and SQL to read the data and only the fields you need
> (which
> > > is proven to be faster than specifying SELECT * FROM)?  You can fetch
> more
> > > than one row at a time I do believe and I think would perform better
> than
> > > a single record by record read using native I/O.
> > >
> > > Then again, if I have the idea of when the i/o checks happen respective
> to
> > > read vs. write then everything I said above is for naught!
> > >
> > >
> > > Thanks
> > > Bryce Martin
> > > Programmer/Analyst I
> > > 570-546-4777
> > >
> > >
> > >
> > > Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx>
> > > Sent by: rpg400-l-bounces@xxxxxxxxxxxx
> > > 06/04/2010 02:12 PM
> > > Please respond to
> > > RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
> > >
> > >
> > > To
> > > "'RPG programming on the IBM i / System i'" <rpg400-l@xxxxxxxxxxxx>
> > > cc
> > >
> > > Subject
> > > Speed in Reading
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi all,
> > >
> > > Lately I've been dealing with a new client that has a high volume of
> data
> > > for us to process, so I've been looking at various ways to get things
> > > moving a little faster.
> > >
> > > I believe I've successfully implemented the use of SETOBJACC with the
> help
> > > of Chuck Pence & Mark Waterbury (thanks guys).
> > >
> > > Now, this may be grasping at straws, but in a high data volume
> situation,
> > > should I see any benefit in restricting the fields in a LF to only the
> > > fields used by the program?  (In essence, going from record length of
> 438
> > > to 138.)  My brain says, "yes," but the logic under-the-covers may not
> > > match the logic my brain uses to come to its conclusion.
> > >
> > > I'm also curious about RPG blocking. This question mainly goes out to
> > > people using file encapsulation service programs, but is obviously open
> to
> > > anyone to answer.  I have a file wrapped up in a service program.  This
> > > service program pretty much handles all I/O operations for the file.
>  Now,
> > > if all I want to do is loop through the file, it's not going to block
> read
> > > because it has operations such as READE in the service program.  I wish
> > > block-reading would be determined at run-time (again, a wish without a
> > > full understanding of the compiler does its thing).  I'm curious how
> > > people have circumvented this limitation?
> > >
> > > Thanks,
> > > Kurt Anderson
> > > Sr. Programmer/Analyst
> > > CustomCall Data Systems
> > > --
> > > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> > > list
> > > To post a message email: RPG400-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > > or email: RPG400-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/rpg400-l.
> > >
> > >
> > >
> > > --- This message (including any attachments) is intended only for the
> use
> > > of the individual or entity to which it is addressed and may contain
> > > information that is non-public, proprietary, privileged, confidential,
> and
> > > exempt from disclosure under applicable law. If you are not the intended
> > > recipient, you are hereby notified that any use, dissemination,
> > > distribution, or copying of this communication is strictly prohibited.
> If
> > > you have received this communication in error, please notify us and
> destroy
> > > this message immediately. ---
> > > --
> > > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> > > To post a message email: RPG400-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > > or email: RPG400-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/rpg400-l.
> > --
> > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.