Great work! That's a great write-up! I know nothing about "system console". I'm in California and the mainframes are on the East Coast (meaning anything East of the Rockies.) Nor am I trusted with access to the HMC via TCP/IP.
A few more comments. As a friend of mine said "green screen is an acquired taste". (Green screen is a name for the IBM 3270 family of terminals.) Unless you want to learn to control z/VM or z/OS or z/TPF, it's not worth learning. And it still won't give you 'vi' or 'top' or anything else full-screen, on a 3270-emulator. Some history: A 3270 had only a few "attention" keys. PF1-12, PA1-3, Clear, Enter, and some Reset keys. PF1-12 and Enter sent in the whole screen. (Approximately). When the screen was set up (by z/VM in 3215-emuation mode) with 2 input lines (132 characters) at the bottom, those are what got sent in. PA1-3 sent only the key pressed. I'm not sure what Clear sent in, but in any case it was a request to clear the screen and redraw it. There were also numerous keys that modified the screen or cursor position, but did not send anything.(Cursor movement arrows, tabs, Erase Input, etc.) Esc did not exist. Now for Linux running on z/VM: ^C (hat-C or not-C) doesn't send anything, so you have to type ^C + Enter. (The Linux driver interprets this as a control-C). PA1 takes you from VM Read to CP Read, so you can type CP commands directly, without #CP space in front of them. To get back to the normal mode you have to type BEGIN (or B) which is the CP command to start the virtual machine running again. (Someone else can talk about SET RUN ON if they like.) I don't know what PA2 and PA3 do in Linux. You can program PF1-24 to send short character strings, via CP SET commands. So if you want PF3 to send control-C you can do that: #CP SET PF3 ^C The above was all about real 3270s (3278s). You are probably sitting at a PC running a 3270-terminal emulator, and it can be programmed in many different ways. (See its manual.) But it still cannot send anything but the above, or combinations of them. What Esc does is up to the terminal emulator vendor, but I cannot think of any way to make 'vi' usable. You could program the Esc key to send in a PF key which was set up via #CP SET PFn ^[ but that would be interpreted as Esc + Enter, not just Esc. > ]On Feb 23, 2015, at 11:45 AM, Rick Troth <ri...@velocitysoftware.com> wrote: > > Started this a couple weeks ago, but then had to put it aside. (Other > things urgent, and had some checking to do.) But a friend asked a > related question last week, so when answering that I think I managed to > finish this. > > The thread with subject "Interrupting Linux under z/VM session" again > points out the crucial need for understanding some basics in mainframe > Linux. Console interaction with Linux on z is not difficult, but is > grossly misunderstood by newcomers. (No slam on newbies; the interface > tools paint a deceptive picture.) It's the kind of thing that should be > covered early ... during orientation, before classes start your very > first semester, prior to Linux/390 101. > > It's all about what Linux sees. With all hypervisors, there is a big > difference between physical interaction and virtual interaction. The > other hypervisors (than z/VM) have things somewhat easier because most > of the virtual devices they present as "console" at least allow > byte-at-a-type interaction. Confusion there is a little less. > > There are five modes of console operation for Linux on z: > > * what Linux sees as a 3215 (typewriter) > * what Linux sees as a 3270 > * what Linux sees as the "system console" (SYSC in z/VM speak) > * what Linux sees as the ASCII system console > * what Linux sees by way of IUCV (can do byte at a time) > > > The 3215 is most common when Linux is hosted by z/VM. You connect with a > 3270 emulator, so the conversation is about "3270", but that's *not* > what the guest sees. > > > On 01/21/2015 07:55 AM, John McKown wrote: >> ... I can't duplicate the OP's environment, >> but I wonder why he can't just do the normal: <escape> followed by ":q!" to >> exit vi. > > There's no way for Linux on z/VM to see an <Escape> character by way of > the 3215. > Linux using (what it sees as) a 3215 will never get byte-at-a-time and > will never see an actual <Escape> nor an actual Ctrl-C. > > ^c or ^z are special short-hand for faking it, but as John mentioned (in > the note cited above), 'vi' (VIM) can intercept interruptions. > > ----- what follows is long ----- > > Back up ... always an exception to the rule ... it's possible but really > really really difficult for Linux to see an <Escape> by way of what it > thinks is a 3215. If the 3215 is presented by way of a 3270 (emulated or > otherwise) it is likely not possible. > > The 3215 console driver in the Linux kernel takes the EBCDIC "not" > (sometimes rendered as "hat") and then marks the following character as > a control character. So "^c" becomes Ctrl-C. For Escape, that would > typically be "^[". But don't get me started about square brackets and > Codepage 500. > > Forgive my tone. Explaining this is actually fun. And the > implementations are neat! But the gap in what you have been told is > frustrating. > > DO NOT run 'vi' on Linux on z on a typical 3270 session. > > > *Linux sees a 3215*, ye olde Selectric > > z/VM uses the bottom two lines of your 3270 session for input. The far > right of the second line is reserved for status (eg: VM READ or RUNNING > or others) and shows the VM hostname. The rest of your 3270 screen (what > you see) is guest output (or is VM/CP output). > > Input is line at a time. The content delivered to the guest by VM (CP) > is the line you entered without any control characters. The 3270 console > driver (in Linux) tacks on a 0x0A newline at the end for the shell and > other apps (like 'vi'). When the console device is in cooked mode, I > expect it's actually 0x0D and 0x0A (CR/LF), but haven't bothered to look > into that for a long time. Doesn't matter: the control characters are > simulated. The <Enter> you pressed is not really the same <Enter> the > shell gets. > > The 3215 driver will convert a "^c" to a Ctrl-C 0x03. Ctrl-C is the > default "intr" character. See the 'stty' command for more info about all > that. > > When Linux boots, you see a lot of garbage looking output. The startup > scripts in most Linux distros contain ANSI X3.64 escape sequences for > highlighting and color. What looks nice on a PC looks like junk on a > 3215. (And then Codepage 500 makes matters worse. When you see > "Ýsomething¨", that's CP 500 mucking things up.) > > This is where most of us running Linux on z/VM live when we do console > work. > > Mother never told you, but Ctrl-C in X3270 on your desktop will not be > heard by Linux at the other end. > > > *Linux sees a 3270*, '#cp term conmode 3270' > > There is a 3270 driver for Linux. It's really slick! (DO NOT try "#cp > term conmode 3270" on a running guest.) > > The 3270 driver in zLinux came from Amdahl. Long story. > Remember Amdahl? Okay, not everyone knows the name ... so there once was > a company called Amdahl that made IBM compatible hardware. It was > founded by a man named Amdahl who used to work for IBM. (He's a legend > right up there with Fred Brooks.) > > In the 70s, the company picked up a Unix implementation for S/370. It > was a *great* implementation of Unix, having no allergy to true Unix > things nor confusion over true mainframe things. A fully ASCII system, > it could do full-screen 3270 just fine. This system was called UTS. > > Amdahl (the company) spun off UTS (the product) into UTS Global (a new > company). The latter later contributed their 3270 driver to Linux for > S/390. Very kind of them. One nice thing the 3270 driver does is to take > ANSI X3.64 escape sequences (color, highlighting, cursor position) and > presents them *correctly* on the 3270 screen. This is substantially > different from the trashy output you normally see when Linux starts up > (on a 3215). The 3270 driver reserves the bottom of the 3270 screen for > input, quite like z/VM does. > > UTS had a really nice full screen editor 'ned' which UTSGlobal marketed > (not free) for Linux/390. NED is an example of a 3270 application for > Unix and Unix-like operating systems. > > Unless the app you're running knows how to speak 3270, you still get > line at a time input. Your *output* looks great, but the *input* is > still not much better than with 3215. 'vi' would display correctly. A > 'vi' wizard could probably make good use of it. But ... ick. > > There is also the concept of virtual 3270 lines. Beyond the scope of > this note. > > And still, ^C on your keyboard does nothing. (Or at least, not what you > expect.) > > > *Linux sees a "system console"* > > At some point in the evolution of mainframe hardware (Alan could fill us > in if he has opportunity), the systems no longer required a real > terminal for their console. We were given the concept of a "system > console". When someone signs on to z/VM via the "system console" they > appear at "SYSC" in 'q names' output. > > Linux can use this interface for console work. When running Linux on > z/VM, you probably don't want this. Output is fine, but input is always > by way of the CP 'vinput' command. You'd be entering '#cp vinput vmsg > command-for-the-shell' all the time, where command-for-the-shell is what > you entered at a 3215 without any special lead-in. Restated: you would > have to prefix every command with "#cp vinput vmsg". > > When running Linux native, the "system console" is more normal. You get > a window on the HMC and enter your commands. It works. > > > *Linux sees an ASCII "system console"* > > This is where I had to do a little digging. They don't let me on the HMC > so I have never gotten access to the SYSASCII interface. Sounds like a > great idea. IBM realizes that some mainframe operating systems are > better served with a byte-at-a-time interface. (Call it "ASCII", but the > significant feature is not the character set. Character sets are so 1980.) > > z/VM can attach a SYSASCII to a Linux guest. Linux can then use the > SYSASCII console interface and a non-mainframe Linux person would be > perfectly comfortable. > > > *Linux sees an IUCV connection* > > There has been discussion from time to time about the "IUCV terminal > server". If you have not used the IUCV terminal support, you should > check it out. Very nice stuff. Very secure (because it's IUCV, and > wholly contained in z/VM space). > > IUCV terminal connections can be handled in either of two ways. You can > launch an IUCV 'tty' process. That runs in user space. Slightly > different, the kernel can set-up an IUCV listener when it boots. That's > where you get console traffic, otherwise they're much the same. These > both require a partner Linux guest. > > The partner or "client" runs in another Linux guest. You get the same > byte-at-a-time ASCII operation on a target IUCV console Linux as you > enjoy on the client system; no more, no less. Presumably you got *there* > (the other Linux guest, the IUCV client) by way of SSH. In any case, > Paul could quit 'vi' in the usual way over a connection like this. > > IUCV mode consoles are highly recommended for Linux-on-z users who will > not (or cannot) use the other console modes. > > > > -- > > Rick Troth > Senior Software Developer > > Velocity Software Inc. > Mountain View, CA 94041 > Main: (877) 964-8867 > Direct: (614) 594-9768 > ri...@velocitysoftware.com <mailto:ri...@velocitysoftware.com> > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
