smart@ditmela.oz (Robert Smart) (04/12/89)
GEACs are computers made in Canada and sold mainly (?) for library automation. They have an X.25 capability, but I'm not sure what protocol they speak over that to their terminal concentrator things called NIMs. They allow direct connection of async terminals so it should be easy to get into them with a terminal server, right? Wrong. They have their own funny terminals which talk some strange multidrop polling protocol to the GEAC over the async line. This lets you put up to 3 terminals on one async line. Each terminal has to have a unique Polling Code. So you can set it up: up-to-3-GEAC-terminals---terminal-server----terminal-server---GEAC I guess this will work if it is a fixed connection, but the GEAC will keep polling the terminals across the network. If you try to bring different (groups of) terminals in from different terminal servers in to the same port on the GEAC then the polling won't work because the Polling Codes will be wrong. You could set multiple terminals up with the same codes, but then they wouldn't be able to use the GEAC simultaneously (I think). Well if I had the source for the terminal servers I guess I could put in special code to fudge the polling and diddle the Polling Codes. I hope somebody out there has a better idea: or knows more about these beasts than me. I might say that we have a fair few of these GEAC terminals, so we'd like a solution that allows them. Then again they're expensive (understatement) so we would also be interested in a solution that emulates them on VT100s or similar. Bob Smart <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>
sean@geac.UUCP (Sean Phelan) (04/22/89)
There have been a couple of messages about Geac's old-style polled, async terminals, with some ( very valid ) criticism of their inability to interroperate with TCP-IP lans. smart@ditmela.oz.au (Robert Smart) writes : > GEACs are computers made in Canada and sold mainly (?) for library > automation. They have an X.25 capability, but I'm not sure what > protocol they speak over that to their terminal concentrator things > called NIMs. They allow direct connection of async terminals so it > should be easy to get into them with a terminal server, right? > Wrong. > ...... > Then again they're expensive (understatement) so we would also be > interested in a solution that emulates them on VT100s or similar. > > SHERWOOD@AC.DAL.CA (John Sherwood) replies : > Our GEAC allows the asynch terminals to be configured as GLASS-TTY > instead of the multi-dropped polling type. This means you can connect > a single, dumb ASCII terminal to the GEAC port. Makes for an easy > connection to the terminal server, right? > > Wrong. They neglect such frills as flow control and connection control. > ...... > All this applies to the older 8000 series machines. Our 9000 is in and > running, but I haven't had a chance to see if things have improved. If > anyone has a better way of doing things, would we ever like to hear it! > Yes, there sure is a better way of doing things !! Let me put things in context by explaining a bit more about our old-style polling protocol, and then I'll describe how we now support VT100/VT220 terminals. The reason we used to build our own terminals was that libraries require more than the standard 96 character ASCII character set. North America uses the ~160 character ALA ( American Libraries Association ) set, and most of the rest of the world uses the 190 character ISO set. We also put bar-wand decoding hardware and software in the terminal, which meant that a terminal just needed a $200 wand, and no $500 decoder box, in order to read bar-codes. We used the ANSI X3.28 polling protocol because it allowed cheap, easy cabling, and enabled several terminals in a library branch to share one leased line back to the host. So, Geac terminals were a smart idea 5 or 6 years ago, even cheap by the standards of the day. However now their time has passed, for two main reasons : - far too expensive ( for us to make, and hence for libraries to buy ) - polling and lans don't mix !! The first point needs little explanation - companies like Wyse have over 120 times the terminal manufacturing volume that Geac had. Wyse has factories in the far east, our factory is in Toronto. Clearly, passing async polls across a LAN is horrendous. Some people do it, but we don't recommend it. So we've replaced the polled, Geac-built terminals with two alternatives : Support of VT100/VT220 terminals, and a terminal emulation for a PC. VT100/VT220 compatible terminals are supported through a small 8 port cluster controller called the Geac 8212. Either connect the terminals directly or via a LAN and terminal servers. Flow control ( X-on X-off) and connection control are optimised for use over LANs, radio-modems etc. up to 8 .--------. terminals | Geac | .--------. | host | VT220 ----| | | | VT220 ----| 8212 |--------| | VT100 ----| | | | `--------' `--------' VT100/VT220 terminals won't display the full ALA or ISO character sets, but we use the DEC Multinational Charcter Set to get many of the common ones. Bar wands are done with an add-on decoder box. For the full ALA or ISO character sets, we offer a terminal emulation on the PC. There's also an optional PC board for doing the bar-wand decoding. I'm beginning to sound like a salesman now, so I'll stop here. For more information call your Geac account rep, who has no inhibitions about sounding like a salesman. If the terminals on your LAN are vt100/vt220 compatible, I would STRONGLY recommend using the 8212 solution rather than the dumb async terminal approach - you get a nice, user-friendly full-screen mode instead of the scrolling dumb terminal, and the per-port cost is the same or lower than buying port boards for the host ( at least, it was last time I looked - I'm a programmer, not a salesman. ) If you find ANYTHING unsatisfactory about the way this configuration works, bug your account rep about it, or mail or call me. Since LAN connectivity was one of the main reasons for introducing this product, we'd like to see it work as well as possible. Your reaction to this may be "but that's not REAL lan connectivity - I want the Geac host to connect direct to the Ethernet, without going through terminal servers !!" We decided to start with the async approach, because most of our sites only want a few simultaneous connections - one 8212 with 8 ports is almost always sufficient - and this approach is much cheaper for the library than a direct Ethernet connection. We are working on a direct connection for future sites that will use Ethernet for all the terminals - perhaps 100 simultaneous connections. Sorry, I can't give a release date. If you are trying to connect a Geac library system to your LAN, or to anything else, please feel free to mail me questions or comments. It would help me, though, if you tell me the name of your Geac account rep. -- Sean Phelan | "Education furnishes the mind, Geac Computer, Markham, Ontario | making it a pleasant place to sean@geac | spend the rest of one's life" {uunet!mnetor,yunexus,unicus,utgpu}!geac!sean |