On 4/2/10 1:58 PM, "karl williamson" <[email protected]> wrote:
> I don't understand the above. On ASCII terminals, often a control is > printed as '^<letter.', but entering requires pressing two keys at the > same time. It seems like you are saying that the terminal will send a > control character whenever a not or cent or maybe caret is typed > whenever followed by a letter. What I'm saying is that 3270s don't really use that concept. Applications that force a 3270 to interact with a host that DOES use the concept have to scan input, look for the two characters ^ and <letter> and translate that to a single control character that the remote host understands. An good example is the VM TELNET program. To send a cntrl-C to a remote host, I type <EBCDIC not> C and the VM TELNET program grabs that and sends an ASCII cntrl-C character to the remote host. I can't enter a cntrl-C directly from a 3270 keyboard. The concept is meaningless. > If so, how then does one enter these > three characters literally? You don't. In most cases, there's a specific key for each control function, and on output, screen attributes are sent as bytes in a stream, inserted by applications as part of the output. The I/O model for 3270 is more like dealing with a web browser than with character oriented terminals. You create output as a series of structured fields, fill in data, and write to the device. The user makes changes, hits a key that generates a attention interrupt to the host, and the host reads the whole screen at once. It then figures out what changed, updates the appropriate variables in the app. Repeat. I guess I'm still not getting what EBCDIC support you're trying to provide in Perl. The C compiler libraries you would use to build the Perl language interpreter on anything other than Linux or OpenSolaris already contain the mapping of text to the current system code page, and handle things like \t, \r and \n to the best of the ability of a 3270 terminal. What else are you trying to provide? There aren't really any control characters, because 3270s don't use them. A screen management package would be cool (kinda like curses), but you should look at something like RXFS out of the SAS REXX function kit to get a sense of what it does with a 3270, and that sort of thing really belongs as a module of some kind, not in the core language. Having a 3270::LDEV package like RXLDEV would be really neat, especially if you could drive a dialed terminal with it too. The docs for RXFS do a great job of explaining what a 3270 can and can't do. Check them out here: http://ukcc.uky.edu/~tools/1996/sasrxfn.list (list of files in the package) If you can't extract the VMARC, I'll send you the listing files offlist. Also look at the 3270 console driver in the Linux source code. That will give you a lot of the gory details of what it's like to work with a 3270 from a byte-oriented perspective. --d b ---------------------------------------------------------------------- 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
