|
Hi, Alan, I don't think you need a userspace with 16MB because SQL/Database itself blocks in 32K. In this way fetching multiple rows into a MOD or array data structure that is close to 32K and repeating this process several times, may have the same effect. Mit freundlichen Grüßen / Best regards Birgitta Hauser "Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown) "If you think education is expensive, try ignorance." (Derek Bok) "What is worse than training your staff and losing them? Not training them and keeping them!" -----Ursprüngliche Nachricht----- Von: rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx [mailto:rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx] Im Auftrag von Alan Campin Gesendet: Tuesday, February 20, 2007 23:46 An: rpg400-l@xxxxxxxxxxxx Betreff: RE: I need faster SQL <snip> Why need a user space, apperently you are procesing the occurences of the DS. Using the user space in this regard is overkill. </snip> Your alternative. Allocate 16MB of memory? You will note I said "if you are reading in a lot of records". If the average read only gave you a few records, yes user space is an overkill. If a single read is going to give dozens or hundreds of records or you simply don't know what is being returned, the user space makes a lot of sense because you don't have to manage the storage. The operating system takes care of it for you and the performance is superb. The IBM manuals make it clear that whenever possible do a multiple record fetch. The only other thing that I can say is I have seen huge differences in programs where I read the data into a user space. At a previous company I was working at I was taking RPG/ILE stored procedures with call times of over a minutes to sub-second times using this technique and others.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.