| Re: Multics vs Unix [message #426565 is a reply to message #426557] |
Mon, 27 January 2025 17:57   |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 27 Jan 2025 15:45:18 -0700, Peter Flass wrote:
> Well, early timesharing systems such as PDP-11 systems or TSO.
Swapping was very common in those 1970s systems and earlier.
What happened to change things was 1) larger and cheaper RAM
configurations, and 2) worsening of the disparity in speeds between RAM
and backing store. So swapping was itself incurring increasing performance
costs.
|
|
|
|
| Re: Multics vs Unix [message #426566 is a reply to message #426559] |
Mon, 27 January 2025 18:02 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 27 Jan 2025 15:45:20 -0700, Peter Flass wrote:
> I first encountered the “create a new process” model on Unix, and my
> initial reaction was “that has to be extremely stupid and wasteful, who
> would want to do that?”
Unix was, I am pretty sure, seen as a big and slow OS compared to the
proprietary competition in its early days. Being a research project,
performance was (at least initially) not a high concern.
However, the abstractions it offered turned out to be very useful. Like
doing away with the traditional record blocking/deblocking layer, and have
the kernel itself offer up the abstraction of a file as a stream of n
arbitrary bytes, for any n ≥ 0, without rounding to some arbitrary “sector
size”. And yes, creating lots of processes at the drop of a hat, which
turned out to be quite an elegant way of performing many tasks.
In short, it succeeded because it made its users more productive than the
alternative platforms. And that continues to today, though with Unix being
supplanted by Linux.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426567 is a reply to message #426549] |
Mon, 27 January 2025 18:04 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 27 Jan 2025 07:09:48 -1000, Lynn Wheeler wrote:
> about the same time was "gold" from recent univ. graduate (tried to hire
> him at IBM, but no takers) that had ported unix to 370. ("gold" code
> name taken from "Au" - "Amdahl Unix")
Was it running on bare metal or under the VM hypervisor?
Because I believe Linux on IBM mainframes to this day runs as a VM, not on
bare metal. Not sure why.
|
|
|
|
| Re: Multics vs Unix [message #426568 is a reply to message #426558] |
Mon, 27 January 2025 18:05 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 27 Jan 2025 15:45:19 -0700, Peter Flass wrote:
> Multics shell was the inspiration for Unix version.
No, because MULTICS, for all its innovations, never had the concept of a
command processor running as a separate user process.
|
|
|
|
| Re: Multics vs Unix [message #426569 is a reply to message #426559] |
Mon, 27 January 2025 18:58 |
|
|
Originally posted by: Andy Walker
On 27/01/2025 22:45, Peter Flass wrote:
> I first encountered the “create a new process” model on Unix, and my
> initial reaction was “that has to be extremely stupid and wasteful, who
> would want to do that?”
So did I, and my initial reaction was "Thank goodness we don't
have to write 20 or 100 lines of job control[*] just to compile and run
a ten-line program" [which I guess answers your question].
____
* Admittedly largely packaged up into macros kindly written by
our computer centre, who thereby kept tight control over what
mere users were allowed to do.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Godfrey
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426570 is a reply to message #426567] |
Mon, 27 January 2025 19:27 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> Was it running on bare metal or under the VM hypervisor?
>
> Because I believe Linux on IBM mainframes to this day runs as a VM, not on
> bare metal. Not sure why.
80s claim that both IBM AIX/370 (from UCLA Locus) and Amdahl's GOLD ....
ran under vm370 ... because field hardware support CEs demanded
mainframe EREP .... to add mainframe EREP to them was several times
larger effort than just getting them to run on mainframe (so they ran
under VM370, relying on VM370 to provide the mainframe EREP).
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Multics vs Unix [message #426571 is a reply to message #426561] |
Mon, 27 January 2025 19:55 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> At the point I got into it, I don’t recall any messing with the nucleus
> being required. Of course the disadvantage was that, like windows shared
> libraries, DCSS could only need loaded at the address they occupied when
> saved.
at some point between vm370 and now, they converted DCSS kernel DMKSNT
savesys and loadsys to use the spool file system.
the os/360 convention/heritage was executable images had address
constants and the executable images had RLD information appended, which
could turn all address constants into fixed values at the point of
bringing the (linkedit/loader loading) executable images into memory.
Original/Early CMS implementation would "save" memory image of a loaded
executable image as "MODULE" filetype. Since a "MODULE" filetype no
longer required any storage modifications ... it could be R/O shared
across multiple virtual address spaces ... but at same fixed address
location across all virtual address spaces.
I would do some hacks of os/360 convention software to change all the
"relative" adcons to "fixed" displacements ... which would be added to
virtual address space specific location (sort of simulating the TSS/360
convention of location independent code) ... and enabling the
specification of location independent option ... where it could use
location other than possible default.
For non-shared R/O, an image could execute store operations into its own
image (both CMS "MODULE" filetype) and DCSS savesys & loadsys. An early
variation was booting MVT into a virtual machine ... and stopping it
near the end of MVT IPL and doing a savesys (using savesys/loadsys sort
of like image checkpoint) for a fast reboot (akin to some of the current
PC fast container bringups).
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426572 is a reply to message #426570] |
Mon, 27 January 2025 20:21 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lynn Wheeler <lynn@garlic.com> writes:
> 80s claim that both IBM AIX/370 (from UCLA Locus) and Amdahl's GOLD ....
> ran under vm370 ... because field hardware support CEs demanded
> mainframe EREP .... to add mainframe EREP to them was several times
> larger effort than just getting them to run on mainframe (so they ran
> under VM370, relying on VM370 to provide the mainframe EREP).
in gossiping with Amdahl people I mentioned IBM had special project for
AT&T where IBM had done a strip down of TSS/370 kernel called SSUP
(which included mainframe erep) which higher level part of UNIX kernel
was being layered on top ... besides effectively adding mainframe EREP
(more device support, etc) to UNIX kernel (for running on bare hardware)
it also got mainframe multiprocessor support.
I ask if Amdahl might consider doing something with GOLD and possibly
Simpson's Amdahl RASP
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
|
|
| Re: swapping, was Multics vs Unix [message #426574 is a reply to message #426557] |
Mon, 27 January 2025 22:20 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
>>> But note that the trend of falling memory prices was already becoming
>>> clear by the 1970s, if not earlier. The earliest batch systems only kept
>>> one program in memory at one time, and swapped it out for another one when
>>> it went into any kind of I/O wait, to keep the CPU busy...
>> They did no such thing.
>
> Well, early timesharing systems such as PDP-11 systems or TSO.
Timesharing systems all swapped because programs spent most of their
time waiting for people at terminals. That meant delays of at least
seconds so it made sense to spend a fraction of a second swapping to
disk.
Genrally speaking, batch systems only waited for tapes and disks. Swapping
wouldn't make sense because the swap disk would be no faster than the
device a program was waiting for. Indeed it might be the same device.
Starting in the 1960s there were plenty of batch systems that ran multiple
programs, switching back and forth when the programs were I/O bound, but the
programs were all in memory so it was just context switching, no extra I/O. Once
virtual memory and paging arrived, we can argue about whether the I/O for paging
was like swapping, although it is my strong impression that if a system's memory
was so overcommitted that it did a lot of paging, it was unlikely to get much
useful work done.
--
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
|
|
|
|
| Re: swapping, was Multics vs Unix [message #426575 is a reply to message #426574] |
Mon, 27 January 2025 22:23 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Tue, 28 Jan 2025 03:20:09 -0000 (UTC), John Levine wrote:
> Genrally speaking, batch systems only waited for tapes and disks.
> Swapping wouldn't make sense because the swap disk would be no faster
> than the device a program was waiting for. Indeed it might be the same
> device.
However ...
> Starting in the 1960s there were plenty of batch systems that ran
> multiple programs, switching back and forth when the programs were I/O
> bound, but the programs were all in memory so it was just context
> switching, no extra I/O.
Batch systems were older than this, though.
|
|
|
|
| Re: Multics vs Unix [message #426576 is a reply to message #426493] |
Mon, 27 January 2025 22:34 |
|
|
Originally posted by: Lawrence D'Oliveiro
On 25 Jan 2025 21:14:47 -0500, Rich Alderson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On 25 Jan 2025 19:49:40 -0500, Rich Alderson wrote:
>
>>> The separation of the command processor from the kernel was a feature
>>> of TENEX on the PDP-10 when UNICS was still being written on the
>>> PDP-7.
>
>> Did the "command processor" have any special privileges or status on
>> those systems?
>
>> On Unix it did not.
>
> It did not. The program EXEC.EXE was a vanilla an executable as you
> could wish for.
This article <https://gunkies.org/wiki/TENEX> says that TENEX was not
really innovative at all: it was basically a port of the OS for the SDS
940 that was created as part of “Project Genie” at UC Berkeley.
|
|
|
|
| LCM+L PDP-10 systems [was Re: Multics vs Unix] [message #426577 is a reply to message #426560] |
Tue, 28 January 2025 15:53 |
Rich Alderson
Messages: 528
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <mddwmei4e4c.fsf@panix5.panix.com>,
>> Rich Alderson <news@alderson.users.panix.com> wrote:
>>> (Yes, I've been a PDP-10 guy for more than 45 years, but I was a 36-370 guy
>>> for 10 years befreo that.)
>> I'm glad people are keeping the -10 alive. :-)
> Whatever happened to the -10 (and other hardware);from the LCM?
Several of the high-end items were sold at auction by Christie's.
As much of the PDP-10 hardware as could be acquired was rescued by another
Seattle computer museum, ICM.org
I have nothing to do with either, of course.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426579 is a reply to message #426567] |
Tue, 28 January 2025 18:45 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 27 Jan 2025 07:09:48 -1000, Lynn Wheeler wrote:
>
>> about the same time was "gold" from recent univ. graduate (tried to hire
>> him at IBM, but no takers) that had ported unix to 370. ("gold" code
>> name taken from "Au" - "Amdahl Unix")
>
> Was it running on bare metal or under the VM hypervisor?
>
> Because I believe Linux on IBM mainframes to this day runs as a VM, not on
> bare metal. Not sure why.
>
RAS. Lots of error reporting and recovery would otherwise have to be
duplicated. Technically it’s not VM, but an LPAR (I believe) which is part
of vm in microcode.
--
Pete
|
|
|
|
|
|
| Re: Multics vs Unix [message #426581 is a reply to message #426580] |
Tue, 28 January 2025 18:48 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Dallman <jgd@cix.co.uk> wrote:
> In article <87wmehmmqd.fsf@localhost>, lynn@garlic.com (Lynn Wheeler)
> wrote:
>
>> IMS kept physical disk addresses internally in data records for
>> related data
>
> Ouch!
This was pretty standard. IMS was a hierarchical system, but CODASYL
specified a network model like IDMS. All pointers were kept in the records.
GE had a system that implemented this, and was the model for CODASYL.
>
> John
>
[I don’t know what happened with this post. NewsTap had it stuck in the
outbox]
--
Pete
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426583 is a reply to message #426579] |
Tue, 28 January 2025 20:13 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Tue, 28 Jan 2025 16:45:22 -0700, Peter Flass wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Mon, 27 Jan 2025 07:09:48 -1000, Lynn Wheeler wrote:
>>
>>> about the same time was "gold" from recent univ. graduate (tried to
>>> hire him at IBM, but no takers) that had ported unix to 370. ("gold"
>>> code name taken from "Au" - "Amdahl Unix")
>>
>> Was it running on bare metal or under the VM hypervisor?
>>
>> Because I believe Linux on IBM mainframes to this day runs as a VM, not
>> on bare metal. Not sure why.
>>
> RAS. Lots of error reporting and recovery would otherwise have to be
> duplicated.
Look at it the other way: Linux already has extensive mechanisms for doing
exactly this sort of thing, which work across all its different platforms.
So the question becomes: would someone running Linux on an IBM mainframe
want to make a special case of that installation, or would they rather be
able to manage it with the same mechanisms as all their other Linux
installations?
|
|
|
|
| Re: Multics vs Unix [message #426584 is a reply to message #426580] |
Tue, 28 January 2025 20:14 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Tue, 28 Jan 2025 16:45:24 -0700, Peter Flass wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Mon, 27 Jan 2025 15:45:19 -0700, Peter Flass wrote:
>>
>>> Multics shell was the inspiration for Unix version.
>>
>> No, because MULTICS, for all its innovations, never had the concept of
>> a command processor running as a separate user process.
>>
> https://multicians.org/shell.html
You got misled by the term “shell“, didn’t you?
A MULTICS user normally did everything in a single process.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426585 is a reply to message #426579] |
Tue, 28 January 2025 22:01 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
>>> about the same time was "gold" from recent univ. graduate (tried to hire
>>> him at IBM, but no takers) that had ported unix to 370. ("gold" code
>>> name taken from "Au" - "Amdahl Unix")
>>
>> Was it running on bare metal or under the VM hypervisor?
>>
>> Because I believe Linux on IBM mainframes to this day runs as a VM, not on
>> bare metal. Not sure why.
>
> RAS. Lots of error reporting and recovery would otherwise have to be
> duplicated. Technically it’s not VM, but an LPAR (I believe) which is part
> of vm in microcode.
Does anything run on a bare zSeries machine? It is my impression that everything
is in an LPAR, partly for the RAS reason you mention, partly for flexibility so
one can borrow part of the system for testing or a short term project.
--
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
|
|
|
|
| Re: The history of "multi-programming" [message #426590 is a reply to message #426520] |
Wed, 29 January 2025 08:33 |
Bill Findlay
Messages: 297
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 26 Jan 2025, Lars Poulsen wrote
(in article<slrnvpchuc.18si6.lars@cleo.beagle-ears.com>):
> On 25 Jan 2025, Lawrence D'Oliveiro wrote (in article
> <vn1apj$2fink$2@dont-email.me>):
>>>> > But note that the trend of falling memory prices was already
>>>> > becoming clear by the 1970s, if not earlier. The earliest batch
>>>> > systems only kept one program in memory at one time, and swapped it
>>>> > out for another one when it went into any kind of I/O wait, to keep
>>>> > the CPU busy; later on, when memory became large enough (and cheap
>>>> > enough), it made sense to keep multiple programs resident at once
>>>> > ("multiprogramming", this was called), to allow the scheduling
>>>> > switches to happen more quickly.
>
> On Sun, 26 Jan 2025 00:05:16 +0000, Bill Findlay wrote:
>>>> They did no such thing.
>
> On 26 Jan 2025, Lawrence D'Oliveiro wrote
> (in article <vn44ht$37klv$2@dont-email.me>):
>>> They didn´t have enough RAM to do anything else.
>>> That´s why a special term
>>> had to be invented for the new feature.
>
> On 2025-01-26, Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
>> Nonsense.
>
> Be nice, be respectful.
Do try not to be patronising, Lars, my good fellow.
It would have made no sense to respond to an initial IO
waitby incurring a further 4 IO waits: swap out/in/out/in
since:
(a) the swaps out would not be possible while the
initial IO was still active in the initial job's core
(b) those systems did not have devices capable of swapping
the whole of core in significantly less time time than
the initial IO would take to finish.
So: literally, nonsense.
--
Bill Findlay
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426591 is a reply to message #426567] |
Wed, 29 January 2025 10:02 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 27 Jan 2025 07:09:48 -1000, Lynn Wheeler wrote:
>
>> about the same time was "gold" from recent univ. graduate (tried to hire
>> him at IBM, but no takers) that had ported unix to 370. ("gold" code
>> name taken from "Au" - "Amdahl Unix")
>
> Was it running on bare metal or under the VM hypervisor?
>
> Because I believe Linux on IBM mainframes to this day runs as a VM, not on
> bare metal. Not sure why.
When working on MVS and needing Unix, it makes the most sense to use
z/OS Unix. Unix runs in a TSO type environment providing a very
functional Unix environment.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426592 is a reply to message #426591] |
Wed, 29 January 2025 12:34 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> When working on MVS and needing Unix, it makes the most sense to use
> z/OS Unix. Unix runs in a TSO type environment providing a very
> functional Unix environment.
Late 80s, a IBM senior disk enginner got a talk scheduled at annual,
world-wide, internal communication group conference, supposedly on 3174
performance, but opened the talk with the statement that the
communication group was going to be responsible for the demise of of
disk division. The disk division was seeing data fleeing datacenters
with a drop in disk sales to more distributed computing friendly
platforms. They came up with a number of solutions that were all being
vetoed by the communication froup (with their corporate strategic
ownership of overything that crossed the datacenter walls, fiercely
fighting off client/server and distributed computing).
The disk divison executive responsible for software was coming up with
some work-arounds to the communication group; including investing in
distributed computing startups that would use IBM disks, he would
periodically ask us to visit his investments to see if we could offer
some help). He also paid for development of (UNIX) Posix implementation
for MVS (software, wasn't IBM physical hardware transmission product).
a couple years later, IBM has one of the largest losses in the history
of US corporations (wasn't just disks, impacting whole mainframe
datacenter market) and was being re-orged into the 13 "baby blues"
(take-off on AT&T "baby bells" breakup a decade earlier)
https://web.archive.org/web/20101120231857/http://www.time.c om/time/magazine/article/0,9171,977353,00.html
https://content.time.com/time/subscriber/article/0,33009,977 353-1,00.html
We had already left IBM but get a call from the bowels of Armonk
(hdqtrs) asking if we could help with the breakup. Before we get
started, the board brings in the former AMEX president as CEO to try and
save the company, who (somewhat) reverses the breakup (but it isn't long
before the disk division is gone).
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426593 is a reply to message #426592] |
Wed, 29 January 2025 13:00 |
|
|
Originally posted by: Lars Poulsen
Dan Espen <dan1espen@gmail.com> writes:
>> When working on MVS and needing Unix, it makes the most sense to use
>> z/OS Unix. Unix runs in a TSO type environment providing a very
>> functional Unix environment.
On 2025-01-29, Lynn Wheeler <lynn@garlic.com> wrote:
> The disk divison executive responsible for software was coming up with
> some work-arounds to the communication group; including investing in
> distributed computing startups that would use IBM disks, he would
> periodically ask us to visit his investments to see if we could offer
> some help). He also paid for development of (UNIX) Posix implementation
> for MVS (software, wasn't IBM physical hardware transmission product).
What kinds of /unix/linux/aix are in common use in IBM mainframe
environments today?
I know of z/Linux, which runs on z-series processors (including cheaper
ones cripped to NOT be able to run z/OS). I think there is also a
p-series unix, running on the POWER version of the processors. I wonder
if that is A/IX based?
But what is this z/OS Unix described above?
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426595 is a reply to message #426593] |
Wed, 29 January 2025 16:05 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lars Poulsen <lars@cleo.beagle-ears.com> writes:
> Dan Espen <dan1espen@gmail.com> writes:
>>> When working on MVS and needing Unix, it makes the most sense to use
>>> z/OS Unix. Unix runs in a TSO type environment providing a very
>>> functional Unix environment.
>
> On 2025-01-29, Lynn Wheeler <lynn@garlic.com> wrote:
>> The disk divison executive responsible for software was coming up with
>> some work-arounds to the communication group; including investing in
>> distributed computing startups that would use IBM disks, he would
>> periodically ask us to visit his investments to see if we could offer
>> some help). He also paid for development of (UNIX) Posix implementation
>> for MVS (software, wasn't IBM physical hardware transmission product).
>
> What kinds of /unix/linux/aix are in common use in IBM mainframe
> environments today?
>
> I know of z/Linux, which runs on z-series processors (including cheaper
> ones cripped to NOT be able to run z/OS). I think there is also a
> p-series unix, running on the POWER version of the processors. I wonder
> if that is A/IX based?
>
> But what is this z/OS Unix described above?
Sounds to me like you are asking Lynn, but I'll throw in my 2 cents.
I don't know of anyone using z/Linux.
Most mainframes are heavily committed to z/OS or z/DOS.
Z/OS Unix is a standard part of MVS.
You can run z/OS Unix commands under ISPF just like you can run TSO commands.
Just like invoking TSO from batch, you can also run z/OS Unix from batch jobs.
z/OS Unix is pretty much a full implementation of Unix.
In my work experience, I made some use of z/OS Unix for software
development. In general I found it to be more convenient to do Unix stuff
on my Linux desktop. Also batch TSO (or REXX) gives you just as much
function as Unix so I found z/OS Unix only slightly useful.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426596 is a reply to message #426595] |
Wed, 29 January 2025 18:01 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Wed, 29 Jan 2025 16:05:43 -0500, Dan Espen wrote:
> z/OS Unix is pretty much a full implementation of Unix.
Sounds like an emulation layer, like DG’s MV/UX and EUNICE for VMS of old.
I remember, I think it was the Perl build script, if it detected you were
running on a proper *nix system, the message would come up
Congratulations! You’re not running EUNICE!
Basically, these emulation layers on top of proprietary OSes were
inevitably crap.
And yes, I guess WSL1 for Windows falls in the same bin.
|
|
|
|
| Re: LCM+L PDP-10 systems [was Re: Multics vs Unix] [message #426603 is a reply to message #426578] |
Wed, 29 January 2025 19:11 |
Rich Alderson
Messages: 528
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Rich Alderson <news@alderson.users.panix.com> writes:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> In article <mddwmei4e4c.fsf@panix5.panix.com>,
>>>> Rich Alderson <news@alderson.users.panix.com> wrote:
>>>> > (Yes, I've been a PDP-10 guy for more than 45 years, but I was a 36-370
>>>> > guy for 10 years befreo that.)
>>>> I'm glad people are keeping the -10 alive. :-)
>>> Whatever happened to the -10 (and other hardware);from the LCM?
>> Several of the high-end items were sold at auction by Christie's.
>> As much of the PDP-10 hardware as could be acquired was rescued by another
>> Seattle computer museum, ICM.org
>> I have nothing to do with either, of course.
> Have you heard anything regarding the disposition of the V380?
I have not. All of the engineering staff were laid off as of 1 July 2020, and
the two people who took over dealing with the remains of the museum (an
archivist and a manager) were explicitly forbidden to talk to any of us about
what was happening.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: Multics vs Unix [message #426606 is a reply to message #426584] |
Wed, 29 January 2025 20:31 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Wed, 29 Jan 2025 01:14:34 -0000 (UTC), I wrote:
> On Tue, 28 Jan 2025 16:45:24 -0700, Peter Flass wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Mon, 27 Jan 2025 15:45:19 -0700, Peter Flass wrote:
>>>
>>>> Multics shell was the inspiration for Unix version.
>>>
>>> No, because MULTICS, for all its innovations, never had the concept of
>>> a command processor running as a separate user process.
>>>
>> https://multicians.org/shell.html
>
> You got misled by the term “shell“, didn’t you?
>
> A MULTICS user normally did everything in a single process.
Look at section 1.6.1 here <https://multicians.org/exec-env.html>:
1.6.1 How the Command processor uses processes
The cost of creating a Multics process is substantial, and this
led us to a design in which each user gets one process that is
used to run many commands, as opposed to the Unix design where
users get a fresh process for each command. The original plan for
each user's Multics environment was that every logged in user
would have three processes: an overseer process, a worker process,
and a utility process that (I think) handled I/O and allowed
debugging. The three process environment was never run; by the
time of the Phase One milestone in 1967, and from then on, each
Multics user had a single process. Because this process has a
complex address space and is expensive to create, it gets reused
by each command. A Multics process starts up in the "process
overseer" procedure specified in its accounting file: the standard
one calls the standard command processor (shell), which reads and
executes command lines. It does so by parsing the command line and
finding the program named as the first token: the shell just
obtains a pointer to this program and calls it. The dynamic
linking mechanism does most of the work, and the command becomes a
known segment in the process; subsequent executions of the command
will be faster.
Reusing the process this way is efficient, but if a command
scribbles on the ring-4 combined linkage and static segments, or
scrambles the stack threading, the user process can malfunction
and have to be destroyed. The new_proc command signals the
answering service to destroy the current user's process and create
a fresh one, about the same effect as logging out and back in
again. The user's process can also be terminated by encountering a
"simulated fault" caused by dereferencing a special pointer, or by
running out of stack.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426610 is a reply to message #426596] |
Thu, 30 January 2025 10:12 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 29 Jan 2025 16:05:43 -0500, Dan Espen wrote:
>
>> z/OS Unix is pretty much a full implementation of Unix.
>
> Sounds like an emulation layer, like DG’s MV/UX and EUNICE for VMS of old.
I don't know what those things are but I wouldn't call z/OS an emulation
layer. It looked and acted like a Unix implementation.
One a mainframe, there are a few issues to deal with to run Unix.
The common use terminal, a 3270 is not character at a time, data is
transferred in blocks with a pretty complex protocol. z/OS unix
couldn't do things like run Emacs on a 3270 but it did a reasonably good
job of providing a working stdin/stdout.
Another issue is the native disk file system where data is read in
blocks with predefined block sizes. z/OS Unix also did a pretty good
job with this. Also "normal" Unix file systems were accessible.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426611 is a reply to message #426610] |
Thu, 30 January 2025 10:56 |
|
|
Originally posted by: drb
> I don't know what those things are but I wouldn't call z/OS an emulation
> layer. It looked and acted like a Unix implementation.
Seems like it might be time to inject a reminder that "unix" sometimes
refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
API compliance.
De
|
|
|
|
| Unix (was: Re: old pharts, Multics vs Unix) [message #426612 is a reply to message #426611] |
Thu, 30 January 2025 11:18 |
|
|
Originally posted by: vallor
On Thu, 30 Jan 2025 15:56:22 +0000, Dennis Boone wrote:
>> I don't know what those things are but I wouldn't call z/OS an
emulation
>> layer. It looked and acted like a Unix implementation.
>
> Seems like it might be time to inject a reminder that "unix" sometimes
> refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
> compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
> API compliance.
I agree. "unix" or "Unix" is more about the API, and
""UNIX® is a registered trademark of The Open Group""
https://unix.org/trademark.html
So Linux is a Unix but not UNIX(R).
Oddly enough, MacOS is UNIX(R). I have a correspondent
who claims otherwise, but they haven't described what UNIX(R)
offers that MacOS doesn't. Nevertheless, I find it troublesome
to use because of its extra "security" features that hobble
ordinary usage. Example:
(base) Mac:~ scott$ cd Desktop/
(base) Mac:Desktop scott$ ls
ls: .: Operation not permitted
(base) Mac:Desktop scott$ ls -ld .
drwx------ 8 scott staff 256 Dec 13 13:45 .
(base) Mac:Desktop scott$ id
uid=502(scott) gid=20(staff) groups=20(staff),12(everyone),
61(localaccounts),79(_appserverusr),80(admin),81(_appservera dm),
98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore) ,
100(_lpoperator),204(_developer),250(_analyticsusers),
395(com.apple.access_ftp),398(com.apple.access_screensharing ),
399(com.apple.access_ssh),400(com.apple.access_remote_ae)
Oh, and see all those supplemental groups?
(base) Mac:Desktop scott$ getconf NGROUPS_MAX
16
So all those groups almost fill up the supplemental
groups array.
Back on friendly Linux:
$ getconf NGROUPS_MAX
65536
--
-Scott System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.13.0 Release: Mint 22.1 Mem: 258G
Linux user since 1992.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426613 is a reply to message #426611] |
Thu, 30 January 2025 11:29 |
cross
Messages: 55
Registered: May 2013
Karma: 0
|
Member |
|
|
In article <zg-dnUdXgZm7PAb6nZ2dnZfqnPadnZ2d@giganews.com>,
Dennis Boone <drb@ihatespam.msu.edu> wrote:
>> I don't know what those things are but I wouldn't call z/OS an emulation
>> layer. It looked and acted like a Unix implementation.
>
> Seems like it might be time to inject a reminder that "unix" sometimes
> refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
> compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
> API compliance.
"Unix" is a trademark, owned by The Open Group. Systems that
implement relevant standards and provide a common base of
utilities, libraries, etc, can apply for certification to use
the Unix trademark. Only a few still bother to do so: Apple,
IBM, HP and SCO. Of the IBM systems, versions of both AIX and
z/OS are certified Unix systems. So both AIX and z/OS are Unix.
Many other systems adhere closely to the the standards required
for Unix certification and provide the common utilities and so
forth, but don't bother with the laborious (and expensive)
certification process, and so can't technically call themselves
Unix. Most of these systems meet those criteria for all intents
and purposes and so are sort of de facto Unix, even if not
legally Unix. Among these are Linux, most of the BSD-derived
operating systems, QNX, and illumos (descendent of Solaris,
itself derived from SVR4).
Then there is the kernel lineage: at one point, "Unix" meant
sharing code with systems derived from early versions of
research Unix (e.g., 7th Edition, 32/V, 4BSD, SysIII and SysV,
etc). AIX and HP-UX both certainly fall into this category, as
did many of the now obsolete "commercial" Unixes of the 1980s
and 90s, but z/OS (as a whole) and Linux do not. The BSDs are
sort of weird in this regard: they are kind of the Ship of
Theseus of Unix in that they are directly descended from the
research Unix code base, but with all of the AT&T code rewritten
and replaced.
Then there are Unix-like systems that are designed for other
purposes, but neither descend from research Unix code nor try to
adhere to the standards mentioned before. Many of these are
research or pedagogical systems, such as Comer's Xinu, xv6 and
its derivatives (rxv64 [disclaimer: I wrote that]; sv6, and the
early versions of Minix. Mach and similar research systems fit
into a weird quasi-independent space, as Mach started from 4BSD
but is for all intents its own thing now.
Then there are hybrids like OSF/1, etc.
I've found that when one refers to "Unix" one is generally being
imprecise, and the exact meaning depends on context. Often it's
just a shorthand for "looks and behaves substantially as one
expects based on familiarity with other Unix systems." So when
one is talking generically about "Unix" one may also mean Linux,
BSD, etc, even though those are technically not "Unix" in the
sense of being certified to use the trademark, or sharing code
with Bell/AT&T/USL/whatever code.
- Dan C.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426614 is a reply to message #426610] |
Thu, 30 January 2025 11:37 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> One a mainframe, there are a few issues to deal with to run Unix.
> The common use terminal, a 3270 is not character at a time, data is
> transferred in blocks with a pretty complex protocol. z/OS unix
> couldn't do things like run Emacs on a 3270 but it did a reasonably good
> job of providing a working stdin/stdout.
70s 3272/3277 had .089sec hardware response ... then 80 came 3274/3278
where lots of electronics were moved out of terminal back into 3274
controller (reducing 3278 manufacturing cost) ... significantly driving
up the coax protocol chatter and latency ... and hardware response went
to .3sec-.5sec (depending on amount of data transferred). This was in
period of studies showing improved human productivity with .25sec
"response" (seen by human) ... with 3272/3277 required .161 system
response (plus terminal hardware .089) to give .25sec human response.
after joining ibm, one of my hobbies was enhanced production operating
systems for internal datacenters. circa 1980, rare MVS/TSO system was
lucky to see even 1sec interactive system response (and nearly all much
worse) ... some number of internal VM370 systems were claiming .25sec
interactive system response ... but I had lots of internal systems with
..11sec interactive system response (giving .199 response seeen by
human w/3277).
Letters to the 3278 product administrator complaining about 3278 for
interactive computing got reply that 3278 wasn't intended for
interactive computing, but "data entry" (aka electronic keypunch).
Later IBM/PC hardware 3277 emulation cards had 4-5 times the
upload/download throughput of 3278 emulation cards.
however, all 3270s were half-duplex and if you were unfortunate to hit a
key same time system went to write to screen, it would lock the keyboard
and would have to stop and hit the reset key. YKT developed a FIFO box
for 3277, unplug the keyboard from the 3277 head, plug the FIFO box into
the head and plug the 3277 keyboard into the fifo box ... eliminating
the unfortunate keyboad lock.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426615 is a reply to message #426613] |
Thu, 30 January 2025 11:48 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <zg-dnUdXgZm7PAb6nZ2dnZfqnPadnZ2d@giganews.com>,
> Dennis Boone <drb@ihatespam.msu.edu> wrote:
>>> I don't know what those things are but I wouldn't call z/OS an emulation
>>> layer. It looked and acted like a Unix implementation.
>>
<snip>
> Many other systems adhere closely to the the standards required
> for Unix certification and provide the common utilities and so
> forth, but don't bother with the laborious (and expensive)
> certification process, and so can't technically call themselves
> Unix. Most of these systems meet those criteria for all intents
> and purposes and so are sort of de facto Unix, even if not
> legally Unix. Among these are Linux, most of the BSD-derived
> operating systems, QNX, and illumos (descendent of Solaris,
> itself derived from SVR4).
I wouldn't necessarily say 'derived'. Sun and USL worked
together on SVR4, with SVR4 adopting several features
from SunOS including a bunch of UCB usermode stuff.
> Then there are hybrids like OSF/1, etc.
And Chorus/MIX and SVR4/Mk (aka Amadeus[*])
[*] USL, Unisys, ICL (Fujitsu), Chorus Systemes, et al.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426616 is a reply to message #426583] |
Thu, 30 January 2025 13:33 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 28 Jan 2025 16:45:22 -0700, Peter Flass wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Mon, 27 Jan 2025 07:09:48 -1000, Lynn Wheeler wrote:
>>>
>>>> about the same time was "gold" from recent univ. graduate (tried to
>>>> hire him at IBM, but no takers) that had ported unix to 370. ("gold"
>>>> code name taken from "Au" - "Amdahl Unix")
>>>
>>> Was it running on bare metal or under the VM hypervisor?
>>>
>>> Because I believe Linux on IBM mainframes to this day runs as a VM, not
>>> on bare metal. Not sure why.
>>>
>> RAS. Lots of error reporting and recovery would otherwise have to be
>> duplicated.
>
> Look at it the other way: Linux already has extensive mechanisms for doing
> exactly this sort of thing, which work across all its different platforms.
>
> So the question becomes: would someone running Linux on an IBM mainframe
> want to make a special case of that installation, or would they rather be
> able to manage it with the same mechanisms as all their other Linux
> installations?
>
You wouldn’t buy a mainframe to run Linux. I would think the typical
customer is already running a zOS, zVM, or zTPF workload and wants to add
Linux to it.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426617 is a reply to message #426611] |
Thu, 30 January 2025 13:33 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dennis Boone <drb@ihatespam.msu.edu> wrote:
>> I don't know what those things are but I wouldn't call z/OS an emulation
>> layer. It looked and acted like a Unix implementation.
>
> Seems like it might be time to inject a reminder that "unix" sometimes
> refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
> compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
> API compliance.
>
> De
>
I think they got the right to call it “unix”, but I could be mistaken. It
used to be “unix system services”.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426620 is a reply to message #426613] |
Thu, 30 January 2025 13:33 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <zg-dnUdXgZm7PAb6nZ2dnZfqnPadnZ2d@giganews.com>,
> Dennis Boone <drb@ihatespam.msu.edu> wrote:
>>> I don't know what those things are but I wouldn't call z/OS an emulation
>>> layer. It looked and acted like a Unix implementation.
>>
>> Seems like it might be time to inject a reminder that "unix" sometimes
>> refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
>> compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
>> API compliance.
>
> "Unix" is a trademark, owned by The Open Group. Systems that
> implement relevant standards and provide a common base of
> utilities, libraries, etc, can apply for certification to use
> the Unix trademark. Only a few still bother to do so: Apple,
> IBM, HP and SCO. Of the IBM systems, versions of both AIX and
> z/OS are certified Unix systems. So both AIX and z/OS are Unix.
>
> Many other systems adhere closely to the the standards required
> for Unix certification and provide the common utilities and so
> forth, but don't bother with the laborious (and expensive)
> certification process, and so can't technically call themselves
> Unix. Most of these systems meet those criteria for all intents
> and purposes and so are sort of de facto Unix, even if not
> legally Unix. Among these are Linux, most of the BSD-derived
> operating systems, QNX, and illumos (descendent of Solaris,
> itself derived from SVR4).
>
> Then there is the kernel lineage: at one point, "Unix" meant
> sharing code with systems derived from early versions of
> research Unix (e.g., 7th Edition, 32/V, 4BSD, SysIII and SysV,
> etc). AIX and HP-UX both certainly fall into this category, as
> did many of the now obsolete "commercial" Unixes of the 1980s
> and 90s, but z/OS (as a whole) and Linux do not. The BSDs are
> sort of weird in this regard: they are kind of the Ship of
> Theseus of Unix in that they are directly descended from the
> research Unix code base, but with all of the AT&T code rewritten
> and replaced.
>
> Then there are Unix-like systems that are designed for other
> purposes, but neither descend from research Unix code nor try to
> adhere to the standards mentioned before. Many of these are
> research or pedagogical systems, such as Comer's Xinu, xv6 and
> its derivatives (rxv64 [disclaimer: I wrote that]; sv6, and the
> early versions of Minix. Mach and similar research systems fit
> into a weird quasi-independent space, as Mach started from 4BSD
> but is for all intents its own thing now.
>
> Then there are hybrids like OSF/1, etc.
>
> I've found that when one refers to "Unix" one is generally being
> imprecise, and the exact meaning depends on context. Often it's
> just a shorthand for "looks and behaves substantially as one
> expects based on familiarity with other Unix systems." So when
> one is talking generically about "Unix" one may also mean Linux,
> BSD, etc, even though those are technically not "Unix" in the
> sense of being certified to use the trademark, or sharing code
> with Bell/AT&T/USL/whatever code.
>
I like Unix vs. Unix(R), that’s a great way to differentiate. Just like it
used to be with IBM “standards”back in the day, I suspect Linux is driving
the bus these days.
--
Pete
|
|
|
|
| Re: Unix (was: Re: old pharts, Multics vs Unix) [message #426621 is a reply to message #426612] |
Thu, 30 January 2025 14:19 |
|
|
Originally posted by: Mister Johnson
On 2025-01-30, vallor <vallor@cultnix.org> wrote:
[...]
> (base) Mac:~ scott$ cd Desktop/
> (base) Mac:Desktop scott$ ls
> ls: .: Operation not permitted
> (base) Mac:Desktop scott$ ls -ld .
> drwx------ 8 scott staff 256 Dec 13 13:45 .
[...]
that's odd!
% cd Desktop/
% ls
[lots of stuff]
% ls -ld .
drwx------@ 129 foo staff 4128 22 Jan 22:17 .
% ls -lde .
drwx------@ 129 foo staff 4128 22 Jan 22:17 .
0: group:everyone deny delete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426622 is a reply to message #426616] |
Thu, 30 January 2025 14:45 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
> You wouldn’t buy a mainframe to run Linux. I would think the typical
> customer is already running a zOS, zVM, or zTPF workload and wants to add
> Linux to it.
You might think so but IBM has this thing called LinuxONE which is a
zSeries machine with microcode tweaks so it can ron linux but not
z/OS or other operating systems. I gather it is cheaper than
the untweaked Z:
https://www.ibm.com/products/linuxone-4
You'd use it for the same reason you'd use any other mainframe,
extremely high reliability with uptime measured in years and
sometimes decades. They can swap out entire hardware subsystems
without rebooting. It's the Computer of Theseus.
--
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
|
|
|
|
| Re: Unix [message #426623 is a reply to message #426612] |
Thu, 30 January 2025 15:24 |
|
|
Originally posted by: geodandw
On 1/30/25 11:18, vallor wrote:
> On Thu, 30 Jan 2025 15:56:22 +0000, Dennis Boone wrote:
>
>>> I don't know what those things are but I wouldn't call z/OS an
> emulation
>>> layer. It looked and acted like a Unix implementation.
>>
>> Seems like it might be time to inject a reminder that "unix" sometimes
>> refers to kernel (AIX is not unix, etc.) and sometimes to API (POSIX
>> compliance might be thought of as "unix"). IIRC the z/OS unix stuff is
>> API compliance.
>
> I agree. "unix" or "Unix" is more about the API, and
>
> ""UNIX® is a registered trademark of The Open Group""
>
> https://unix.org/trademark.html
>
> So Linux is a Unix but not UNIX(R).
>
> Oddly enough, MacOS is UNIX(R). I have a correspondent
> who claims otherwise, but they haven't described what UNIX(R)
> offers that MacOS doesn't. Nevertheless, I find it troublesome
> to use because of its extra "security" features that hobble
> ordinary usage. Example:
>
> (base) Mac:~ scott$ cd Desktop/
> (base) Mac:Desktop scott$ ls
> ls: .: Operation not permitted
> (base) Mac:Desktop scott$ ls -ld .
> drwx------ 8 scott staff 256 Dec 13 13:45 .
> (base) Mac:Desktop scott$ id
> uid=502(scott) gid=20(staff) groups=20(staff),12(everyone),
> 61(localaccounts),79(_appserverusr),80(admin),81(_appservera dm),
> 98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore) ,
> 100(_lpoperator),204(_developer),250(_analyticsusers),
> 395(com.apple.access_ftp),398(com.apple.access_screensharing ),
> 399(com.apple.access_ssh),400(com.apple.access_remote_ae)
>
> Oh, and see all those supplemental groups?
>
> (base) Mac:Desktop scott$ getconf NGROUPS_MAX
> 16
>
> So all those groups almost fill up the supplemental
> groups array.
>
> Back on friendly Linux:
>
> $ getconf NGROUPS_MAX
> 65536
>
Since MacOS is based on BSD, why is this surprising?
|
|
|
|
Members
Search
Help
Register
Login
Home
