× 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: 4 - subfiles
  • From: "Dan Bale" <dbale@xxxxxxxxxxx>
  • Date: Tue, 9 Nov 1999 15:47:43 -0500



Booth,

You seem to be stating two different issues.  In your 100% subfile with 2500
records that is keyed by name, are you saying that there'd be no "Position To:"
prompt?  So a user looking for "Zywot, Dr. Zachary" would have to page all the
way down to the bottom?  (Over 200 pages with 12 records per page?)

If you're speaking of subfile that uses the scroll bar, how "fine" a touch does
one need to have to accurately position the cursor in such a large subfile?
(Your sample app is the first I've seen of the 5250 scroll bar and I don't
really want to key in 2500 records to find this out. ;-)  )  I wonder whether
there really is much of a user efficiency gain over scrolling in such a large
subfile as opposed to keying in a "Position To:".  I also wonder just how
efficient the users you spoke of are, given that they feel a need to type in the
entire name they're searching for.  Perhaps that was a training issue?

Again, too, you need to consider how dynamic the data is.  If this is a subfile
app that the user runs all day, and the data is fairly dynamic, you run the risk
of users looking at obsolete data.  Also, what if you had 200 users using this
subfile all day?  200 users * 2500 records = 500,000 records taking up memory.
Could this have an impact on performance?

I was just reviewing your answer again, and got to thinking (I know, dangerous!)
Is it possible to define a page-at-a-time subfile _and_ a scroll bar that
reflects the potential size of the subfile?  Hmmm.

OK, I think I've beaten this horse long enough.

- Dan Bale


boothm@earth.goddard.edu wrote:

I like the page-at-a-time subfiles;  those were the first that I used.

But when I started writing Visual Age RPG applications I  came to realize
that a very large fraction of the files in everyday use are 2,500 records
or less.  Even many of the larger files have logicals over them that make
the file of actual interest under 2,500 records.   With today's AS/400s
these load 100% in 5 or 6 seconds.  Add in the speed of the scroll bar and
page-at-a-time no longer makes sense.   With page-at-a-time subfiles I
watch users laboriously type in the whole name on the look-up field over
and over.  I suggest they just type the first 5 letters or so, but as soon
as I look away they carefully type "Johnson, Dr.  Jonathon R."  and then
hit the enter key.

Compare that to the a 100% subfile where the user scrolls to the name and
clicks and then the default action screen pops opens.  Never key a key,
never hit Enter, never touch a function key, at least not on the header
screen; just on the default action screen.  Fast, easy, and accurate, even
on the factory floor.





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