BY THE WAY ... I maintained for years, and still do, that a 3270 can be used effectively from carefully written ASCII application programs. The big requirement is not 3270 data streams nor EBCDIC, it's block mode toleration. Tools like YaST are awfully close to being able to do this.
The console (or terminal) device driver must be cognizant of ANSI X3.64 escape sequences and translate all properly to their 3270 data stream equivalents. ALSO, there should be some amount of field formatting, which might well be ignored on a "real" ASCII screen (like the PC console) too allow for clean data entry. Given that, PF1-12 and ENTER would operate just like PC F1-12 and ENTER. The driver needs a trivial state machine to convert the ANSI X3.64 screen control sequences into 3270 data streams. It would need to reliably detect the tube's capabilities (highlight, color, dimentions). The applications which use it would have to be tooled to NOT EXPECT byte-at-a-time style input, for which the installation programs are all great candidates. Applications should also emit some kind of field-start and field-end signals which would be ignored by real 'xterm', VT100, and the like. This is a change, but a small one. Arthur will tell you that TNVT100 is a pain. I suggest that effective use of 3270 for selected ASCII apps is much less painful. Getting a 3270 to work with apps which have no clue that the tube is block mode is HARD. But getting apps to work well with *either* block mode or byte mode tubes is not. Well ... aside from politics, emotion, and inertia.
