|
Hello Buck and Bruce, Last I knew (and I don't believe it has changed): 1) The PAG is always important 2) The system will try to keep the subfile in the PAG until it exceeds 32K then it will move it to a separate space. Now with regard to 2 above. The DDS compiler uses the SFLSIZ and record length of the subfile to decide whether to build the subfile in the PAG or not. In the case of fixed SFLSIZ and no ROLLUP or SFLSIZ=SFLPAG the compiler generates a subfile which is loaded in the PAG if less than 32K and loaded outside the PAG if greater than 32K. In the more common case of SFLSIZ=SFLPAG+1 and ROLLUP specified the compiler will usually determine that the SFL should go in the PAG. However, these subfiles grow as the user scrolls through more data. In this case the system starts with the SFL in the PAG since it is usually less than 32K initially and it stays in the PAG until it reaches 64K in which case it is unceremoniously tossed out to a separate space. The system keeps it in the PAG while it is 32K<size<64K because the overhead of leaving it in the PAG is less than moving it out. After it exceeds 64K the system decides the SFL is being moved anyway. Now as to SFLSIZ=SFLPAG here are my thoughts: SLFSIZ=some fixed value and ROLLUP not specified -- otherwise known as a 'set-and-forget' subfile. The program simply fills the subfile and lets OS/400 handle scrolling. Useful when the programmer "knows with abolute certainty" that a maximum of n records can possibly be displayed. SFLSIZ=SFLPAG*n where 'n' is the expected usual number of records. The programmer fills the subfile with the 'normal' number of records. Scrolling backward is handled by the OS. Scrolling forward is handled by the OS until there are no more records in the SFL whereupon the program gets control and can add more records to the SFL. Useful when the total number of records requested is less than 9999 (the maximum allowed in a subfile with RPG/400 -- I wonder if this has changed with RPG IV? Although it is really a DDS limitation) SFLSIZ=SLFPAG used when an unknown number of records may be requested by the user. The programmer handles scrolling backwards and forwards. Generally the SFLSIZ=SFLPAG*n is to be preferred over SFLSIZ=fixed-value because there is minimal additional code to handle the ROLLUP key and you'll never be stuck with a SFL full error or records not available to the user -- except at the 9999 limit. SFLSIZ=SFLPAG should be reserved for those few instances where the user may actually want to scroll through 7 million records. In the last two cases a position-to field should always be provided and in my opinion whenever position-to is used SFLSIZ=SFLPAG should also be used. This is because the user will not be able to roll back after position to the new first page. Sloppy and irritating to the user. Note: UIM gives the ability to have a 'subfile' or list containing 16MB of data if the 9999 limit of a SFL is too low. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» //--- forwarded letter ------------------------------------------------------- > X-Mailer: Mozilla 4.05 [en] (Win95; I) > MIME-Version: 1.0 > Date: Fri, 12 Feb 99 12:13:28 -0500 > From: "R. Bruce Hoffman, Jr." <rbruceh@ibm.net> > To: MIDRANGE-L@midrange.com > Reply-To: MIDRANGE-L@midrange.com > Subject: Re: subfile processing: SFLSIZ=SFLPAG (was: readc & sflnxtchg) > > > > Buck Calabro/commsoft wrote: > > > The "expanding" subfile is my preference, too but I make SFLSIZ equal to > > the number of pages I expect the average user to load - typically 3 times > > SFLPAG. I recall some advice from my dusty memory that the system > > allocates SFLSIZ records at a time in the PAG. Is this still true, and > > more importantly, is this still relevant? > > This is (IMHO) the correct way. Is it still relevant? Yes if performance >is an > issue. Can you measure the difference on an underutilized high performance > AS/400? Not likely, but at some future point in time, that box is likely to >be > more heavily utilized and since we are talking about an interactive >environment, > it is better to plan ahead, than to go back and figure out which subfile > techniques are causing the customer to order a new box for performance > considerations. > > -- > =========================================================== > R. Bruce Hoffman, Jr. -- IBM Certified AS/400 Administrator > > -- The sum of all human knowledge is a fixed constant. > It's the population that keeps growing! +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.