Hello Jerry,

Am 25.11.2019 um 15:01 schrieb Jerry Adams <midrange@xxxxxxxx>:

Are you sure about there not being a limit on the number of records for a page-at-a-time subfile?

Yes, because you only load just so many records into the SFL as there are "lines" in the DSPF (SFLSIZ = SFLPAG). Questionable is if you want your customers to press Rollup a thousand times to get to the desired record. ;-)

I have a recollection of a colleague working on a program that blew off at 9999, and all of our subfile programs used PAT subfiles.

Sorry, but then that's not a paged SFL but a load-all (or load-and-expand). The *absolute* number of entries in an SFL is limited to 9999. And if I had to scroll through 9999 records to find the desired entry, I'd have a serious talk with the application programmer. ;-)

On the other hand, wouldn't a Load All (expandable) subfile blow off on the first EXFMT? (Full disclosure: I've
never tried it to see what would happen.)

No, because with any keypress to scroll down, there will be just SFLPAG records loaded again. This loading takes place just with every keypress, until end of records from the data source (PF, SQL) or until the big bang when the SFLRCDNBR reaches 9999. :-) As you told, you need to press that key a *lot* of times.

Anyway, I always use Load All subfiles; they are (for me, anyway) much easier to code. I only tested for the 9999 limit once in > 20 years. ("Seriously? You're going to page through >9000 records?")

That's what I meant.

On a side note, how to you implement "Position to" in a senseful way with a load-all? CHAIN in a SFL is limited to the RRN as Key value. One could use a data queue or a separate table to have a translation from primary key (search term in Position-to) to the associated RRN and thus one can set the SFLRCDNBR to that value and jump to the record in question. But this seems not very elegant to me. What do you think?

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc

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