> I cannot help but think that this is a job for inverse TN3270. > (Not sure what else to call it. Maybe "reverse protocol conversion"?) > Making a Linux distro CMS-friendly is one thing, and is VERY useful. > But making it 3270-friendly is closer to "same as a PC", which is > what some customers expect. The principle of least astonishment > comes into play. Let me explain. > > Getting the *output* from 'yast' and other textual (but full-screen) > tools to display on a 3270 is easy. It's the *input* from a 3270 > which is more challenging, and that only because the text mode apps > presume on byte-at-a-time keystroke interaction. But we who live in > the 3270 world know full well that block-mode input is fully interactive.
Actually, I can see how some of this _could_ almost be done... but it may take some creativity in using a "non-tty" interface/driver which would front-end the TTY driver (well, a wedge into it, at least). (laughs) Look, I've been around a bit. I'll admit that I'm underwhelmed by the local capabilities of a 3270-ish device (it's just a buffered display w/ little in the way of local intelligence... though you can make various chunks of the screen "protected" for forms). I have to admit the times I've written the bisync drivers for a 3270ish terminal enemalator that I liked the protocol, it was just the "tube" that I really didn't like. Heck, I even wrote a handshake for data transfer between hospital ancillary systems on the Unix end that basically, as I look on it now, acted like a robot. Granted, we had a 3270ish box on the 3274's coax network that would allow a "regular" ASCII terminal to be used instead of, say, a 3277. Heck, I played with a "black box" device that made the "327x" terminal look like a vt220, too, so this kind of "faking" can't be all that hard. Been there, done that. I _did_ have fun, however, with Uniscopes-- the Sperry+UNIVAC buffered terminals which DID have a lot of local intelligence but had, to my eye, an annoyingly clunky bisync protocol (UCCP was _not_ fun and had a lot of "features" I didn't like to deal with... but it was that clunky handshake that caused me to write a full screen editor for the Uniscope and UTS-400 terminals just to cut down on the number of the poll/select handshakes to display a line for editing... and be ready for the next editing/entry. I'm wondering if there's a cute way to simulate this whole bizarre handshake inside the line discipline logic? In some ways you have to emulate the terminal internally and just push the buffer out to the display frequently enough to do the job... but, to my limited knowledge, the 3270 doesn't really pass keystrokes at all, but does want to enter into a field and transmission is implicit. (laughs) A virtual KD terminal with a text-mode frame buffer... (shakes head) 'tis a pity I ain't a mainframer. I *will* grant that some things may be harder to enemalate within such an environment... so, maybe, "vi" will be "out"... or, maybe, not. I'm still hoping for a "turnkey" Linux CD, kind of like the turnkey MVS 3.8 CD I've played with, which might make it easier for me to understand how it all fits together. I've put Linux on pSeries, Sparcstations along with PCs, thinkpads and PCs... but the big 'ol mainframe *still* throws me a curve... even though I played with the architecture back in the days of the V5 USF being mapped to it without "Guest VLANs" (you know... using CTCs and IUCVs) but could never get my own hands "dirty". -soup -------------------- John R. Campbell, Speaker to Machines (GNUrd), Stand-Up Philosopher Phone: (813) 356-5322 (t/l 697) Adsumo ergo raptus sum MacOS X: Because making Unix user-friendly was easier than debugging Windows. Red Hat Certified Engineer (#803004680310286) IBM Certified: IBM AIX 4.3 System Administration, System Support ---------------------------------------------------------------------- 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
