• Re: CMS, Self-hosting and the 6502

    From John Levine@3:633/10 to All on Sun Apr 5 19:22:53 2026
    According to David Wade <g4ugm@dave.invalid>:
    On 05/04/2026 00:44, Lawrence D?Oliveiro 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.






    --
    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

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lynn Wheeler@3:633/10 to All on Sun Apr 5 14:30:15 2026
    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).

    part of reason that other RDBMS shipping before System/R was opposition
    from "IMS" (& then EAGLE)

    I transfer out to SJR on the west coast and work with Jim Gray and Vera
    Watson on the original SQL/relational, System/R (all work having been
    done on VM370/CMS). Sign a System/R joint study with BofA and they order
    60 VM/4341s for distributed operation (sort of leading edge of coming distributed computing tsunami). Branch office hears about engineering
    4341 and Jan1979 cons me into doing benchmark for national lab that was
    looking at ordering 70 VM/4341s for compute farm (sort of leading edge
    of coming cluster super computing tsunami).

    VM/4341 starts shipping to customers summer 1979 and begin seeing large corporations ordering hundreds of VM/4341s at a time for placing out in departmental areas (inside IBM, departmental conference rooms were
    becoming scarce since so many were being converted into departmental
    VM/4341 computing rooms).

    Was also able to do System/R tech transfer to Endicott for SQL/DS
    ("under the radar" with the corporation pre-occupied with the next great
    DBMS, "EAGLE" ... System/R having met lots of opposition by both the
    "IMS" & "EAGLE" DBMS forces). When "EAGLE" implodes, get request from
    STL for how fast could "System/R" be ported to MVS ... eventually
    released as "DB2" originally for "decision support" only.

    trivia: old archived post with decade of VAX/VMS numbers ... VM/4341s
    sold in approx. same numbers in single or small unit numbers ... big
    difference were the large orders for hundreds of VM/4341 at a time. https://www.garlic.com/~lynn/2002f.html#0

    --
    virtualization experience starting Jan1968, online at home since Mar1970

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Peter Flass@3:633/10 to All on Sun Apr 5 20:02:23 2026
    On 4/5/26 17:30, Lynn Wheeler wrote:
    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).


    We lived thru this. Maintenance was so botched for a couple of releases.
    It's a good thing nobody there could hear us.


    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Peter Flass@3:633/10 to All on Sun Apr 5 20:05:11 2026
    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 D?Oliveiro 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.

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Mon Apr 6 07:03:07 2026
    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?

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lynn Wheeler@3:633/10 to All on Sun Apr 5 22:19:00 2026
    Lawrence D?Oliveiro <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).

    after joining IBM CSC ... with competition from TSS/360 and MULTICS up
    on the 5th flr ... I did a page-mapped filesystem for CP67's CMS
    (nominal filesystem workload about 3times faster (and degrading much
    more gracefully as load increased) and since CMS used OS/360 language processors ... it had fixed addresses as part of loading. I had to do a
    lot of code fiddling in order to emulate TSS/360 being able to load
    shared segments at independent locations.

    With TSS/360 decommitted and all the 360 systems (MVT, MFT, DOS) having
    to support 370 virtual memory .... the wide-spread implementation of the "relocatable addresses" updating to correspond to the loaded address
    ... sort of negated any position-independent orientation.

    --
    virtualization experience starting Jan1968, online at home since Mar1970

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Mon Apr 6 08:20:33 2026
    On Sun, 05 Apr 2026 22:19:00 -1000, Lynn Wheeler wrote:

    Lawrence D?Oliveiro <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).

    So the code itself was not position-independent? Instead, extra
    information had to be provided in the object format to fix things up
    based on where in memory it was loaded?

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Dan Cross@3:633/10 to All on Mon Apr 6 12:03:54 2026
    In article <87pl4c1oy3.fsf@localhost>, Lynn Wheeler <lynn@garlic.com> wrote: >Lawrence D?Oliveiro <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.

    Lynn, sadly, you are arguing with an idiot. Lawrence is not
    interested in how things actually work.

    - Dan C.



    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Peter Flass@3:633/10 to All on Mon Apr 6 07:30:51 2026
    On 4/6/26 00:03, Lawrence D?Oliveiro wrote:
    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.

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lynn Wheeler@3:633/10 to All on Mon Apr 6 07:39:18 2026

    Peter Flass <Peter@Iron-Spring.com> writes:
    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.

    OS/360, etc ... large programs required addresses ... on disk the
    addresses were relative to position within the program ... but loaders
    were required to modify the addresses to fixed real addresses in real
    storage.

    tss/360 and support for multiple virtual memory address spaces and
    shared segments wanted the image in memory be exactly the same as the
    image on disk ... w/o requiring all addresses to be modified as the
    whole program was swapped into real memory ... but allowing for demand
    paged in w/o requiring for executable images to be preloaded (and
    addresses modified for their loaded position). Also not requiring for
    shared segments to have the same addresses in different virtual
    addresses spaces.

    OS/360 MVT in transition to VS2/MVS kept the OS/360 preloading/swapping
    in executable image and changing location addresses (making the affected
    pages of the executing image changed). TSS/360 just mapped portions of
    the virtual address space to the executable image on disk ... and in
    case of shared segments could just change segment table pointer to that
    of same shared segment concurrently in use by multiple other virtual
    address spaces.

    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 (or have restricted only have
    certain executables to be concurrently mapped into the same address
    space).

    That is what got me providing page-mapped filesystem for CMS ... and CMS
    was using OS/360 compilers and assemblers which assumed address
    constants had to be modified as executables were loaded (had to fiddle
    the programs so the executables images on disk were identical to
    the same as executable images mapped to virtual address spaces).

    --
    virtualization experience starting Jan1968, online at home since Mar1970

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Peter Flass@3:633/10 to All on Mon Apr 6 12:05:24 2026
    On 4/6/26 10:39, Lynn Wheeler wrote:

    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

    windows

    (or have restricted only have
    certain executables to be concurrently mapped into the same address
    space).

    VM DCSS


    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Wade@3:633/10 to All on Mon Apr 6 21:25:15 2026
    On 06/04/2026 20:21, Waldek Hebisch wrote:
    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 D?Oliveiro 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.

    I think this is probably referring to the BIGFOOT port which I think
    initially ran on what was called S370/XA but this is a 31-bit hardware
    so close the ESA

    Dave

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lynn Wheeler@3:633/10 to All on Mon Apr 6 17:41:54 2026
    Peter Flass <Peter@Iron-Spring.com> writes:
    VM DCSS

    A lot of the page-mapped filesystem and advanced shared-segments, I
    updated from CP67 to VM370R2 for my internal CSC/VM ... and very small
    subset was added to VM370R3 as DCSS.

    VM370 had been restricted to "IPL by-name" where images were saved in
    locations defined and disk location specified in DMKSNT. For DCSS a
    special API interfacing to entires in DMKSNT using several of the things
    I had extended for page-mapped filesystem shared-segments (some that I
    had twiddled for location independent ... but wasn't supported by the
    small subset used for DCSS).

    --
    virtualization experience starting Jan1968, online at home since Mar1970

    --- PyGate Linux v1.5.13
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)