Image Map Image Map
Page 6 of 7 FirstFirst ... 234567 LastLast
Results 51 to 60 of 62

Thread: Modern Mainframes

  1. #51
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    From the pages of history:

    "....Though the CDC-6500 was off-the-shelf hardware (aside from a custom interface to our network),
    the software we used was largely home-grown. The operating system was called SCOPE/Hustler.
    It was based on Control Data's batch-oriented SCOPE 3.2 (System Control Of Program Execution) OS.

    MSU's primary innovation was to add interactive service in a way that was well-integrated into
    the vendor's batch OS. "Hustler" was taken from the Paul Newman movie of the same name,
    which was popular when MSU was beginning its design of this homebrew OS. Evidently
    the programmers found OS data structure terminology--with queues (sounds like "cues"--get it?),
    tables, and pools--too tempting to resist the cute name. They even invented a "pocket" data structure.
    But the operating system lacked "balls"..... "

    Source is here

    ziloo



    Last edited by ziloo; January 7th, 2018 at 10:47 PM.

  2. #52
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    26,746
    Blog Entries
    20

    Default

    You might also investigate Purdue's use of the 6500. I think Saul Rosen wrote a couple of papers on it. IIRC, it was coupled to a pair of 7094s for I/O (at the time, 7094s were being phased out for the S/360 machines and were comparatively inexpensive). Purdue's 6500 OS was based on Dave Calender and Greg Mansfield's MACE. Dave's passion was bats and was one of Harold Edgerton's students and suggested using Edgerton's new strobe to study them. Greg was a friend (I introduced him to gelato) who wound up at Cray eventually. (MACE stands for "Mansfield's Answer for Customer Engineers"). MACE started out as a "bootleg" lightweight system used by CEs and was, at a program level, largely compatible with SCOPE (which itself was a takeoff on COS, the Chippewa Operating System). Greg did much of his work at night, using machines on the QA floor at Arden Hills.

    MACE morphed into KRONOS and was used for timesharing tasks such as the PLATO learning system. SCOPE was used for batch jobs. Sometime around 1973 or so, both were re-christened--SCOPE became NOS/BE and KRONOS became NOS--eventually, the internal differences were reconciled and a single product line, NOS, was offered.

    Perhaps the fundamental difference between SCOPE and KRONOS was the deployment of resources. SCOPE used a PP-centric approach and a filesystem oriented toward high performance. KRONOS put some of the OS into the CPU and used a simplified file system designed for quick response. For example, SCOPE sorted and prioritized disk requests to get the highest performance; KRONOS serviced them on a strict first-in-first-out basis. Almost all system calls to SCOPE resulting in loading a PP program to handle the request; KRONOS handled the simpler, non-I/O requests in the CPU. Both approaches made sense--SCOPE was great for heavy compute and big I/O workloads; KRONOS was great for light multi-user real-time tasks.

    There were other (often classified) operating systems as well used for government work.

  3. #53
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    Chuck......during your involvement with the big ones, was there any
    serious talk about "Artificial Intelligence" and some "deep stuff"
    like "Heuristic Algorithm"?


    ziloo
    Last edited by ziloo; January 8th, 2018 at 09:58 AM.

  4. #54
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    26,746
    Blog Entries
    20

    Default

    Nope--I was primarily a low-level systems guy. I didn't do any of the theoretical stuff.

  5. #55
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    Low-level???........I don't think so........


    ziloo




  6. #56
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    Ziloo--here's a shot of CDC "big iron"--a vector supercomputer....

    The CPU is the line of of units in the background. The boxes on the right with the CRTs are SBUs (station buffer units), which essentially handle I/O. Basically 16 bit minis with a resident drum and a bunch of core and device/channel interfaces. On the left, you can just see a 405 card reader and the rear of the operator's console. What's not visible are the tape drives and disk drives.


    It is a good place to ask.......why so many termials ?...


    ziloo
    Last edited by ziloo; January 9th, 2018 at 03:04 AM.

  7. #57

    Default

    Quote Originally Posted by ziloo View Post
    ECL....emitter-coupled logic as compared to TTL......

    I see that differential signalling is presently used in RS-485, USB, and Serial ATA;
    but as far as ECL in mainframes were concerned, was it used in I/O only,
    or it was used within the system as well?

    ziloo
    The DEC PDP-10 KL10 used 10k ECL for the whole CPU.
    Member of the Rhode Island Computer Museum
    http://www.ricomputermuseum.org

  8. #58
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    26,746
    Blog Entries
    20

    Default

    Quote Originally Posted by ziloo View Post
    It is a good place to ask.......why so many termials ?...
    I thought I answered that. They're the interfaces to the SBUs--which are I/O processors for the machine in the background and fairly complete computers in their own right.. Normally, an operator only pays attention to the display terminal for the MCU, which is a special type of station with its own local drum storage. But given the cost of these things, the terminal interface was a minor blip and a convenience for the CEs. One could, for instance, stop and reload a station with different firmware without halting the main CPU.

    This sort of thing was not atypical on supercomputers. A Cray I, for example made use of another (not Cray) mainframe to perform I/O. The purpose of this big iron was to compute and not get involved in dedicating expensive cycles to managing mechanical I/O devices. It would make a lousy machine to play games on, unless the game were something like chess.

    I recall that one of Neil's designs dedicated a hard-wired 16Kw (8 bytes per word) to the operating system. When I asked about this, his response was "If you can't fit an operating system in 16K, you don't belong in this business.". The design was never implemented, but it was fun to talk about it.

  9. #59
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    Quote Originally Posted by m_thompson View Post
    The DEC PDP-10 KL10 used 10k ECL for the whole CPU.
    Thank you m_thompson....

    I read that PDP-11 originally used asynchronous Unibus.
    What kind of bus is that?


    ziloo

  10. #60
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    860

    Default

    Quote Originally Posted by Chuck(G) View Post
    .....They're the interfaces to the SBUs--which are I/O processors for
    the machine in the background and fairly complete computers in their own right......
    In reading about the PDP-10 computer.... I found out that for the proper operation of
    the main computer, they used Frontend Computer Systems that extended the functionality
    of the systems to which they were connected.

    The frontend computer would be first booted from a disk drive, or Tape drive,
    and then commands can be given to the frontend computer to start the main
    processor. In some systems they actually used an 8080 CPU to load a microcode
    from a disk or magnetic tape, and then start the main processor. The 8080 then
    switches modes after the operating system boots and controls the console
    and remote diagnostic serial ports.

    Any additional discussion would be appreciated...

    ziloo
    Last edited by ziloo; January 15th, 2018 at 07:15 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •