On 3/17/18, 1:55 PM, "IBM Mainframe Discussion List on behalf of Paul Gilmartin" <[email protected] on behalf of [email protected]> wrote:
>On Sat, 17 Mar 2018 16:29:29 +0000, David Boyes wrote: >There's c3270 (which I never got to work) and older flavors of tn3270 (which >i've used) >The trick is to switch modes dynamically. >How about logging in on an emulated 3270, setting X11 DISPLAY back to your >desktop >and starting Xterm under OMVS? The trick would be to bootleg DISPLAY and Xauth >through the 3270 logon. I recall that years ago, when security was more >casual, I >could start Xterm from a batch job. The point of this exercise is not to have to use a special terminal emulator at all. I mentioned c3270 only to point out that it already has a well-tested 3270 screen order processing engine that already knows how to do all the screen management and telnet option negotiation that's needed to allow a standard telnet session to emulate a 3270; we wouldn't have to start from scratch. If that 3270 engine code was included in the shell (activated say by an ioctl() and inheriting the current connection), then any application could trigger that emulation as needed and keep mainframe code that works today working without change. Most TSO or VM sessions would be (and are) perfectly usable with nothing smarter than a teletype - I do it all the time on VM when I need to quickly execute a command and don't need/want any fullscreen stuff, and the line editor mode is still in the base XEDIT code, if a bit dusty/crusty. > If, only, ISPF would consider operating from other than the logged-in > terminal! See above. There's no need to modify ISPF or any application, just enable the emulation when needed, either by ioctls inserted into the application or via a script that calls an external utility to toggle the emulation off/on. X11 takes a lot of additional infrastructure for this purpose; my approach would allow any ASCII terminal that is supported by termcap to work immediately. I could use my vintage ADM-3A (the world's stupidest glass TTY; supports only clear screen and position cursor, otherwise you have to rewrite every character on screen) and have a working environment. > Long ago, there was ISPGUI (is there still?) Sucked. I think Win10 finally broke the workstation agent code. It still sucked. > How about a dynamically resizable 3270 in an ISPF session!? > (XEDIT comes close: I can pull the plug on an XEDIT session and reconnect > with a different > terminal geometry. XEDIT dutifully repaints the screen to the new geometry. > What about > ISPF? ISPF people say, "Impossible! NFW!" No. Just do a WSF Query, as > XEDIT does, > and redraw the display. We won't get into 'who's editor is better' discussions; they just degenerate quickly into "Nyah!" and "Does not!". I don't think that one is totally ISPF's fault, though. > Long ago, there was SimWare. (Are they still? Who bought them?) Deservedly buried with a proper stake in it's heart, I hope. That package was a gigantic PITA. > Forget Session Managers. Why not simply support concurrent logins as any > non-IBM OS > does? Step 1 - get VTAM out of the terminal management business... a lot of the basic assumptions it makes about devices just don't really hold true any more. I think the logical device model VM uses seems to work a lot better for that purpose. The basic system services concepts needed exist to permit multiple sessions; it's just a question of thinking it all the way through an implementation. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
