Re: *Max4GB or *Max1TB

Sure, Ryan. I meant that SQL is not optimized - my pronoun did not point to the 
right object. ODBC does let you read a row at a time from a result set, but 
this does not make the fastest way to do that. ODBC is a front-end, basically, 
to SQL, and SQL is best with sets of records, not single records like the 
native IO we use in RPG. Hope that clarified what I meant.   ;-)

Vern

-------------- Original message -------------- 
From: "Ryan Hunt" <ryan.hunt@xxxxxxxxxxxxx> 

> 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? 
> 
> 
> wrote in message 
> news:041020061936.16276.443AB3B7000DB75E00003F942207020853099D0A0D030E0890@comca
>  
> st.net... 
> > 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