For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
In the IBM system, communication between users would have required
communication between VMs. In other words, a (virtual) peer-to-peer
network. But IBM didnrCOt have anything like that for close to another
two decades.
Depends on what you mean "close to that". The VMCF facility provided a >transport, but there wasn't much that used it until TCP/IP ....
... but users could send messages and files to each other, and between >machines which was sufficient.....
Sort of. TSS programs had CSECTs which were read-only and position independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process
This is not all that different from ELF shared libraries in Unix
and linux, which have position independent pages and the PLT and
GOT with process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all
in much more detail.
node nntp.mjs post <group> <subject> <body>
For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position independent
with one copy shared among all processes, and PSECTs which were read-write and
needed a separate copy per process which had pointers that were relocated when
loaded. The calling sequence had a pair of addresses for each routine, one to the PSECT (the R-con) and one to the CSECT (the V-con). In retrospect it would
have made more sense to use one address for the PSECT and pick up the code address from a known location in the PSECT. My guess is that they hoped there would be routines with no static data so they could skip the R-con, but as far
as I know they never did that.
It is easy to write position independent 360 code since all references are relative to base registers. You load a base register to point to wherever the code is (BALR R,0 was the usual way) and off you go. The routine would keep a pointer to the PSECT in another register set up from the calling sequence, so the routine can directly address both its code and its data without extra instructions. The calling sequence was slower than the OS/360 version, but even the OS version was quite slow with register saves and save area chaining.
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
John Levine wrote:
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process
The CSECT/PSECT split maps almost exactly to modern text/data
segments in ELF. The R-con/V-con pair in the calling sequence
is what surprises me - carrying two pointers per routine where
a single indirection through the PSECT would have worked.
This is not all that different from ELF shared libraries in Unix
and linux, which have position independent pages and the PLT and
GOT with process-specific pointers to the shared code.
The GOT is basically the PSECT pointer table extracted into its
own section. Were the ELF designers directly aware of TSS or did
they arrive at the same solution independently? Position
independent shared code has a limited number of clean solutions.
On 3/30/26 17:58, John Levine wrote:
Highly recommended. I have a copy sitting on my shelf now.For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process which had
pointers that were relocated when loaded. The calling sequence had a
pair of addresses for each routine, one to the PSECT (the R-con) and
one to the CSECT (the V-con). In retrospect it would have made more
sense to use one address for the PSECT and pick up the code address
from a known location in the PSECT. My guess is that they hoped there
would be routines with no static data so they could skip the R-con, but
as far as I know they never did that.
It is easy to write position independent 360 code since all references
are relative to base registers. You load a base register to point to
wherever the code is (BALR R,0 was the usual way) and off you go. The
routine would keep a pointer to the PSECT in another register set up
from the calling sequence,
so the routine can directly address both its code and its data without
extra instructions. The calling sequence was slower than the OS/360
version, but even the OS version was quite slow with register saves and
save area chaining.
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with
process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
On Tue, 31 Mar 2026 07:35:37 -0700, Peter Flass wrote:
On 3/30/26 17:58, John Levine wrote:
Highly recommended. I have a copy sitting on my shelf now.For TSS/360 all address constants have to be copied and relocated each >>>> time a program is loaded, and then it needs two memory fetches instead >>>> of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process which had
pointers that were relocated when loaded. The calling sequence had a
pair of addresses for each routine, one to the PSECT (the R-con) and
one to the CSECT (the V-con). In retrospect it would have made more
sense to use one address for the PSECT and pick up the code address
from a known location in the PSECT. My guess is that they hoped there
would be routines with no static data so they could skip the R-con, but
as far as I know they never did that.
It is easy to write position independent 360 code since all references
are relative to base registers. You load a base register to point to
wherever the code is (BALR R,0 was the usual way) and off you go. The
routine would keep a pointer to the PSECT in another register set up
from the calling sequence,
so the routine can directly address both its code and its data without
extra instructions. The calling sequence was slower than the OS/360
version, but even the OS version was quite slow with register saves and
save area chaining.
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with
process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
I have every book in that series, if you're referring to the Macdonald/ Elsevier set.
I also have the Levine book.
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
The TSS/360 story is new to me. Twenty users on a 360/67 and itNot sure, do you mean the software architecture of TSS or the Hardware >>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>managed more users than that with reasonable response time on a 360/67.
struggled? How much of that was the large-team bloat you're describing >>>> versus actual architectural problems?
A combination of overeager software architecture and implementation.
CP/67 and MTS both got good performance from the same hardware.
AFAICS main factor was that TSS/360 was too big, which left too
little core for users which lead to intensive paging when one
tried to increase number of users. Also, VM quite early got
good paging algorithm, other IBM systems used worse algorithms
and improved them only later.
In a sense one can say that TSS/360 was ahead of it times: on
bigger machine smaller fraction of machine would be occupied
by system code so memory available for user whould be significantly
bigger. IIUC already on 2MB machine TSS/360 behaved much better.
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific >pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
In the IBM system, communication between users would have required
communication between VMs. In other words, a (virtual) peer-to-peer
network. But IBM didnrCOt have anything like that for close to another
two decades.
Depends on what you mean "close to that". The VMCF facility provided a >>transport, but there wasn't much that used it until TCP/IP ....
... but users could send messages and files to each other, and between >>machines which was sufficient.....
You could hook the virtual card punch in one machine to the virtual reader
in another through a virtual card chute. The RSCS daemon used that to >communicate with other processes on the same machine, and over networks
to other machines. That was BITNET which grew to 3000 nodes and provided >email and a vibrant community of discussion lists in the late 1980s.
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with >>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
I can't lie, your book on the subject is fantastic. And I think it is
still one of the _only_ books available on linkers and loaders
specifically?
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific >>pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
I can't lie, your book on the subject is fantastic. And I think
it is still one of the _only_ books available on linkers and
loaders specifically?
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> >>wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>linux, which have position independent pages and the PLT and GOT with >>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>still one of the _only_ books available on linkers and loaders >>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> >>>wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>>linux, which have position independent pages and the PLT and GOT with >>>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>>still one of the _only_ books available on linkers and loaders >>>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I can't >find a mention online, but I have a copy.
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I can't >find a mention online, but I have a copy.
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part of the>> pitch was that there had been linkers and loaders since the late 1940sThere had been an entire book, but it was only a monograph really. I can't find a mention online, but I have a copy.
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
In article <n3488uF2repU8@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine >>>><johnl@taugh.com>
wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>>>linux, which have position independent pages and the PLT and GOT with >>>>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>>>still one of the _only_ books available on linkers and loaders >>>>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of
the pitch was that there had been linkers and loaders since the late
1940s but there'd never been more than the occasional article or
chapter. So either this was the book that the world had been awaiting
for half a century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I
can't find a mention online, but I have a copy.
What was the title? And who are/were the author(s)?
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
1940s but there'd never been more than the occasional article orpitch was that there had been linkers and loaders since the late
chapter. So either this was the book that the world had been awaiting
for half a century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaitingpitch was that there had been linkers and loaders since the late >>>> 1940s but there'd never been more than the occasional article or
for half a century, or this will prove that there is no market for it. >>>> It kind of did both, never selling huge numbers but still in print.
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go
and find it!
Bob Eager <news0009@eager.cx> writes:
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaiting >>>>> for half a century, or this will prove that there is no market for it. >>>>> It kind of did both, never selling huge numbers but still in print.pitch was that there had been linkers and loaders since the late >>>>> 1940s but there'd never been more than the occasional article or
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go >>and find it!
https://archive.org/details/assemblersloader0000barr/page/n1/mode/2up
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
Bob Eager <news0009@eager.cx> writes:
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaiting >>>>> for half a century, or this will prove that there is no market for it. >>>>> It kind of did both, never selling huge numbers but still in print.pitch was that there had been linkers and loaders since the late >>>>> 1940s but there'd never been more than the occasional article or
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go
and find it!
https://archive.org/details/assemblersloader0000barr/page/n1/mode/2up
On Wed, 1 Apr 2026 17:15:19 +0100, Andy Walker wrote:
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
How about Ulrich DrepperrCOs 47-page document on rCLHow To Write Shared >LibrariesrCY, written a couple of decades ago? He is/was the principal >maintainer of GNU libc. So he goes into issues like versioning and
backward compatibility, which is a lot more important on Linux systems
today than it was back on computer systems of, say, the 1980s.
According to Waldek Hebisch <antispam@fricas.org>:
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
The TSS/360 story is new to me. Twenty users on a 360/67 and itNot sure, do you mean the software architecture of TSS or the Hardware >>>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>>managed more users than that with reasonable response time on a 360/67.
struggled? How much of that was the large-team bloat you're describing >>>>> versus actual architectural problems?
A combination of overeager software architecture and implementation.
CP/67 and MTS both got good performance from the same hardware.
AFAICS main factor was that TSS/360 was too big, which left too
little core for users which lead to intensive paging when one
tried to increase number of users. Also, VM quite early got
good paging algorithm, other IBM systems used worse algorithms
and improved them only later.
That was certainly part of it. It was also quite buggy, with the bugginess inversely proportional to how heavily used a component was. The file system worked pretty well but I gather magtape support didn't.
In a sense one can say that TSS/360 was ahead of it times: on
bigger machine smaller fraction of machine would be occupied
by system code so memory available for user whould be significantly
bigger. IIUC already on 2MB machine TSS/360 behaved much better.
Well, there's a rule of thumb that the way you get good performance from
a paging system is to have enough RAM that you don't have to page.
Lev wrote:
node nntp.mjs post <group> <subject> <body>
Your innards are showing ...
John Levine <johnl@taugh.com> wrote:
According to Waldek Hebisch <antispam@fricas.org>:
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
A combination of overeager software architecture and implementation.The TSS/360 story is new to me. Twenty users on a 360/67 and itNot sure, do you mean the software architecture of TSS or the Hardware >>>>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>>>managed more users than that with reasonable response time on a 360/67. >>>>
struggled? How much of that was the large-team bloat you're describing >>>>>> versus actual architectural problems?
CP/67 and MTS both got good performance from the same hardware.
AFAICS main factor was that TSS/360 was too big, which left too
little core for users which lead to intensive paging when one
tried to increase number of users. Also, VM quite early got
good paging algorithm, other IBM systems used worse algorithms
and improved them only later.
That was certainly part of it. It was also quite buggy, with the bugginess >> inversely proportional to how heavily used a component was. The file system >> worked pretty well but I gather magtape support didn't.
In a sense one can say that TSS/360 was ahead of it times: on
bigger machine smaller fraction of machine would be occupied
by system code so memory available for user whould be significantly >>>bigger. IIUC already on 2MB machine TSS/360 behaved much better.
Well, there's a rule of thumb that the way you get good performance from
a paging system is to have enough RAM that you don't have to page.
To explain more what I mean: if one have 1MB machine and OS takes
800 kB for itself, then one has about 200 kB for user programs.
If OS takes 400 kB, then one has about 600 kB for user programs.
I this case smaller system effectively has 3 times more memory
available for user programs. On 2 MB machine (assuming the same
OS use) ratio is closer to 4/3, still giving advantage to smaller
system, but this advantage is much smaller.
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of
There had been an entire book, but it was only a monograph really. I can't >> find a mention online, but I have a copy.-a-a-a-aDavid Barron's 1068 monograph?-a This is called "Assemblers and Loaders", [...].
In article <10qk9ea$6jl0$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
John Levine <johnl@taugh.com> wrote:
According to Waldek Hebisch <antispam@fricas.org>:
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
A combination of overeager software architecture and implementation. >>>>> CP/67 and MTS both got good performance from the same hardware.The TSS/360 story is new to me. Twenty users on a 360/67 and itNot sure, do you mean the software architecture of TSS or the Hardware >>>>>> architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>>>> managed more users than that with reasonable response time on a 360/67. >>>>>
struggled? How much of that was the large-team bloat you're describing >>>>>>> versus actual architectural problems?
AFAICS main factor was that TSS/360 was too big, which left too
little core for users which lead to intensive paging when one
tried to increase number of users. Also, VM quite early got
good paging algorithm, other IBM systems used worse algorithms
and improved them only later.
That was certainly part of it. It was also quite buggy, with the bugginess >>> inversely proportional to how heavily used a component was. The file system
worked pretty well but I gather magtape support didn't.
In a sense one can say that TSS/360 was ahead of it times: on
bigger machine smaller fraction of machine would be occupied
by system code so memory available for user whould be significantly
bigger. IIUC already on 2MB machine TSS/360 behaved much better.
Well, there's a rule of thumb that the way you get good performance from >>> a paging system is to have enough RAM that you don't have to page.
To explain more what I mean: if one have 1MB machine and OS takes
800 kB for itself, then one has about 200 kB for user programs.
If OS takes 400 kB, then one has about 600 kB for user programs.
I this case smaller system effectively has 3 times more memory
available for user programs. On 2 MB machine (assuming the same
OS use) ratio is closer to 4/3, still giving advantage to smaller
system, but this advantage is much smaller.
Relatedly, I saw a talk recently by an English gent where he
talked about a similar phenomenon: if you're driving somewhere
and you're going 20 MPH (or KPH, if you prefer; the important
thing here is the ratio, not the unit) then incresing speed by
10 MPH to 30 is a significant different and makes a measurable
difference in your arrival time at your destination. On the
other hand, if you're doing 80, then increasing speed by 10 to
90 is almost immeasurable and just (in his words) "makes you a
dickhead."
Well, I thought it was funny.
- Dan C.
On 01/04/2026 17:15, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of
There had been an entire book, but it was only a monograph really. I can't >>> find a mention online, but I have a copy.-a-a-a-aDavid Barron's 1068 monograph?-a This is called "Assemblers and
Loaders", [...].
accuracy, the publication date was not /that/ early! Typo for "1968".
[I find that I now do so little actual typing, as opposed to dabbing,
that typos now abound in what I type, and are difficult to spot in the >typeface that my monitor uses and with the eyes that my head uses.]
Andy Walker <anw@cuboid.co.uk> writes:
Well, 1066 is a notable date in your neck of the woods...David Barron's 1068 monograph?-a[...].I don't suppose anyone was deceived, but in the interests of
accuracy, the publication date was not /that/ early! Typo for "1968".
Andy Walker <anw@cuboid.co.uk> writes:
On 01/04/2026 17:15, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of >>accuracy, the publication date was not /that/ early! Typo for "1968".
There had been an entire book, but it was only a monograph really. I can't >>>> find a mention online, but I have a copy.-a-a-a-aDavid Barron's 1068 monograph?-a This is called "Assemblers and >>> Loaders", [...].
[I find that I now do so little actual typing, as opposed to dabbing,
that typos now abound in what I type, and are difficult to spot in the >>typeface that my monitor uses and with the eyes that my head uses.]
Well, 1066 is a notable date in your neck of the woods...
Back when I was doing cross-country trips I gave this some thought, and
at one point came to the same conclusion. Is it worth it to save five minutes on a four-hour trip (or whatever, don't flame me), when other contingencies can easily cause you to gain or lose more than that making
a rest stop?
This leads to what I call my 5% rule. In many cases, a difference of
less than 5% is either insignificant or gets washed out by other
factors - so you might as well not worry about it.
On Thu, 02 Apr 2026 16:58:50 GMT, Charlie Gibbs wrote:
This leads to what I call my 5% rule. In many cases, a difference of
less than 5% is either insignificant or gets washed out by other
factors - so you might as well not worry about it.
Is Microsoft applying this principle to its QA on Windows releases
now, do you think?
On 4/4/26 14:55, John Levine wrote:
IBM also had Conversational Programming System (CPS) that supportedDid any timesharing OSes from IBM enjoy much success? Maybe TSO? Did
that do multiuser, without the need for VMs?
Obviously VM/CMS. Non-IBM MTS was fairly popular in the education community.
Single language APL\360 was also pretty popular, supporting a lot of interactive
users on a 360/50.
BASIC and PL/I. Don't know about FORTRAN.
On 05/04/2026 00:44, Lawrence DrCOOliveiro wrote:
I wonder how many people at DEC worked on TOPS-10 ... remember, they
were able to provide true multiuser support from the get-go, which CMS
could not.
No but CMS is still in use today, and it still doesn't provide true
multi user support whatever that is
On 2026-04-03 20:57, Lawrence DrCOOliveiro wrote:
On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote:
Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by
TSS/360 kernel ...
Wikipedia says TSS was not a great success.
Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did
that do multiuser, without the need for VMs?
IBM's flagship OSs were versions of OS/360, later including OS/370, MVS, >etc. The internals were apparently not suited for interactive program >execution, where each terminal was likely to be running a different
program. What they did very well at, was for a permanently running
program to handle transaction processing for a large network of
terminals, where each terminal/host/terminal handshake sent out a >prompt/data entry form, then received it back when the user hit enter,
and finally sent out the response. The nature of the polled multidrop >clusters allowed the queue of not-yet-processed transactions to sit in
each originating terminal instead of taking up host memory for the queue.
On this foundation, were built a number of functionally similar >"Conversational Remote Job Entry" systems; some (CRJE) developed and >released by IBM, some developed by university computer centers and
shared with other customers. My exposure to the kind, was the WITS
(Waterloo Interactive Terminal System) developed at University of
Waterloo in Ontario, where the WATFOR fast compile-and-go FORTRAN
teaching system also came from.
The system was essentially a large multi-user file editor, which could >submit batch jobs into a virtual card reader; either provided by HASP >(Houston Automatic Spooling and Priority Scheduler) or to an "initiator" >module in OS, which thought it saw a card reader connected to a channel
that really just had a loopback connector on the end. A similar virtual >printer and virtual card punch could bring jobs back to the editor
complex where the were copied to user files to be edited, alter to be >printed or used as input for new jobs.
This kind of subsystem was ubiquitous in OS/3[67]0 installations and
greatly improved programmer productivity compared t using physical cards
for job submission.
In comparison, the UNIVAC EXEC_8 OS had much lower per-job overhead, and >allowed
1) Small undergraduate jobs from programming classes to run as fast as
WATFOR could process similar jobs in its (mostly interpretive?)
system.
2) True interactive jobs using the same JCL as batch jobs.
At the Univac based university data center where I learned my trade, we
knew we had to compete with the IBM OS/HASP/WITS/WATFOR center across
town, where WATFOR jobs were free. Our solution was to have an express
job queue where you could run any job that was under 5 CPU seconds at
the highest priority, so that it came bac "instantly".
The third center ran a CDC 6600 with KRONOS. I am not sure if it was
CRJE or truly interactive.
No matter what it is, it would make no sense since it only runs under
VM which provides quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run
several flavors of linux, all at the same time, if that's what you
want.
According to David Wade <g4ugm@dave.invalid>:
On 05/04/2026 00:44, Lawrence DrCOOliveiro wrote:
I wonder how many people at DEC worked on TOPS-10 ... remember, they
were able to provide true multiuser support from the get-go, which CMS
could not.
No but CMS is still in use today, and it still doesn't provide true
multi user support whatever that is
No matter what it is, it would make no sense since it only runs under VM which provides
quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run several flavors of linux,
all at the same time, if that's what you want.
John Levine <johnl@taugh.com> writes:
No matter what it is, it would make no sense since it only runs under
VM which provides quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run
several flavors of linux, all at the same time, if that's what you
want.
"Future System" overlapped adding virtual memory to all 370s, FS was
totally different than 370 and was going to completely replace it,
internal politics during FS was killing off 370 projects and lack of new
370 during FS period is credited with giving clone 370 makers their
market foothold.
when "FS" finally imploded, there was mad rush to get stuff back into
370 product pipeline, including kicking off quick&dirty 3033&3081 in parallel.
1974, CERN presented comparison of VM370/CMS and MVS/TSO at SHARE ...
inside IBM the report was classified "IBM Confidential - Restricted" "on
need to know" only (not wanting internal employees see the
comparison). How much better VM370/CMS looked likely was major factor in
the head of POK (high-end 370s) convincing corporate to kill the
VM370/CMS product, shutdown the development group and transfer all the
people to POK for MVS/XA (Endicott lab eventually manages to acquire the VM370/CMS product mission, but had to recreate a development group from scratch).
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
On 05/04/2026 00:44, Lawrence DrCOOliveiro wrote:
I wonder how many people at DEC worked on TOPS-10 ... remember, they
were able to provide true multiuser support from the get-go, which CMS >>>> could not.
No but CMS is still in use today, and it still doesn't provide true
multi user support whatever that is
No matter what it is, it would make no sense since it only runs under VM which provides
quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run several flavors of linux,
all at the same time, if that's what you want.
VM6 runs in 370 mode and runs CMS. IIUC Linux needs at least s390 mode
so can not run under VM6.
On 4/5/26 18:42, Waldek Hebisch wrote:
VM6 runs in 370 mode and runs CMS. IIUC Linux needs at least s390
mode so can not run under VM6.
One of the colleges, probably Marist, had an unofficial version of
Linux running on a 370. I understand GCC wanted a PC-relative branch instruction, so they had to code around that.
Did it really take that many decades for IBM to understand the concept
of position-independent code?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Did it really take that many decades for IBM to understand the
concept of position-independent code?
TSS/360 supported position independent code .... could have same
shared segments across different virtual address spaces at different
address locations.
OS/360 languages generated executable with "relocatable" addresses
and loader, loading the executable images when loaded, the relocable addresses were updated for the ("fix") loaded address locations (aka "relocatable" until loaded for execution).
Did it really take that many decades for IBM to understand the concept
of position-independent code?
TSS/360 supported position independent code .... could have same shared >segments across different virtual address spaces at different address >locations.
On Sun, 5 Apr 2026 20:05:11 -0700, Peter Flass wrote:
On 4/5/26 18:42, Waldek Hebisch wrote:
VM6 runs in 370 mode and runs CMS. IIUC Linux needs at least s390
mode so can not run under VM6.
One of the colleges, probably Marist, had an unofficial version of
Linux running on a 370. I understand GCC wanted a PC-relative branch
instruction, so they had to code around that.
Did it really take that many decades for IBM to understand the concept
of position-independent code?
360 was all position-independent. In theory there were no absolute
addresses, everything was base-displacement. Change the base register
and Bob's your uncle. Unfortunately there were a couple of gotchas,
address constants being the worst. Also the small range of addresses available from a single base became limiting as programs got larger.
W/o location independence and requiring executable image to be otherwise preloaded to have address constants to be modified to their executing position ... would have required every executing program image to have
unique address across the whole system
certain executables to be concurrently mapped into the same address
space).
On 4/5/26 18:42, Waldek Hebisch wrote:
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
On 05/04/2026 00:44, Lawrence DrCOOliveiro wrote:
I wonder how many people at DEC worked on TOPS-10 ... remember, they >>>>> were able to provide true multiuser support from the get-go, which CMS >>>>> could not.
No but CMS is still in use today, and it still doesn't provide true
multi user support whatever that is
No matter what it is, it would make no sense since it only runs under VM which provides
quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run several flavors of linux,
all at the same time, if that's what you want.
VM6 runs in 370 mode and runs CMS. IIUC Linux needs at least s390 mode
so can not run under VM6.
One of the colleges, probably Marist, had an unofficial version of Linux running on a 370. I understand GCC wanted a PC-relative branch
instruction, so they had to code around that.
Peter Flass <Peter@iron-spring.com> wrote:
On 4/5/26 18:42, Waldek Hebisch wrote:
John Levine <johnl@taugh.com> wrote:
According to David Wade <g4ugm@dave.invalid>:
On 05/04/2026 00:44, Lawrence DrCOOliveiro wrote:
I wonder how many people at DEC worked on TOPS-10 ... remember, they >>>>>> were able to provide true multiuser support from the get-go, which CMS >>>>>> could not.
No but CMS is still in use today, and it still doesn't provide true
multi user support whatever that is
No matter what it is, it would make no sense since it only runs under VM which provides
quite a lot of multi-user support.
I would also note that any VM system that can run CMS can also run several flavors of linux,
all at the same time, if that's what you want.
VM6 runs in 370 mode and runs CMS. IIUC Linux needs at least s390 mode
so can not run under VM6.
One of the colleges, probably Marist, had an unofficial version of Linux
running on a 370. I understand GCC wanted a PC-relative branch
instruction, so they had to code around that.
AFAICS there is more to this. There was a version of GCC targeting
370, so in a sense that was handled. But IIUC GCC for 370 emited
assembler that Paul Edwards used, which was similar or maybe
identical to assembler for some version of MVS. However, for
me neither MVS assembler (that is version that I had) nor
binutils were able to handle assembler output from GCC.
Beside GCC, AFAICS there is substantial difference in s390 and
370 system instructions and data structures. So one would have
to rework low level machine specific support.
VM DCSS
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 03:54:40 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
767 files (8,591M bytes) |
| Messages: | 264,528 |