Re: Display file cursor positioning -- can somebody clarify, and/or jog my memory?

From my past. An application was designed toperform a file search

based on potentially four selection terms. It was a load-all.
Machine was a B50. Application >may< not have been optimally
designed. I never thought it was, but it had been designed by my
boss. The more search terms given, the longer it took. Point is that
a load-all search could EASILY consume over 30 minutes routinely, at
least on that old piece of iron.

John McKee

On Thu, Nov 15, 2012 at 4:32 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

I tend to do only load-all subfiles. In my experience, even if the data
file is huge, some thoughtful design work up front gets load-all
subfiles down to a few hundred records. No scenario I can imagine would
have a user actually paging through 7000 records, let alone 70,000 or
700,000 records.

If the user is truly working randomly against a humongous file then a
page-at-a-time file works reasonably well since you are going to be
building the subfile repeatedly, anyway.

Anyway, that is an opinion, and I realize it is not even a popular
opinion. But it has worked well in every situation I have come up
against with the exception of the "'Shut up' the boss explained" scenario.

On 11/15/2012 4:20 PM, Carel Teijgeler wrote:

All I want to add, that this only applies for the first SFL page. IIRC
(and
many moons has passed since that day), when on the second or third oage
you
have to see which SFL age is active and do some calculations from that
point.
This was on a SFL with input capable fields.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR ***********

On 15-11-2012 at 15:07 Booth Martin wrote:

One alternate solution that might be useful with the subfile is to
always

advance the subfile screen so that the selected row, when

returned, is always returned at the top of the subfile (In some
operations

that could mean that the file's repositioning automatically

moves the records up so that the user finds the next desired record
already on

the screen.)

SF1TOP 4S 0H SFLRCDNBR(CURSOR *TOP)

That allows the problematic issue to become a feature. Maybe.

--
Booth Martin
802-461-5349
http://www.martinvt.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.