block mode

[muta...@gmail.com]

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.

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.

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.

But if a zmodem file transfer is being done across
the line, we are only expecting data. 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.

I'm still trying to figure out zmodem should ideally work
on the mainframe.

BFN. Paul.

[s_dub...@yahoo.com]

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 <NAK> 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

[muta...@gmail.com]

On Wednesday, December 29, 2021 at 3:22:53 PM UTC+11, s_dub...@yahoo.com wrote:

> > 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.

I'm interested in a solution for a single-tasking system
like MSDOS, but that also works for block mode
devices.

> > 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 above has no relationship to xmodem (or zmodem).

It is just a protocol for terminal interaction. For some reason
when you press 'a' on your VT100 terminal currently, just the
letter 'a' is sent to the host system. I would have expected the
terminal to switch to read mode after sending the 'a', and to
inform the host that it is in read mode by sending an XON.

So I expect 2 characters to be sent - 'a' and XON. Assuming
the VT100 terminal is actually a computer running a single-tasking
OS like MSDOS and the host is another single-tasking OS like
MSDOS.

(basically I'm after a solution for single-tasking PDOS).

> > 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.

It's zmodem I am interested in, not xmodem. And it looks like
zmodem already takes XON into account:

http://gallium.inria.fr/~doligez/zmodem/zmodem.txt

ZMODEM accommodates a wide variety of systems:

+ Microcomputers that cannot overlap disk and serial i/o

+ Microcomputers that cannot overlap serial send and receive

+ Computers and/or networks requiring XON/XOFF flow control

An XON character is appended to all HEX packets except ZACK and ZFIN. The
XON releases the sender from spurious XOFF flow control characters
generated by line noise, a common occurrence.


I think by insisting on single-tasking and pure C90
I am creating a system that meets some of those
characteristics. Not 100% sure though.

> > 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?

Emulated tape.

BFN. Paul.