Fw: [LINUX-390] Let Novell Know if you want a easy CMS-friendly starter system!
David Boyes remarked: >> How hard would a 3270 based implementation of ncurses library be? And >> would that solve the issues? > > Since ncurses mostly just deals with output, probably not too bad -- I > faintly remember that Alan Crosswell had done some work on that way back > when at Columbia, but I don't remember where I stored a copy of it. > > It doesn't really address the input issues at all, though. Agreed, the input management and key recognition in the terminfo tree is awkward (at best) but some of the logic has, at least, been thought about-- even though many of the old ASCII terminals don't fit it very well. With the advent of ANSI x3.64 (peeled off of the VT100 and then enhanced with all kinds of visible bells... (smirks) What is annoying is that some of the keys fit the model very well but there are usually all kinds of variations on the action keys-- and, to make you get almost psychotic enough to go on a multi-state killing spree (I love that line from "Back To School"). function keys often map to some weird and oh-so-terrible escape sequences. Been There, Done That. (laughs) I don't fit into a spreadsheet cell all that well, now, do I? One more day... and Buh-Bye! (I'll have to re-subscribe to this list from my gmail addy...) 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
Re: Fw: [LINUX-390] Let Novell Know if you want a easy CMS-friendly starter system!
> John was this a 717 type device as described in, "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."? And can you point to an appropriate > location > to see what a 7171 type device would look like. A 7171 (aka the Yale ASCII Controller) was a standard IBM half-height cabinet (same physical width and depth as other 370 processor and disk hardware, so it would line up nicely in rows, just half height,). It contained a 7RU chassis with a parallel channel interface card, the control unit processor cards (2), and up to 8 serial interface cards with 8 ports on each card, for a total of 64 connected ASCII devices per 7171 unit. AFAIK, they only came in Standard Ivory -- rumor had it you could get different color door panels, but the sides only came in Ivory. The color conversion kit contained two cans of spray enamel, some masking tape and a drop cloth...8-) AFAIK, it was the only terminal controller ever sold by IBM that supported more than 32 physical devices. It appeared to the host as two local non-SNA 3274s, each with 32 devices. If you *really* want obscure, find a 7170. Channel-attached UNIBUS cage, allowed use of the VAX Ethernet adapters for WISCnet and the very early VM TCP code. Weird, weird, *weird* device. -- 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
Re: Fw: [LINUX-390] Let Novell Know if you want a easy CMS-friendly starter system!
Hello! John was this a 717 type device as described in, "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."? And can you point to an appropriate location to see what a 7171 type device would look like. Your description struck a chord based on your reference to that MVS3.8 Turnkey disk. As it happens I lurk over on most of the lists there, I also manage a few, so your reference caught me, and I thought I would ask. (The list in question was discussing the right way to attach almost anything else to an emulated environment on Intel. It happens I triggered it, but that's all I'll say.) -- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you. Always." Obi-Wan Kenobi > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of John > Campbell > Sent: Tuesday, May 29, 2007 6:15 PM > To: LINUX-390@VM.MARIST.EDU > Subject: [LINUX-390] Fw: [LINUX-390] Let Novell Know if you want a easy CMS- > friendly starter system! > > > 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... b
Fw: [LINUX-390] Let Novell Know if you want a easy CMS-friendly starter system!
> 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
