muta...@gmail.com  wrote:   
   > On Friday, June 18, 2021 at 5:50:19 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > For some time my e-mail was on VM/CMS accessed via modem   
   > > from a PC. Plain ATDT worked fine to establish connection.   
   > > Terminal emulator (Kermit) knew that it was connected to   
   > > EBCDIC system and did needed translation.   
   > >   
   > > Doing translation in modem actually would complicate   
   > > terminal emulator.   
   >   
   > Why? Kermit is already complicated by having the   
   > burden of ASCII to EBCDIC translation, isn't it?   
   >   
   > And you suddenly restrict yourself to terminal software   
   > that has this complication.   
   >   
   > > Namely, beside running terminal   
   > > programs on mainframe terminal emulator also handled   
   > > file transfers. Character translation inside modem   
   > > would complicate file transfers, either terminal   
   > > program would have to switch off character translation   
   > > or somewhat compensate for it in file transfer protocol.   
   >   
   > Yes, I agree that file transfers (instead of the terminal)   
   > would need some complication added. Is this actually   
   > a worse situation?   
   >   
   > Regardless, solutions available are:   
   >   
   > 1. Use a file transfer protocol that sends binary data as   
   > two hex characters for links that are considered to be   
   > problematic. This will also bypass problems with other   
   > characters like XON and Telnet.   
   >   
   > 2. Rely on the fixed 819/1047 translation being done and   
   > compensate appropriately.   
   >   
   > Note that I'm not trying to solve every problem in the   
   > world simultaneously. I have a specific EBCDIC use-case   
   > that I want to see work.   
   >   
   > > So, you can do what you want, by why complicate things   
   > > without need?   
   >   
   > To take the burden off the vast bulk of the terminal   
   > software. Terminal software already normally allows   
   > you to set the modem dial string, e.g. ATDP or ATDT.   
   > Why not ATDE?   
      
   Translation between 8-bit code pages can be done via   
   table lookup.  That costs 512 bytes (for two way   
   translation) and single indexed memory access per   
   character.  This is not much burden, either for   
   software or for hardware.  However, you need to   
   know which code page to use and when.  Sofware   
   simply is better place to put translation because   
   it anyway needs to know about state of connection,   
   so switching translation tables comes naturally.   
      
   But I will stop arguing here.  Apparently you   
   love solutions that other folks find awkward.   
   Since you are doing this, ulitmately your   
   opinion is most important here.   
      
   > > P.S. To folks who say that mainframe can not do ASYNC:   
   > > this was done via a hardware hack on mainframe side.   
   >   
   > Can you provide more details of this please?   
      
   Not much.  I was just a user (one of users as this   
   line was shared with several other folks).  The   
   guy who did that said that it was enough to add   
   one wire, to connect internal signal to external   
   connector.  He also said that transmissin was   
   via interrupts and that "IBM does not like   
   interrupts".  I take this to mean that each   
   character triggered a separate interrupt.   
   My guess is that the guy connected "external   
   interrupt" line (which IIUC is standard thing   
   for IBM processors) to parallel-port style   
   connector so that modem could interrupt the   
   mainframe.  Concerning "IBM does not like   
   interrupts": transmiting one character per   
   interrupt was horribly inefficient by IBM   
   standards.  Since this was single line, there   
   was no problem.  But the machine had probably   
   about 80 terminals connected using standard   
   IBM interfaces.  Running 80 terminals in   
   async mode probably would not work (I mean   
   running in hacky way without something   
   like 3705).   
      
   > Also, I assume that your VM/CMS software was still   
   > operating on line mode, you couldn't run a character-based   
   > application like micro-emacs?   
      
   I only used e-mail.  IIUC e-mail software were done   
   using standard CMS utilitis (including some hairy   
   scripts).  I really can not say it this was   
   line mode or 3270 emulation (AFAIK other terminals   
   were 3270).   
      
   For e-mail system felt sluggish, since   
   for other work I had fast PC I did not try other   
   things on mainframe.  Just as extra explantion:   
   on mainframe I got a single VM, limited to 8M   
   virtual memory that could run only single program   
   at given time (due to limitation of CMS).  On   
   PC I had 386 BSD and later Linux.  While I had   
   4M real memory I could get tens of megs virtual   
   memory.  And I could run time-consuming tasks   
   in background, without worry that other folks   
   get angry on me for blocking shared e-mail   
   connection.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)