Thanks Sven, Where do I find the source code? Maybe I can contribute to a solution. š
When you changed to code to use āLPAR modeā instead of diag 120, did the console work properly with different geometries? 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) 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. One thing lost by using 3270 support - canāt spool the console. Thatās a different problem for a different thread. š Cheers On Sun, Nov 13, 2022 at 10:48 Sven Schnelle <[email protected]> wrote: > Hi Donald, > > Donald Russell <[email protected]> writes: > > > I have RHEL 7.9 setup (on zVM) so I can use the 3270 console instead of > > 3215 and it works quite nicely provided the 3270 geometry is 24 X 80. > > > > If the screen geometry is other than that, itās not usableā¦. Input > commands > > are not parsed properly and fail, and of course the output display is a > > mess due to the wrong buffer address calculations for sba orders etc. > > > > I detect in near real time when the console reconnects ā¦ is there a > (linux) > > command I can issue that will āshoulder tapā the 3270 device driver to > > reread the device characteristics, specifically screen geometry? > Presumably > > by issuing diagnose 8c or issue the query to the 3270 device ātell me > about > > yourselfā. > > I checked the kernel source, and it looks like Linux has different ways > of figuring out the geometry: > > - on VM, it uses a diag120 call. From the device type, it determines the > geometry. So it can only handle the fixed resolution of the -1, -2 and > so on models. I haven't found any reference to diag 8c. > > - if it's !VM (lpar), it uses a read partition query to figure out the > geometry. Interestingly though, this also seems to work on VM when i > force the 3270 driver to use the "lpar mode". I have to ask the VM > people why that differentiation exists - maybe VM couldn't handle > the query in former versions. But maybe it's just my limited knowledge > of 3270 support in VM and Linux, i have never seen a real 3270 :-) > > > I have a udev rule that is trigggered (indirectly) by a reconnect event > so > > thatās the point where I want to tell the driver ācheck the 3270 device > > characteristicsā. > > I haven't checked whether something like 'stty [rows|columns] X < > /dev/3270/ttyX' > works. But with the networking 3270 clients we have nowadays, > resolutions are changing all the time and i guess this wouldn't help > much even if it works. > > > P.S. Iām going to do this on RHEL 8 soon and maybe 9. I havenāt yet > > checked to see if the driver has been updated in those versions. > > I tested it with upstream 6.1-rc and was able to reproduce the behaviour > you described. So i don't think you need to test it with RHEL8/9. > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
