From: utzoo!utcsrgv!utcsstat!wagner
Newsgroups: net.works
Title: Re: WORKS Digest V2 #68
Article-I.D.: utcsstat.291
Posted: Sun Aug  8 12:28:01 1982
Received: Sun Aug  8 21:13:42 1982
References: unc.3781

I think the biggest problem with menu systems is 
display bandwidth related.  The first good menu system I used
was SPF on channel attached 3270s.  The menus never got in the
way - the datarate of such a device is roughly half a megabyte
per second.  Try using the same system at 4800 baud (i.e. about
500 chars/second - 3 orders of magnitude slower) - suddenly I
understood why the half of the computer centre located 
remotely couldnt stand SPF.

One of the features that ameliourates the problem a bit is a
way of stepping through common menu sequences without display
of intermediate menus.  In SPF, if you remember where you want
to go, you can concatenate menu replies (sort of like UUCP
routings - utzoo!decvax means send to utzoo, having stripped off
utzoo so the next guy will re-read and send to decvax).

IMS is a menu based database system.  One of the things you can
do to speed up menu response is run your remote terminal on
a micro called a system/3 (which supports 8 or so terminals
and a line back to the mainframe).  In the morning, when IMS
wakes up, it sends prototype menus down the phone lines to all
its system/3 sites, who store it locally on disk or in memory
(i dont remember which).  Then, when IMS feels the need to show
the user menu X with fillins, menu X is condensed to 3 characters
from the more normal 100 or so, and flash! up it goes.  The 
fillins, of course, still go up slower.  Too bad it cant
huffman encode them.  

Enough.

Michael Wagner, UTCS