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