Yeah, I was wondering about the termcap et al databases too. So yes it’s fine that TERM=linux is usable with 3270. It was just an observation
I haven’t tried the dial thing yet, that one’s not as interesting to me as the console after a logon by… I may tinker with that “just for fun” On Mon, Nov 14, 2022 at 10:35 Rick Troth <r...@casita.net> wrote: > There's a standard for ASCII based screen terminals: *X3.64* developed > circa 1980. > TERM values like "vt220" and "xterm" trigger curses/termcap/terminfo > behaviors which speak that protocol. > But there are countless (ASCII) terminals, such as the DEC VT52, which > speak their own protocol and not this standard. > > DEC made a good guess when they produced the VT100. It was the first > widely used physical terminal which spoke ANSI X3.64. > > Remember: Linux is an ASCII system, so even when you've got a 3270 (real > or emulated), Linux thinks it's talking to an ASCII screen. The driver > nicely maps X3.64 escape sequences, translating them into roughly > equivalent 3270 data streams. Now ... as I recall, UTS donated their > 3270 driver to Linux, so we *could* talk direct 3270 data streams. But > the applications would need to know about the alternate interface. UTS > *did not* donate their slick 'ned' editor, operationally similar to > XEDIT and which can drive 3270s directly. > > Linux on a PC does the same mapping of X3.64 protocol. In that case, of > course, the user end is the text mode raster of your hardware. But the > PC itself doesn't know anything about escape sequences or ASCII (or > EBCDIC). > > "ibm3278" and "ibm3279" don't have meaning in the ASCII/Linux/Unix world. > It's not some sort of allergy, nor an aversion; it's just that nobody > ever defined terminfo/termcap/curses database files for those entries. > But they're not really needed because you get the same effect from > (e.g.) vt220 and several others. > > On z/VM, you can also 'vmcp def graf' and have DIALable 3270 screens. > > -- R; <>< > > > On 11/14/22 12:44, Donald Russell wrote: > > That’s great.😀 I don’t know why the code was written to act differently > > when running on vm, but it sounds like using the query partition in all > > cases simplifies the code and makes it more generally useable. > > > > The IBM doc that describes this talked about using TERM=linux and you > just > > mentioned TERM=ansi. > > > > Other common types are vt220 and others, so I was curious why the TERM > > value wouldn’t be something like ibm3278 or ibm3279. > > > > I used “linux” and the colors worked as expected, though I don’t use > many. > > I use tput to get the color escape codes to use in the text strings in > bash > > strings and the PSx prompts. > > > > As for handling geometry changes due to vm cp disconnect/reconnect… > > Obviously it would be best if the kernel detected that, but if I have to > do > > something like echo 1 > /dev3270/tty1/query_partition > > That would be acceptable because I already have a process in Linux that > > starts a 3270/tty when reconnecting…. Maybe that’s where the code needs > to > > be… when starting the Getty, read partition, that works for me because I > > also stop the Getty on a CP disconnect event. > > > > If you’re open to making changes, I’m open to testing them. (On rhel, I > > don’t have SUSE or uduntu) > > > > I have a couple of other suggestions but this is the most important to > me. > > > > Cheers, > > Don > > > > On Sun, Nov 13, 2022 at 23:21 Sven Schnelle<sv...@linux.ibm.com> wrote: > > > >> Hi Donald, > >> > >> Donald Russell<russell....@gmail.com> writes: > >> > >>> This Message Is From an Untrusted Sender > >>> You have not previously corresponded with this sender. > >>> > >>> Thanks Sven, > >>> > >>> Where do I find the source code? Maybe I can contribute to a > >>> solution. 😀 > >> It's in the linux kernel source, file drivers/s390/char/raw3270.c, line > >> 580: > >> > >> > >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/s390/char/raw3270.c?h=v6.1-rc5#n580 > >> > >> As a quick test i changed: > >> > >> } else if (MACHINE_IS_VM) { > >> raw3270_size_device_vm(rp); > >> raw3270_size_device_done(rp); > >> } else > >> raw3270_writesf_readpart(rp); > >> > >> to: > >> } else if (0 && MACHINE_IS_VM) { > >> raw3270_size_device_vm(rp); > >> raw3270_size_device_done(rp); > >> } else > >> raw3270_writesf_readpart(rp); > >> > >> so it always uses WSFQ to get the geometry. > >> > >>> When you changed to code to use “LPAR mode” instead of diag 120, did > >>> the console work properly with different geometries? > >> It did, but i haven't tested whether dynamic resizing works. And it's > >> diag210, the 'diag 120' was a typo from me. > >> > >>> That’s the first problem, when the system first comes up, if the > >>> screen isn’t 24X80 the wheels fall off the wagon. > >>> > >>> But the other problem occurs when the console is > >>> disconnected/reconnected and the geometry is different. (A very likely > >>> scenario as everybody has their favorite settings. I generally use 60 > >>> X 140) > >> Let me try this here. I'm normally running c3270 in tmux, so i'm not > >> disconnecting and reconnecting to my session. But i realize that my > >> workflow is likely different compared to running production systems. > >> > >>> I can detect when a reconnect event happens, but there needs to be a > >>> way to tell the kernel/driver “check the geometry > >>> and adjust accordingly”. > >>> > >>> I’d like to use 3270 mode, but this is a showstopper for me. Without > >>> it working for any geometry allowed by 3270 data > >>> stream specification, it’s not something I want to implement. 🙁 > >>> > >>> Why do I want to to use it? It solves two annoying problems: > >>> 1 - it supports “dark” fields so passwords are not visible (ssh to > >>> another system etc) > >>> 2 - it supports the Linux “progress bars” as created by fsck and > >>> others. On the 3215, every update is written to a new > >>> line; with the 3270 mode, those lines are just overwritten as > >>> intended. > >> It can even show different foreground colors if you set $TERM to ansi. > >> > >> Regards > >> Sven > >> > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email tolists...@vm.marist.edu with the message: INFO LINUX-390 > or visit > > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > > > -- > -- R; <>< > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
