Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: time-sharing history, Privilege Levels Below User Date: Wed, 12 Jun 2024 15:19:14 -1000 Organization: Wheeler&Wheeler Lines: 53 Message-ID: <87tthx1vxp.fsf@localhost> References: <87y17925e8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 13 Jun 2024 03:19:16 +0200 (CEST) Injection-Info: dont-email.me; posting-host="44822fe9b3333450d8ff8c92dd7086c9"; logging-data="2018100"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181hf4NMIIrECCVEYHfAVt8uls9Oa2z4TE=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:iz09mp65qXN/GkswddQ1iXh7L/8= sha1:5izJe3tOc7gA8YyfBVxauHssDcQ= Bytes: 3918 Lawrence D'Oliveiro writes: > I recall CMS was single-user to start with, and the point of running it > under “CP” aka “VM” was to offer a multi-user service. Did CMS ever become > multi-user in its own right? over years relying more & more on CP kernel services, no multi-user .... but did get multitasking https://www.ibm.com/docs/en/zvm/7.3?topic=cms-application-multitasking https://www.ibm.com/docs/en/zvm/7.3?topic=programming-zvm-cms-application-multitasking https://www.vm.ibm.com/pubs/redbooks/sg245164.pdf original CMS that could run on real hardware support SIO and channel programs for file i/o ... a CP "diagnose" function for CMS file i/o was added to CP/67 that ran purely synchronous (didn't return to CMS until file I/O was completed) ... in transition to VM370, CMS went purely for CP "diagnose" (and SIO capability was eliminated). When I joined science center and also saw the virtual memory file support by MULTICS ... I figured I could do one for CMS ... that scaled up faster than the normal file I/O operation ... and I claimed I learned what not to do for a page-mapped filesystem from TSS/360 (part of TSS/360 was just memory mapped the filesystem then mostly faulted in pages ... while I did combination of memory mapping and pre-fetching, read-ahead and write-behind support). Some of the IBM Future System issues was specifying a TSS/360-like filesystem ... one of the last nails in the FS coffin was study that showed if 370/195 applications were ported to FS machine made out of the fastest available hardware, it would have throughput of 370/145 (about 30 times slowdown ... part of it was serialization of file i/o). Some existing FS descriptions talk about how FS lived on with S/38 ... for entry-level business operation ... there was sufficient hardware performance provide necessary throughput for the s/38 market. In any case, the FS implosion contributed to memory mapped filesystem implementations acquiring very bad reputation inside IBM. In 1980s, I could show that heavily loaded, high-end systems with 3380 (3mbyte/sec disks) running my page-mapped CMS filesystem had at least three times the sustained throughput of standard CMS filesystems, some FS http://www.jfsowa.com/computer/memo125.htm https://people.computing.clemson.edu/~mark/fs.html trivia: my brother was regional Apple rep (largest physical area CONUS) and when he came into town, I could be invited to business dinners and argue MAC design (even before MAC announced). He also figured out how to remotely dial into the S/38 that ran Apple to monitor manufacutring and delivery schedules. -- virtualization experience starting Jan1968, online at home since Mar1970