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

According to Stephen Fuld  <sfuld@alumni.cmu.edu.invalid>:

On 6/28/2024 2:55 PM, Lawrence D'Oliveiro wrote:

On Fri, 28 Jun 2024 15:08:20 +0000, MitchAlsup1 wrote:
 

Lawrence D'Oliveiro wrote:
>

On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:

>

I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.

>

Did you make much use of LOCATE-style I/O?

>
No, I fond VSAM completely adequate for my needs.

 
This tends to confirm my suspicion that LOCATE-style I/O is too hedged
round with restrictions to be useful outside some limited set of
situations. Most of the time, it’s just not worth the trouble.

>
It really depends upon what you are doing. ...

Yes, and more often than not locate I/O is faster and easier. VSAM was
TSS' native file system. You used GET and PUT macros to read and write
files, and they had move and locate mode just like QSAM did for
OS-compatible disks and tapes. See this TSS programmer's manual,
starting on page 18. On TSS locate mode just told you where in virtual
storage the record was. When you touched the address, the page fault
caused the I/O.

https://bitsavers.org/pdf/ibm/360/tss/GC28-2056-2_Time_Sharing_System_Data_Management_Facilities_Dec77.pdf

As I think I said before, these days you map the file into your
address space and read or write it like a long string, so its all
locate all the time.

See for example my version of grepcidr which maps the file in and
chugs through it with a state machine, much faster than the old read a
line and use a RE:

https://github.com/jrlevine/grepcidr3

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly