On 2013-09-28 21:10, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2013-09-28 11:51, Sampsa Laine wrote: Are you saying that Terminal.app (a program I avoid by the way, since the VT100 emulation is buggy) do not pass all values? How are you using it, by the way? Selected some arabic language on your MAC, running the terminal, typing in there, and in the terminal you have telnetted to some VMS box. Yes, essentially, Terminal.app will not accept Arabic letter input but displays Arabic text (incorrectly, without ligatures). I've tried this both locally, over SSH and Telnet. Again, I don't think this is a VMS issue. In this case, I think it is not. But I think you can pretty much expect there to be situations where it will break for you because VMS do not really work correctly with UTF-8. Your best chance, if you really want to do UTF-8 would be to write your own program to output the file. That's not true. VMS is only transmitting bytes of data to his terminal.app. VMS does not have any knowledge of the usage of that transmitted data by the autonomous application that is digesting it at the end of the connection; in this case, Terminal.app. VMS can wrap output, and for that VMS keeps track of printing characters output, so it can know when it hits column 80... And at that point, it inserts extra CR+LF in the stream. Checking at terminal settings in VMS: LFFILL and CRFILL will also mess you up. Broadcast will mess you up. TTSYNC can output XOFF and XON characters to you at any time. Lowercase alters output. Tab can replace the tab character with a number of spaces. All of these can mess up multibyte characters. VMS do not have any knowledge of the usage, and that is the problem, because in the case of UTF-8, there is context implied in the usage. VMS assumes that each byte is a character of its own. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol