On Sunday, December 26, 2021 at 10:22:29 PM UTC-6, muta...@gmail.com wrote:   
      
   > I think the difference between Unix and MVS, as    
   > operating systems - from a file processing API    
   > perspective - is that MVS deals with blocks while    
   > Unix deals with characters.    
   >    
   ~ a character is a block of one.   
      
   > I'm interested in block mode terminals. When you    
   > read data from a terminal, I think the OS/application    
   > should receive an interrupt when one of the following    
   > (set by the application) happens:    
   >    
   > 1. CR/LF/NL received.    
   > 2. XON received.    
   > 3. Any data at all received.    
   >    
   ~ Then what?  This seems like a time sink.  Maybe MVS is different, maybe this   
   control should be in a thread.   
      
   > When a terminal is in fullscreen mode, what I expect    
   > is that the server, when doing a read, sends an XON    
   > to let the terminal know that it is it's turn. And then    
   > when the terminal sends a character or sequence,    
   > it should terminate with XON to let the server know    
   > it is finished and started a read.    
   >    
   I'm confused, there is a serial transfer control for your terminal, how does   
   xmodem file transfer protocol play a role here?   
   The main point is:  the receiver is in control, either by issuing XON/XOFF or   
   DSR/DCD , CTS/RTS or what ever scheme. - see the references, i.e. handshake   
   protocol.   
      
   https://en.wikipedia.org/wiki/RS-232#Pinouts    
      
   This is such a big topic, where details matter, where to start?   
      
   > But if a zmodem file transfer is being done across    
   > the line, we are only expecting data. Or maybe it should    
      
   I assume you mean 'serial' RS232 line, where there are two lines - a transmit   
   (TX), and a receive (RX) lines.   
   These are unidirectional from the point of view of the TX device; TX data and   
   RX control codes. -And from the point of view of the RX device; RX data and TX   
   control codes.   
      
   > Or maybe it should    
   > be part of the zmodem (or zmodem+) protocol to send    
   > an XON after each block. The trouble is that XON normally    
   > implies that the terminal is about to go into read mode,    
   > but during a zmodem transfer there is simply more data    
   > transmitted.    
      
   Don't muddle the protocol - it's ACK & NAK.   
   >    
   > I'm still trying to figure out zmodem should ideally work    
   > on the mainframe.    
      
   How do you move files on and off the mainframe now?   
   >    
   > BFN. Paul.   
      
   o Transfers were receiver-driven; the transmitter would not send any data   
   until an initial  was sent by the receiver. This was a logical outcome of   
   the way the user interacted with the sending machine, which would be remotely   
   located. The user would    
   navigate to the requested file on the sending machine, and then ask that   
   machine to transfer it. Once this command was issued, the user would then   
   execute a command in their local software to start receiving. Since the delay   
   between asking the remote    
   system for the file and issuing a local command to receive was unknown, XMODEM   
   allowed up to 90 seconds for the receiver to begin issuing requests for data   
   packets.   
      
   https://en.wikipedia.org/wiki/XMODEM   
      
   Ref:   
   https://en.wikipedia.org/wiki/Flow_control_(data)   
   https://en.wikipedia.org/wiki/Software_flow_control   
      
   Enjoy!   
      
   Steve   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)