Re: ancient OS history, ARM is sort of channeling the IBM 360

Scott Lurndal wrote:

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

Lawrence D'Oliveiro wrote:

 

Presumably the downside of that was there was no such thing as
“stream- oriented” I/O: it was all record-based, just like

most of >> the other OSes.

 
For the business oriented and even scientific oriented applications
typically run on S/360, "stream oriented" I/O would have been a
distinct disadvantage.  COBOL I/O (and even Fortran I/O) is "record
oriented".  "byte oriented" I/O would ha made things harder for the
programer as well as much less efficient.
 
 

Unix was unique in hiding the need from applications/users to worry
about sector sizes when writing to files and reading from files.

But >> there was a significant overhead in that, at least in the
early years.

 
 
There still is additional overhead.  But the application amd
programming language mix has changed, so stream oriented I/O is now
the default.

 
Is there?   It's trivially easy to impose a record structure
on a stream of bytes,

Sure.  But you have taken a (typically now 4K) record structure on the
disk, treated it as a stream of bytes, then aggregating groupsof those
bytes into records.  This, while not a huge overhead, is *some*
additional overhead.

and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.

Yes.  Thus bypassing the overhead of the "stream of bytes" illusion. 

And even on the mainframes, the records were blocked and read
in larger chunks and the application deblocked them.

Sure.  But lets use a typical example of reading 80 column card images
blocked 10, so an 800 byte disk record (remember, this is IBM, CKD type
disks, so really 800 byte records on the disk).  So for ten out of
every eleven reads, the read verb just meant a single load of the base
address of the next record in the block.



--
 - Stephen Fuld
(e-mail address disguised to prevent spam)