console modes - what Linux sees
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: followed by ":q!" to > exit vi. There's no way for Linux on z/VM to see an 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 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 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 you pressed is not really the same 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 (t
Re: console modes - what Linux sees
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 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: followed by ":q!" to >> exit vi. > > There's no way for Linux on z/VM to see an 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 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 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 > typic
