× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: subfile processing: SFLSIZ=SFLPAG (was: readc & sflnxtchg)
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Sat, 13 Feb 99 10:06:40 +1100

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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.