Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Tue, 25 Jun 2024 15:30:28 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <v5enqj$1k5g7$1@dont-email.me>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com> <v5an0l$10bj$1@gal.iecc.com> <87le2vatq4.fsf@localhost> <v5asis$p33t$1@dont-email.me> <v5dfkf$1h3e$3@gal.iecc.com> <v5dl6f$1dttg$1@dont-email.me> <v5eln4$1jpnm$1@dont-email.me> <3XAeO.24906$Gurd.8658@fx34.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 25 Jun 2024 17:30:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c54e9456f016d4223881dc0a49e6a9e3";
	logging-data="1709575"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19QCgxvcDJ+c7dkrXfEFAJtDfH/3sxWTD8="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:rSZ8yhoN0sz/auOHELFr6YcMl+8=
Bytes: 3321

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)