Re: 4 - subfiles -- MIDRANGE-L



Booth,

I think you're right in that we have to take a deep breath every once in a while
and "think outside of the box".  Too often I (you too?) get stuck on something
or just quickly run through a design in a boilerplate fashion without looking at
the possibilities.  Just yesterday, a colleague answered a long-standing bugaboo
of mine that involved using data queues.  I've known about data queues ever
since they were introduced, but over time, forgot to even think of using them.

The other thing regarding the load-all vs. page-at-a-time, Booth, is consistency
in the interface.  Your users obviously love that scroll bar in the subfile that
loads 2500 records.  Now, say you need to design another subfile application for
these same users, only this time the database is 50,000 records.  Now, (correct
me if I'm wrong) you can't even _use_ the scroll bar.  Well, I suppose you
could, but it would not be scaled correctly to the "real" bottom of the data /
subfile.

This kinda supplements my response yesterday on what I believe would be a good
enhancement to the scroll bar function.  Allow page-at-a-time (sflsiz = sflpag),
and specify two other fields on the SFLEND(*SCRBAR) keyword.  First, the number
of records that _could_ be displayed from beginning to end (in my example above,
50000), this would control the size of the scroll box in the scroll shaft (IBM's
terms).  Second, the position (as it relates to the number of records from the
beginning of the data) of the current subfile page being displayed, i.e. if
"Johnson, Dr. William" is in the current subfile page and would logically be the
25,000th record in the "virtual" subfile of 50,000 records, the scroll box would
appear smack dab in the middle of the scroll shaft.  The operating system would
use these two values to determine the size and placement of the scroll box.
Here's how I see it being implemented in DDS (not column-correct):

   A       #PRECS     15  0P   TEXT('# of Potential RECordS in virtual sfl')
   A       @POSIT     15  0P   TEXT('Position of current page in virtual sfl')
   A  34                       SFLEND(*SCRBAR #PRECS @POSIT)

Determining the value of these two program-to-system fields would be the burden
of the application, which _could_ require significant background processing if
not designed properly.  Boy, if I had that, I'd reconsider using the scroll bar
as a standard.  (Again, I'd still utilize a Position To: prompt.)

That was kinda fun!  Thanks for keeping the thread going, Booth.

How does one submit this kind of idea to IBM to consider as an enhancement to
display file DDS?

- Dan Bale

boothm@earth.goddard.edu wrote:

You are right.  I would never hold out the load-all subfile as the answer,
but my original point was that we shouldn't lock ourselves into the
page-at-a-time subfile solution either because any system has many files
that are 2,500 records or less and benefit nicely from 100% loading.

I would also agree that at somewhere around 2500 records the file becomes
unwieldy  -  just a twitch of the scroll bar rolls several pages and it
becomes impossible to navigate to the desired record easily. But the
response time issues are much different today than even 3 years ago.  It
is my opinion the whole arena needs to be revisited because the underlying
facts have changed dramatically.

I brought up the darned discussion in the first place because there are
many people here way smarter than me,  and I was hoping for their input
from a fresh look at the issues involved.





+---
| 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
+---