Re: 20 years ago

Hello Frank,

Am 19.08.2022 um 00:09 schrieb Frank Kolmann <frank.kolmann@xxxxxxxxx>:

Hmmm. Depends how the code is written.

Exactly.

The thing about subfiles, especially big subfiles you could hit the 9999 row limit, so, I always coded coded big subfiles as SFLSIZ = SFLPAG, page at at time, performance was never slow.

Thanks for proving my point. In fact, I'd wonder a lot if an ordinary load-paged subfile is slow, because you only need to load roughly 13 to 16 rows from disk — if there is a 1:1 mapping of table to DSPF presentation fields. If extensive calculations or reads from secondary tables need to take place between each SFL WRITE you also can create a pretty slow 5250 SFL based application. :-)

I am guessing web essentially does page at a time.

Depends on how the code is written. :-)

In the olden days of HTML 3.2, screen size was completely a matter of the client. Remember, HTML was meant as a way of information presentation, and shares this basic idea with 5250 panel groups.

Until some "web designers" started to abuse HTML tables for introducing a "layout" on screen, and giving us these awful "best viewed with 1024x768" stickers. All of this came to an end with Apple creating the iPhones with a by default portrait screen and many different screen sizes with each model — and rendering that stuff obsolete. Sorry for digressing.

Because there is no concept of a screen size to basic HTML, the browser usually is presented with all data to be rendered in a single large table. It's up to the programmer to limit the number of table rows to a reasonable limit, just with a load-all SFL. Scrolling takes place entirely on the client, because all data already has been transferred and rendered on screen. Thus I'd say, this is more akin to a load-all subfile, but without a 9999 row limit. The limit is the amount of memory available on the machine running the browser application, and the patience of the user waiting for loading of the page to finally finish.

Contrary, if you look at the result of a search on eBay (for example), there is a setting how many entries you want to be presented per page. You choose a static allocation of "SFLSIZ" dynamically and you'll be shown at most that many entries per page. This is more akin to a load-paged SFL. You can't switch pages just by scrolling, though. You need to click "next".

Maybe I missed out some extended possibilities through the availability of Java Script and other client-side modern techniques. I have stumbled over "endless" web pages. The page with the first few entries is loaded quickly. If you scroll to the bottom, a static number of further records are loaded. This approach saves unneeded CPU cycles. And the user isn't forced to use the mouse to click "next". Smells like load-paged. The biggest drawback is that the user never knows how many records his query returns at large — if there has been a query at all. This in turn is how a load-all subfile feels for a user when not providing a scroll bar.

:wq! PoC