Re: *Max4GB or *Max1TB

Vern, you caught my interest with your statement, "and it [ODBC] is not
optimized for single record access the way native IO is".
DB2/400 is a secondary skill for me...can you elaborate on that?


<vhamberg@xxxxxxxxxxx> wrote in message
news:041020061936.16276.443AB3B7000DB75E00003F942207020853099D0A0D030E0890@xxxxxxxxxxxxxx
> As Pat says, lots of logicals will hurt. Every LF needs to update the
access path for every change to the PF, and all that takes up CPU cycles, no
matter what. One thing to do is what Pat suggests, to delay access path
maintenance (the MAINT parameter of CHGLF, I think) for LFs not used often
(End of year only processing, e.g.). Another technique is to maximize
sharing of access paths. I believe one way to do this is to SAVOBJ of all
the logicals, then delete them, then RSTOBJ - the system will restore things
with optimal sharing, IIRC. But others should chime in here, as it has been
a while. But non-sharing means extra DASD taken up, which eventually also
means poor performance.
>
> Sorry to repeat, but Centerfield's database/ASSESSMENT does a lot of this
heavy lifting for you. In addition to the database monitor parts, it
analyzes all this access path impact stuff, including file usage, and can
give you good recommendations. It used to include a live discussion with a
solid DB expert there, so it can be worth the few K it costs.
>
> As for ODBC, that is not an IBM idea - it is an open standard. ODBC is not
the culprit here, IMO. There is an excellent piece somewhere at
www.iseries.ibm.com/access on optimizing ODBC performance. A person can
really do it wrong - e.g., using the JET database engine in VB instead of
other methodologies results in deep doodoo performance problems. And
appropriate indexes always make it work better. Remember, ODBC is an SQL
access method, hence you suffer the black box problem that has been
discussed here before - and it is not optimized for single record access the
way native IO is. But an alternative might be to call a stored procedure
with the key values passed, then use native IO in the called program, which
will be lightning fast for that kind of thing. Of course, that is a
pie-in-the-sky answer here, I think.
>
> HTH
> Vern
>
> -------------- Original message -------------- 
> From: Pat Barber <mboceanside@xxxxxxxxxxxxxxxx>
>
> > Those large number of logicals is a real killer.
> >
> > I would look at a quick little study of how many have
> > little or NO activity and make the slow movers get
> > built when needed.
> >
> > I'm trying to imagine 250 different views of a single file.
> >
> > ODBC is certainly not the finest access method IBM has
> > dreamed up...
> >
> >
> > pnelson@xxxxxxxxxx wrote:
> >
> > > I've got a client experiencing performance problems with his software
> > > package. Many of the files have a huge number of logicals built over
them
> > > for various purposes. One has over 250 logicals and joined logicals.
All
> > > of the files are defined as having an acces path size of 4GB.
> > >
> > > This system is also being hit with lots of ODBC requests that were
> > > permitted to be built by the previous IT manager (windoze bigot).
> > >
> > > I know how to throttle back the ODBC impact, but should I change the
acces
> > > path size to 1TB for just the logicals or both the physical and its
> > > associated logicals to improve the overall performance?
> > >
> > > Thanks
> > -- 
> > 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.
>
>