> But doesn't that limit it to line mode again? If so, what the heck > would be the point?
I guess I start with the assumption that the console of a Unix machine is something that does not ever get regular use -- it's a emergency device at best. I find that it's safer to start with that assumption for server instances. I don't allow console access to the non-zSeries boxes for casual use, either. As far as I'm concerned, the point of the console is to allow you to fix whatever it is that's preventing it from getting on the network, which can usually be accomplished with the same commands you'd do from a VDT-based console -- and those are all line mode commands anyway. Once you're on the net, login on a network PTY and do the editing, etc. As far as advantages of the consoles being PVM clients: 1) Never having to allow J Random Luser to log in to the VM userid to get to the "console" 2) PVM macros for common tasks. 3) Configuration and selection solicitor so operators don't need to remember details. 4) Console access does not depend on having a working network configuration in the guest. 5) Leverages existing Linux 3270 console support with minimal development 6) PVM cross-system support over multiple transports (IP and non-IP) 7) Direct integration into z/OS or VSE-based automation tools without development (most support PVM directly) 8) PVM implements the suppress-echo-response CCW correctly. 8-) 9) PVM already supports a transparent method of sending data (you can actually run SNA traffic over PVM links if you so choose; ugly, but it works). The same support could be drafted for your idea w/o totally rewriting the session muxing code in PVM from scratch. 10) Multiple session support with session switching hotkeys. 11) (my favorite) Because we can. 8-) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
