Re: *Max4GB or *Max1TB

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