Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.

Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.

Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.

Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.

Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.

Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.

Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.

New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.

Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Best obscure mainframe OS?

  • Filter
  • Time
  • Show
Clear All
new posts

    Best obscure mainframe OS?

    I was born a decade or two too late to really experience mainframe computing. I briefly did some IBM 3090 and System 390 stuff, and Tandem if that counts.

    However, I'm more curious about the competing mainframes from the Seven Dwarves or BUNCH.

    Specifically, I'd like to understand more about:

    Burrough's MCP
    Univac's EXEC (now OS2200)
    Control Data's NOS/VRE
    NCR's VRX
    RCA Spectra's VMOS

    I found that Unisys provides desktop (Windows) emulation environments for modem versions of MCP and OS2200.

    I've also found the Desktop Cyber emulator for Control Data.

    I haven't seen anything out there on the NCR or RCA machines.

    I've also left off the GE > Honeywell > Bull GCOS operating system for no good reason. It just doesn't interest me that much.

    Does anyone have any interesting comments that contrast these different environments?

    Or, should I just recognize that these things get the market share that they deserve, and just spend more time with DEC / Unix OSs ?

    If you want to try out Multics on an emulated Honeywell system, you can start here:


      I think VMOS became Sperry OS/3 when they bought the product line. Charlie Gibbs just sent bitsavers a bunch of manuals for that.

      SDS/XDS CP-V wasn't a bad interative timesharing system

      I never liked UNIVAC EXEC-8 very much, it was a card-oriented operating system that barely tolerated terminal use.

      People that came up through the PDP-10 et. al. interactive terminal world were spoiled.


        There are/were probably more OS-es than you could shake a stick at
        Just for CDC upper-level mainframes:

        STAR-OS/ RED

        I've probably forgotten a few.

        Reach me: vcfblackhole _at_ protonmail dot com.


          Well, I went from using PETs in High School to working with NOS on the school Cyber 730 in college.

          Talk about a different computing experience.

          There was a bunch of arcane stuff in NOS that just never seemed to apply to me, and NOS itself was never "explained". We were basically told how to use the individual programs (editor, compilers), but as far as architecture, there was no mention of that. The teachers didn't know the system, so they couldn't explain it to you.

          There was some concept of "direct storage" and you would "attach" things to you session. Dunno if that was a sharing thing, or what that was.

          There were proc files (essentially batch/script files), and entire libraries you could "attach" to make available to your session. There was a utility core maintained by students that we all shared.

          Much to the chagrin of one student who was targeted. There literally was "If BOB then" code in these files.

          There was the DAYFILE, which logged all of your commands. (The shared proc file kindly shipped Bobs dayfiles to the admins everyday.)

          One group wrote a COMPASS (the 60 bit assembler for the Cyber) simulator, and used it to run all sorts of system programs that were ostensibly "privileged". Found numerous security holes that way.

          It was an interesting system, I'm so grateful that this was my second major computing experience. Later, the school adopted PCs. I felt those students missed out a lot not working on a multi-user shared system. There's a lot of keen fundamental concepts you get working in the kind of environment that you'd never get on a standalone PC.

          In the end, I prefered the RSTS/E PDP, it was just a bit friendlier.

          I do wish I was able to better understand at the time what I was working with though.


            It helps to know the genesis of some of the CDC stuff. I'll try to be brief without being obscure (Brevis esse laboro, obscurus fio)

            COS (Chippewa Operating System) was the first 6000 series OS. As the name suggests, it was the product of Seymour Cray's Chippewa Falls, WI (therein lies a bunch of stories) lab.
            Next came SCOPE (never did figure out what it stood for), a more full-featured standard product.
            At about the same time, a chum by the name of Greg Mansfield, along with Dr. Dave Callender (the "bat" guy) created a simple operating system suitable for customer engineers; it was compact and much simpler than SCOPE. It was dubbed MACE (Mansfield's Answer for Customer Engineers).
            Because of its simplicity, it was repackaged and made to be more-or-less SCOPE-compatible from a user standpoint and found to be suitable for time-sharing applications. It was thus dubbed KRONOS.
            There arose a bit of a east-west rivalry--the West Coast people maintained and developed successive SCOPE versions, while the Twin Cities folks worked on KRONOS. Because PLATO was a time-shared application, naturally, it was hosted on KRONOS.
            However, KRONOS really sucked at big resource-intensive jobs, while SCOPE excelled at them.
            So KRONOS was relabeled NOS (Network Operating System) and SCOPE relabeled NOS/BE (Batch environment).
            Eventually the two were merged and simply called NOS.
            TCM (Time Critical Monitor) was a Special Systems bootleg project whose goal was response to an event taking no longer than 100 microseconds. To do this, a lot of code was moved from the peripheral processors to the central processor. It was long forgotten about until:
            ZODIAC (probably so-called because the Zodiac killer dominated the news at the time) was done to satisfy a contract from the USAF Logistics Command (and peripherally, UBS--the Union Bank of Switzerland). It was built on the TCM base, but instead of user programs being serviced by PPUs, user jobs were designated as "modules" all under the umbrella of a lead module constituting something called a "chain". Such chains could reside in any machine of a multi-machine configuration, communicating through shared bulk core (ECS). The residency of a chain in any machine could be measured in milliseconds. The goal was near-instant response for a transaction-oriented system. UBS re-christened ZODIAC as TOOS, but it was the same basic system under the covers.
            ROVER was strictly concrete-block copper shielded walls cold war spook stuff. Probably still highly classified. People working on it had top secret clearances with appropriate endorsements and were told never to disclose to outsiders what was going on under penalty. So I won't discuss it here.

            For the STAR super computer (also known as CYBER 200/201/203/205) and eventually the ETA-10 liquid nitrogen-cooled super, there was RED--a simple operating system developed within CDC and STAR-OS--mostly developed in cooperation with the folks at Lawrence Livermore. Very complex message-passing style OS, mostly written in a dialect of LRLTRAN.

            One complication is that if you were a CDC customer, you could request the source to the operating system and utilities free of charge. So there were many local variations of the above.
            Reach me: vcfblackhole _at_ protonmail dot com.


              Chuck, if you were a computer, you'd have an exabyte of storage and processor clock that never misses!

              I suppose in today's world, unless you're actually working with large scale systems, it's hard to appreciate the batch nature of the older systems and how you computed with them.

              It seems like now, everything is about the web/web application frameworks, SAP, mobile, or some other small/near instant Python program. Back then, there was "A" computer, versus now you lose track of how much computing you actually have access to (RPi and clouds!)


                For me, the disquieting thing is that there has been a huge amount of information lost, probably forever. I've just covered what I recall from the CDC 6000 and STAR architectures. I know almost nothing about the 3000 series software or the stuff that ran on the 1604, much less any "government" projects. Like a lot of aerospace work done, when the project is over, the funding stops and the work pretty much heads to the shredder and landfill. I recall retrieving firmware source for some Lockheed missile project that had long been ended--someone saved a bunch of 8" floppies from a FutureData development system. Sadly the collection was incomplete. This situation was not unusual.

                Isn't it true that we're only as good as what we can remember and learn from?
                Reach me: vcfblackhole _at_ protonmail dot com.


                  If we don't remember ... it never happened ...


                    Originally posted by Chuck(G) View Post
                    Isn't it true that we're only as good as what we can remember and learn from?
                    I think most people working in the field have no interest in researching the past, just like companies have no interest in hiring anyone unless they
                    are fluent in the latest shiny.

                    The days of MIT-style learning from first principles are very, very dead.


                      Originally posted by View Post
                      If we don't remember ... it never happened ...
                      "If we destroy the evidence, they can't prove it ever happened"


                        Originally posted by Chuck(G) View Post
                        It helps to know the genesis of some of the CDC stuff. I'll try to be brief without being obscure (Brevis esse laboro, obscurus fio)


                        At about the same time, a chum by the name of Greg Mansfield, along with Dr. Dave Callender (the "bat" guy) created a simple operating system suitable for customer engineers; it was compact and much simpler than SCOPE. It was dubbed MACE (Mansfield's Answer for Customer Engineers).

                        I think the 6600/6500 in the Purdue C.S. department ran MACE (kind of remember it being M.A.C.E. in the brief documentation I saw). I used it to teach a summer class (Super Saturday) for high school students, but we didn't do much with the actual OS as all our time was spent in the interactive BASIC environment. This was all for a brief few weeks 37 years ago, so I could be making this up. Amazing that you remember so much history of these machines.


                          My recollection was that it was Purdue's own variation of MACE; for their 6500 heavy on the CP monitor functions. You need only have looked at the SYSLIB source code to see Greg and Dave's names in every deck. I think it also had a provision for communicating with the 7094s that ran PUFFT as well. Very CEJ-oriented; the "save registers" routine was done via an XJ, rather than the litany of generating a table using RJ for the last B-register. Memory is dim on that one.

                          Egad, I'm showing my age, aren't I.
                          Reach me: vcfblackhole _at_ protonmail dot com.


                            One of the truths of the old machines is that abstraction is expensive, so the realities of the architecture don't just "leak" (as we like to say) through the abstractions, but just tear large holes in them and march through.

                            So, theses ideas and these concepts (liked ATTACHed files, or whatever) were there for a reason, and I never quite understood the genesis behind these kinds of things.

                            For the simple school projects that we did, obviously, none of this stuff ever really impacted us directly. Everything we did, we just did by rote without understanding it.


                              Originally posted by whartung View Post
                              So, theses ideas and these concepts (liked ATTACHed files, or whatever) were there for a reason, and I never quite understood the genesis behind these kinds of things.
                              Okay, I'll explain it. On all 6000 operating systems, a job starts with only a single file, called INPUT. For obvious reasons, this consists of your input card deck or terminal keyboard data. There are no other files accessible from your job. If you wanted printed output, you wrote to a file called OUTPUT, which was disposed of in batch jobs at the job conclusion (or with a DISPOSE directive during the job). Similarly, a file called PUNCH would be sent to the card punch. All these are "local" files and cease to exist after the job or session terminates. There was a system library, specially maintained for system programs, such as compilers and libraries, but not readable or writable by normal I/O commands. A very secure system and one where what you did was pretty much invisible to other jobs running at the same time.

                              For "permanent" data, the system maintained a separate file system, which was owner-qualified, password-protected and even included versioning (called "cycles). You could gain access to one of these files if you knew its name (IIRC up to 30 characters), its owner's name, as well as the passwords for the access you desired. You "attached" the file to a locally-named file of your choosing. That is, a permanent file named "MYLASTWORKTHATIDID" could be "attached" to a local file named "WORK", which then could be accessed via normal I/O. You could explicitly DETACH the file, which broke the association or just let the system do it at job/session conclusion.

                              Unlike other systems, you weren't even aware of the existence of a permanent file unless you knew its name and the name of its owner. You couldn't access the file unless you knew the appropriate passwords.

                              Quite secure for the time--and I'm omitting a fair amount of detail.
                              Reach me: vcfblackhole _at_ protonmail dot com.