Subject:
Fwd: History question: zSeries simulation of S/360 and IBM 1401 ?
From:
Robert Garner (Add as Preferred Sender)
Date: Tue, Jul 02, 2019 3:43 pm
To: Ken Shirriff
Cc: Robert Garner , Carl Claunch ,
Marc Verdiell , Dag Spicer ,
Ed Thelen , Bill Worthington ,
Luca Severini , Jay Jaeger ,
Stan Paddock , Van Snyder ,
Ron Mak , Dick Weaver
Ken,
Yesterday you asked about when IBM discontinued 1401 emulation support.
Below is the informative email I received from Alan Altmark in 2015.
According to Alan, 1401 emulation was last supported on the CMOS-based S/390 Gen 3 (9672-Rx4),
emulating S/370-XA and ESA/370, which supported 1401/1440/1460 emulation.
The model 9672-Rx4 was introduced in 1996:
https://en.wikipedia.org/wiki/IBM_System/390#9672
… so one is likely still running “out there” somewhere. :-)
There’s a “dirty/corroded” one on eBay for $1500:
https://www.ebay.com/itm/IBM-9672-Mainframe-computer/352705813663?hash=item521ee79c9f:g:CawAAOSwoR9dAYtR
1401 emulation was also available on the S/370 models 4331 and 4341 back in 1982…
We could email Alan Altmark for clarification(s).
(I recall an amiable/fun phone conversation.. :)
- Robert
p.s. Cc’d Dan Greiner is the IBMer at Santa Teresa Lab that shepards the zSeries/390/370/360 ISA!...
> Begin forwarded message:
>
> From: Alan Altmark
> Subject: Re: Fw: History question: zSeries simulation of S/360 and IBM 1401 ?
> Date: May 17, 2015 at 8:07:47 PM PDT
> To: Robert B Garner
> Cc: Thomas Mathias , Ronald Milczewski ,
brooks@cs.unc.edu, John Niski , Thomas Litty ,
Jeffrey Ader , Richard Bibolet ,
Jerry Kaminsky , Jennifer A Hunt ,
peter.capek@gmail.com, Robert Garner (robgarn@mac.com),
Dan Greiner , John Paveza
>
> Robert, first, let me answer your question to me:
The IBM System/390 Parallel Enterprise Server - Generation 3 (9672-Rx4)
was the last mainframe to carry S/370-XA and ESA/370 architecture capability.
It was introduced in 1996 and withdrawn from marketing in 1999. Most were out of service by
2006, but the 9672-RA4 remained in service until 2010. And except for some clever support
we have in z/VM for 370-based CMS application, that marked the end 370-enabled hardware.
>
> In doing some additional research of the announcement letter archive
(https://w3-03.sso.ibm.com/sales/support/Search.wss?pg=anno), I found that the
1400/1440/1460 emulator (5746-SU1) for DOS was still available on the 4331 and 4341 series
of processors, but it was withdrawn from service and discontinued September 1, 1982.
I couldn't find any reference to support on the 4361 and 4381, so that provides a better
time reference for loss of the emulation capability, as it was a hardware feature.
I haven't looked for the 4300-series sales manual to see the feature codes themselves.
>
> The 1401/1440/1460 Emulator Program continues support for the 14XX series programs
on the IBM 4300 processor.
>
> Users of the IBM 4331 Processors may run this program also in conjunction with the
1401/1440/1460 hardware Compatibility feature provided by the 4331 processor.
>
> Programs written to run on IBM 1401, 1440 or 1460 Systems may be executed on the 4331
using the IBM Systems 1401/1440/1460 Emulator program product and can achieve improved
performance with a special feature on the processor.
>
> I also found references to
> 5744-AG1 1410/7010 Emulator For System/370 Under OS/VS
> 5744-AH1 1401/1440/1460 Emulator For System/370 Under OS/VS
> 5746-SU1 14XX Emulator for System/370 Under DOS/VS
> 5744-AJ1 707X for Models 155 II and 158
> 5744-AK1 707X for Models 165 II and 168
> 5744-AL1 7080 for Models 165 II and 168
> 5744-AM1 709X for Models 165 II and 168
>
> Publications: Available through EPC, Copenhagen:
> GC33-6070 Licensed Program Design Objectives
> GC33-6071 Licensed Program Specifications
> SC33-6072 Installation Guide and Reference
> LY33-9082 Program Logic Manual 8
>
> Some feature codes (in parens)
> 158 1401 / 1440 / 1460, 1410 / 7010 Compatibility (3950)
> 7070 / 7074 Compatibility (7117)
>
> 168 7070 / 7074 Compatibility (7127)
> 7080 Compatibility (7128)
> 709 / 7090 / 7094 / 7094-II Compatibility (7129)
>
> The emulators were apparently packaged with the OS-specific simulators.
(Interesting to note how specific we were about 'emulation' vs. 'simulation' back then.)
>
> Researching the archives is always fun, and each announcement references another
announcement letter that helps fill in some blanks and create new one. It looks
like you can spend a lot of time figuring out this history of emulation, particularly
if you find the old OS/VS and DOS/VS manuals that talk about running the emulator.
>
> For some fun I include the following as it includes the prices (USD):
> IBM Announcement Letter Number P79-39 dated January 30, 1979
> IBM US - Last Revised on January 30, 1979
> Internal Letter Section
>
> The IBM Systems 1401/1440/1460 Emulator program product
> provides support of 1400 Series programs on the 4300 Processors.
> This emulator executes with the 1400 Compatability Feature
> available on the 4331 Processor. Alternatively the emulator will
> execute on the 4341 Processor in simulator mode with the 1400
> simulator generated as part of the 1400 Emulator. Simulation of
> disk I/O on fixed block architecture devices is provided.
>
> Highlights
> Emulation is provided for 1401, 1440, and 1460 systems with core
> storage from 1,400 to 16,000 storage positions.
> . All basic features of these systems are emulated, together with
> the following optional features: expanded print edit
> ...inverted print edit ... high-low-equal compare ...
> multiply/divide ... processing overlap ... sense switches ...
> advanced programming/indexing ... bit test ... print storage
> ... additional print control ... space supression ... column
> binary ... binary transfer ... 51-column card ... punch-feed
> read ... card image (on 1442) ... selective stacker ... scan
> disk.
> . Features and operations not emulated are: selective tape
> listing (on 1403) ... compressed tapes ... mixed density tapes
> ... read compare feature (on 1404).
>
> Planned availability: June 1979
> Monthly charge: $100
> Testing period: One month.
>
> Program services:
> Central service: Including the IBM support center, will be
> available until discontinued by IBM upon twelve months'
> written notice.
> Local service: Will be available at no additional charge until
> December 31, 1979.
> Local licensed program support: Will be available after December
> 31, 1979 until discontinued by IBM upon twelve months'
> written notice. Program support will be provided under the
> terms and conditions of the Agreement for Local Licensed
> Program Support for IBM Licensed Programs at the monthly
> licensed program support charge, monthly additional licensed
> program support charge, or will be provided at the
> applicable hourly rate. Local licensed program support will
> be provided by IBM Field Engineering.
>
> Monthly licensed program support charge: $ 5
> Monthly additional licensed program
> support charge: $ 3
> Warranted: Yes
> Installation license applies: No. A separate license is
> required for each designated machine on which the licensed
> program materials will be used except as otherwise provided by
> IBM.
> RPQs accepted: No
> W. O. Grabe
> Division Director, Systems Management
>
> Summary of program highlights
> The IBM Systems 1401/1440/1460 Emulator program product --
> hereafter referred to as the 1400 Emulator -- allows the execution
> of 1400 programs on 4331 Processor equipped with the 1400
> Compatibility Feature or on 4331 and 4341 processors with the 1400
> Simulator generated as part of the 1400 Emulator. Simulation of
> disk I/O on Fixed Block Architecture devices is provided. The 1400
> Emulator is designed to execute as a problem program under control
> of DOS Release 26, or DOS/VS Release 34, or DOS/VSE with
> VSE/Advanced Functions. As a problem program it is possible to
> integrate the 1400 Emulator into a DOS, DOS/VS, or DOS/VSE system
> and to take advantage of the capabilities of such a system.
> The following input and output devices are emulated (full
> details of input and output device correspondence are in the
> 1401/1440/1460 DOS/VS Emulator on S/370 manual and the IBM System
> 1401/1440/1460 Emulator Program Installation Guide and Reference
> manual): 1402 Card Read Punch ... 1442 Card Read Punch ... 1442
> Card Reader ... 1444 Card Punch ... 1407 Console Inquiry Station
> ... 1447 Console ... 1403 Printer ... 1404 Printer (continuous
> forms only) ... 1443 Printer ... 729 Magnetic Tape Units ... 7330
> Magnetic tape Units ... 7335 Magnetic Tape Units ... 1301 Disk
> Storage ... 1311 Disk Storage ... 1405 Disk Storage.
> Input and output devices not emulated are: 1445 Printer ...
> 7340 Hypertape Drive ... 1011 Paper Tape Reader ... 1012 Paper Tape
> Punch ... optical readers ... magnetic character readers ...
> communication devices ... audio response units.
> Two tape formatting programs are provided with the emulator
> program: (1) to assist the user in converting tape files before
> emulation so that they can be used more efficiently by the emulator
> program, and (2) to convert tape files produced during emulation
> back to the 1401/1440/1460 format so that they can then be used on
> the original system.
> Several 1400 Emulators can run concurrently; the maximum
> number depends on the number of partitions available.
> Compatibility: Most 1400 application programs will run
> under the emulator without the need of modification. For specific
> restrictions refer to the IBM System 1401/1440/1460 Emulator
> Program Installation Guide and Reference manual. Emulator control
> statements and JCL must be added.
> Security, auditability and control: This program is
> supported by DOS/VSE and the security, auditability and control
> regimens it provides. User management is responsible for the
> selection, application, adequacy, and implementation of these
> features and for appropriate application and administrative
> controls.
> Specified operating environment
> Hardware configuration: The 1400 Emulator operates on any
> 4300 Processor. The IBM 1401/1440/1460 Compatibility Feature for
> the 4331 Processor is required unless the simulator option (for the
> 4341 Processor) of the 1400 Emulator (SIMUL=Yes) is used (see
> "Software Configuration", below).
> The processor storage requirement under DOS Release 26
> ranges from 24K to 44K bytes, depending on the configuration of the
> 1400 series machine to be emulated.
> If the 1400 Emulator is executed in a virtual mode under
> DOS/VS or DOS/VSE, the storage requirement is within the range of
> the minimum partition size.
> If seven-track tape files are to be processed, the data
> conversion feature is required.
> Software configuration: The 1400 Emulator is designed to
> execute under the control of DOS Release 26*, DOS/VS Release 34*,
> or DOS/VSE with VSE/Advanced Functions.
> * This does not imply any extension of programming service for
> these releases of SCP.
> Sales compensation plan: See DPD Marketing Announcement 279-
> 24 for details.
> Program currency: As already announced, programming
> services for 1401/1440/1460 and 1410/7010 DOS/VS Independent
> Release Emulators for System/370 will be withdrawn on June 14, 1979
> (see P78-105).
> Marketing support: See Marketing Support Bulletin Volume VI,
> Number 2.
> Publications: See Marketing Support Bulletin Volume VI,
> Number 2.
> Ordering information: To be provided at a later date.
>
>
> Regards,
> Alan
>
> Senior Managing z/VM and Linux Consultant
> Lab Services System z Delivery Practice
> IBM Systems & Technology Group
> Phone: +1-607-429-3323
> Mobile: +1-607-321-7556
> e-mail: Alan_Altmark@us.ibm.com
>
>
>
>
> From: Robert B Garner/Almaden/IBM
> To: Alan Altmark/Endicott/IBM@IBMUS, Thomas Mathias/Endicott/IBM@IBMUS
> Cc: Ronald Milczewski/Poughkeepsie/IBM@IBMUS, brooks@cs.unc.edu,
John Niski/Poughkeepsie/IBM@IBMUS, Thomas Litty/Poughkeepsie/IBM@IBMUS,
Jeffrey Ader/Poughkeepsie/IBM@IBMUS, Richard Bibolet/Poughkeepsie/IBM@IBMUS,
Jerry Kaminsky/Fishkill/IBM@IBMUS, Jennifer A Hunt/Endicott/IBM@IBMUS, peter.capek@gmail.com,
Robert B Garner/Almaden/IBM@IBMUS, Robert Garner (robgarn@mac.com) ,
Dan Greiner/San Francisco/IBM@IBMUS, John Paveza/San Jose/IBM@IBMUS
> Date: 05/15/2015 09:43 PM
> Subject: Re: Fw: History question: zSeries simulation of S/360 and IBM 1401 ?
>
>
> Alan,
>
> > LOL. I claim "No."
> I'm delighted to hear that my 1401 emulation/simulation question evoked a smile!
>
> Thanks for the AFIPS System/370 integrated emulation under OS and DOS paper reference
> and the pointer to the 370 doc on bitsavers!*
>
> > The last possible machine to have accidentally carried them would
> > have been our last 370 machine, ...
> Which was model xx ??
>
> > ... but I would wager that the microcoded instructions didn't survive
> > the architecture change to 370-XA.
> Which happened when ?
>
> Would it be OK if we posted your reply on our 1401 restoration web site,
> (likely in the same section where one of our vintage software
> programmers recollected 1400 emulation on the 360 line:
> http://www.ibm-1401.info/1401in360.html#360-1401MicroCode
>
> ==> Tom,
>
> Thanks for forwarding my inquiry!
>
> > One of the programmers around here with the longest tenure and who
> > joined IBM in the early 1970's has a very old top-10 list of
> > programmer excuses. One of the programmer excuses is "It worked
> > that way on the 1401").
>
> Could I possibly get a scan or copy of that top-10 list?
> Who is the programmer, if I dare ask? ;-)
>
> Thanks everone for the fun snark hunt, ;-)
>
> - Robert
>
> p.s. Fred Brooks recounted that the happiest day in his (professional) life
> was when his quickly conviened 1964 ace task force demonstrated that the 360/30,
> after some unanticipated modifications, would be capable of emulating a 1401 faster than a 1401.
> (I could forward his story if anyone is interested, and Fred agrees to release it. ;-))
>
> A couple of years ago I arranged for an IBM 1440 to be donated to Binghamton's
> TechWorks / Center for Technology and Innovation: http://www.ctandi.org/
> where a small team of retired IBMers have restored it. Recently senior students
> from the Watson School of Engineering and Triple Cities Makerspace built and demonstrated
> an interface between a PC and their thunderous 1403-N1 printer.
>
> Tomorrow, Saturday, May 16th, 2 PM they are hosting a Tech Talk on the IBM 1401-360 series
> by Emerson Pugh, veteran IBMer and author of Building IBM- Shaping an Industry and its Technology,
>
> I visited Endicott's IBM History and Heritage Center last fall, my photos here:
> http://ed-thelen.org/comp-hist/IBM-EndicottMuseum.html
>
> p.p.s. Full disclosure: I spend most of career at firms throwing arrows at IBM.
> I was the lead architect of SPARC at Sun and managed several microprocessor dev programs.
> At Xerox PARC and SDD, I co-designed the STAR workstation and the first commercial Ethernet
> in late 70s/early 80s. By volunteering to lead the IBM 1401 restoration project, I learned
> much of IBM's early history (1940s - 1960s) first hand from the delightful retired IBMers,
> but little from 1970s onward.
>
> * From the AFIPS paper and 370 model 135 manual, it looks like there were several
> 370 compatibility docs describing 1400 emulation in more detail:
> Emulating the IBM 1401,1440,1460 on the IBM System/370 Models 145 and 155 Using DOS/360 - # GC33-2004
> Emulating the IBM 1401, 1440, and 1460 on the IBM System/370 Models 135 using DOS/360, GC33-2004.
> Emulating the IBM 1401, 1440, and 1460 on the IBM System/370 Models 135, 145, and 155 using OS/360, GC27-6945.
>
>
|
Ken,
Looks like there was a model 15 S/360 too… :)
> Begin forwarded message:
>
> From: Robert Garner
> Subject: Re: IBM 360 model 20 (vs. 30) as first 1401 compatible
> Date: June 12, 2008 at 11:26:36 PM PDT
> To: Bill Worthington
> Cc: David Cortesi , Robert B Garner ,
Ed Thelen , Dan McInnis , Robert Garner
>
> Bill,
>
> Yes, re-reading Karl's email to me last August, I didn't recall it right: their
hardware design was flexible enough to be targeted to either the 1401 or the 360 instruction set,
and they went for 360 ISA at the last moment (no 1401 compatibility at same time).
>
> Here was his text again:
>
> Already after phase 1 (December 1955) the German Lab's electronic department was
no longer involved in the development efforts which resulted in the 1401, while the
printer developments went on. Instead it immediately engaged in the studies for a
new low cost electronic machine for the low end Unit Record market. Focus was on a
low cost printer and a low cost stored program machine for several years, aimed at
a "1430 product" which finally was given up in the final battle 1401- versus /360-compatibility
in 1963. So, the 1430 (the GPD/Endicott preference until 1963) was never anounced and
given up when the /360 systems concept (DSD/Poughkeepsie) prevailed in January/February 1964.
(I don't recall why the 1430 product number was in use while the product was not announced yet?)
>
> The German Lab had been in the middle of this compatibility battle
1401- versus /360- architcture which was taking place in 1963 between GPD Endicott
and DSD Poughkeepsie. It escaped by a tricky processor design: Its new processor
had all functions implemented exclusively in microprogram control stored in a
hardware read-only store (stored function concept). Thus, when the decision was
taken to go /360-compatible early 1964 only this hardware control store had to
be exchanged in order to switch to the other architecture. It took only about
6 weeks redesign of the hardware control store, yet long enough that the product
could not make it for the /360 great announcement in April 1964. So, only in
November 1964 the /36O compatible product could be announced as the /360 Model 20
(which in the following years reached over 15 000 systems shipped world wide).
> But then, the struggling for lower cost continued, and Boeblingen developed a
/360 Model 15 which came out later.
>
>
> The European market really wanted inexpensive machines!
>
> > About the time that the 4300 processors were announced in 1979, this evolved
into a 1401/1440/1460 simulator and no special hardware feature was needed.
>
> It would be interesting to find out when the last 1401 simulator was provided
in a 360/370/Z-series compatible machine.
> I'll have to start asking around...
>
> - Robert
>
> On Jun 12, 2008, at 7:18 PM, Bill Worthington wrote:
>
>> Robert and all,
>>
>> Dave is spot on with his memory of the 360/30 emulation using CCROS microcode.
The 360/40 also had a 1400 emulator. Both turned the processor into a
1401, 1440 and 1460, but you could not run S/360 program concurrently.
>>
>> That changed a year or so later when a group in the Systems Engineering Techniques Development
(SETD) department of the Data Processing Division figured how to use some hardware interfaces
to trap 1400 I/O, Halts, etc. into the Disk Operating System (DOS/360) supervisor as
privileged instructions. The support was known as COMPAT for "1400 COMPATibility support.".
>>
>> The emulator software was formally picked up by IBM Endicott at the announcement of
System/370. The S/370 Models 115, 125, 135 and 145 all had a 1400 emulation feature.
A bit later, it was migrated to OS/VS1.
>>
>> About the time that the 4300 processors were announced in 1979, this evolved into a
1401/1440/1460 simulator and no special hardware feature was needed.
>>
>> The 360/20 had no emulators. It did not even emulate the System/360 well. As
Dave mentioned, it had a reduced set of S/360 instructions and had a few extra that
the S/360 did not.
>>
>> BTW. When S/360 was announced in 1964, there were five models – Models 30, 40, 50, 60 and 62.
Before many were sold, the Models 60 and 62 were modified to Models 65 and 67.
The Models 62 and 67 both had a virtual storage capability – which is another story.
>>
>>
>>
>>
>> David Cortesi wrote:
>>> It is certainly my recollection from my C.E. days in the mid 60s, that the /30
had the emulator (an optional feature, implemented in CCROS microcode). I'm not
certain if 1401 emulation was ever an option on the /40, but it might have been.
>>>
>>> It is my recollection (backed up by Wikipedia, see http://en.wikipedia.org/wiki/IBM_360#Models)
that the 30, 40 and 50 were the initial lineup and the 20 was announced later. It had a
reduced instruction set, was primarily programmed in RPG, and I don't think it had
enough smarts to emulate anything. It couldn't even emulate the 360 very well. ;-)
>>>
>>> On Thu, Jun 12, 2008 at 3:40 PM, Robert B Garner wrote:
>>>
>>>
>>> Bill,
>>>
>>> Do I recall correctly that you had indicated that the first 1401-compatible 360
was the model 30?
>>> And that perhaps Karl was mistaken in an email to me that I forwarded referring to
it as the model 20?
|
Carl, et al,
Vol 4 of Karl Ganzhorn set is also named "Die IBM Laboratorien Böblingen:
Systementwicklung” by Helmut Painke,
or “The IBM Laboratories Bölingen: System Development”.
But I still couldn’t find a copy of it or images on-line...
Google did find this (german) article on Böblingen hardware systems history..
http://www.aendres.de/Texte/Beitrag_Lab_Boeblingen_45.pdf
authored by "Horst Barsuhn, Roland Beyer, Albert Endres, Horst Henn, Herbert Kircher,
Helmut Painke, Manfred Roux, Karl-Heinz Strassemeyer, Edwin Vogt"
It has a section by Painke that talks about a 1430, S/360 model 20, “S/360 model 20 submodel 5”,
and the 4331,
but no dev work on S/370 model 115.
Google translating it, as follows, it sounds like perhaps Karl’s "model 15” could have
been their “submodel 5” project(?).
It also sounds like didn’t make it to market, outcompeted by Endicott's model 25?…
Contemporary witness Helmut Painke reports:
4.1 The System / 360 Model 20 (internally called 011)
In the build-up phase of the lab, the hardware development group
from which later the system development should emerge, with fundamental questions
the punch card reading and examined for this purpose the possibilities of
contactless readout. A dielectric reading method, "Dielectric Sensing", stood
the focus here. In parallel, another group developed a bit serial
working processor with a magnetostrictive delay line as memory.
And in the electromechanical field, the trial took several years, with a
drastically reduced punched card and corresponding readers
to lower the financial threshold for entering data processing and thus
especially to expand the European market. All of this had the character of a
tentative search for a positioning in the big concert of IBM laboratories
in the US and Europe. That changed a few years later with the conception
the new system / 360 architecture, which combines the various competing processor
architectures by a single, the entire great circle of applications and
Performance levels encompassing a single comprehensive and construction area
united.
This opened up the opportunity for the Böblinger laboratory to become a permanent fixture in this
Secure development project. From the beginning we had less the area
the mainframe and scientific 'number cruncher' in the eye rather than the
many small and medium-sized businesses with their punch card machines and tabs.
We positioned ourselves at the bottom of the compatible line.
To achieve the cost targets for this market segment, the company had one here
Subset of the S / 360 architecture developed the S / 360 Mod20 architecture.
The 32-Bit data formats were reduced to 16 bits, which completely excluded
scientific computation operations, and the channel architecture that supports
the input and output devices of isolated the processor properties,
in favor of a random access of the processor abandoned on the devices.
Nevertheless, the task seemed, this still rich and complex structure
to pack on the contents of a kitchen buffet, to be almost insoluble.
The concept of microprogramming, formulated in 1951 by Maurice Wilkes, offered one
Possibility to play off effort against speed and was therefore in
used the smaller systems of the series in different variations. By
the installation of an intermediate level could be realized by the microprogram
complex functions by a simpler structure. In the case of our 011 was
the simplification of the basic structure pushed to the extreme: the data flow was on
just four bits slimmed down, the computing capacity limited to simple up and down
counting with program branching when reaching zero, and all architected registers
were only available as locations in main memory. Jerry Ottaway, a young engineer
from the Poughkeepsie lab in the US
One had devised a rough draft of a microinstruction set that I thought of as
Basis for the hardware design served.
Böblinger, Firsts': Native Attachments, Functional Packaging
Several innovations that we introduced with the S / 360-20 into the design proved
prove to be significant for the success of the system and should prove partially
groundbreaking for the processor design as such in the future. There would be as
First to mention the concept of native attachments, which is the channel function of the
S / 360 architecture and the control logic of each terminal to a direct
integrated by the processor unit and therefore the largest part
of the circuitry overhead into the microprogram, that is bits in memory.
Today, such native attachments as controllers are common in the PC world, especially
when it comes to closely interlocking speed-critical devices with the processor design,
eg. B. in graphics cards or the internal plate.
As much as native attachments helped to reduce the cost of the overall system, they
compounded the problem of limited space in the targeted small box.
The circuit technology available to the S / 360-20
(SLT), could on a palm-sized plug-in surface just 3-4 times
Accommodate circuits. It was not the required area that was responsible for this,
but the limited number of available connections, the signals
on a large A4 'board' headed, where they connect the logic through wires
with each other and thus realized the design. A simple extrapolation showed that
the three boards provided for the processor logic did not even cover half
could accommodate the needed circuits. The bottleneck was the
Access to the circuits on the card, not the circuit density itself.
This problem has been shown time and again in the course of computer development.
The development of terminal density of packaging technologies follows a
shallower trend than that of circuit density in semiconductor technology. Fortunately
The number of necessary connections decreases dramatically if it succeeds on the
individual functional units of logic units, such as registers,
Arithmetic units, or finally whole processors. In the case of S / 360-20 let
The packing density more than doubles when you use a double-wide card
assuming that occupied two sockets, and doubled in height and so on
put a whole register on a map. The height was readily available, the problem was
that it violated the basic principle of personalization
to realize the logic only on the board wiring and not on the cards. The
Card factories provided general purpose components and were neither of the
Still logistically able to provide an exploding type number and still have the
frequent design changes of individual designs
to pursue.
The key to solving the problem lay in the task of designing it
structure, with a few universal functional units (such as registers), which themselves
Moreover, it was possible to personalize it for a variety of purposes through just
a few external lines, to realize the majority of the processor and thus to implement
the principle of
Separation of component supply and individual design should not be violated.
At that time, we did not realize that this once considered a crucial fork
in the design strategy should prove. What started here on the map should be
to continue soon on the chip. Functional packaging was the principle that
made the microprocessor possible and since then at all levels of the key
has led to the breathtaking integration density achieved today.
The 1430 interlude
Technology and cost reduction were not the only problems with which
Ptozessor development in the S / 360-20 had to fight. Also the competition
between the IBM labs around the world, we were initially more concerned than
and dear. A development group in San Jose, California worked on one
System of the same order of magnitude as Böblingen. However, their goal was a scaled-down
version of the 1401 system, IBM's most successful machine at the time. Around
To avoid parallel developments, the higher management decided to unite the two groups
and to be based in Böblingen on the basis of the Böblinger design
work. Ray Wooding came to us from San Jose as program manager and brought
Glen Nielsen as Engineering Manager and some designers. The management experience and
direct contacts with the parent company proved to be
beneficial for the project. The ability to manage a complex program in close liaison
with global laboratories was conveyed to us through the transfer of experience in
San Jose-Böblingen. Less fortunate was that the new ones
Managers used their freedom of movement and distance from the parent company to put
their familiar 1401 architecture to our design. The minimalistic hardware structure
of the Böblinger design proved itself through a great adaptability. Most differences settled
by programming in the microprogram, only the memory addressing required a conversion
from decimal to binary addressing. And
then the corporation finally the parallel development of two architectures
stopped again, the back conversion to S / 360 was overcome in record time.
The system structure of the Model 20
The data flow of the S / 360-20 consisted essentially of eight 4-bit registers
and a check bit connected via a bus and a logic network
were. Four of the registers were used to address the main memory, two took over
the function of a data register for the memory, the remaining two
served the microprogram for prefix and index purposes. All of the architecture
provided registers were realized by data in the core memory. To that
The purpose of the core memory except the 4096 bytes for normal programs and contained
Data a so-called auxiliary store of 256 bytes. There were 10 for each byte
Memory cores available, because each 4-bit digit was assigned a check bit. The
Memory cycle, like the processor clock, was 3.6 microseconds.
The microprogram resided in an inductive read-only memory, the so-called TROS
(Transformer Read Only Store). The bit pattern of a microinstruction
is represented by a printed on a plastic film conductor pattern,
through the sprouts magnetic cores are plugged. Through holes inside or outside the cores,
the current is passed either through the cores or out, thereby generating the bit pulses.
The films are stacked on the cores, resulting in a dense and easily changeable by punching a film
Storage. The access time was 0.6 microseconds.
4.2 System / 360-20 Submodel 5
After the various models of the S / 360-20 had established themselves in the market,
The question arose about the growth path of these customers. The jump to
The next higher S / 360 model was problematic for two reasons:
1. The S / 360-30 was not only seven times faster, but also several times more expensive;
not only because of the processor, but also because of the more expensive input / output
devices with their expensive control units.
2. The leap from the S / 360-20 world into the full S / 360 world demanded despite the
Similarity of the architectures but some program changes. Especially
but he meant the abandonment of cherished I / O devices like the
Multifunction Card Machine (IBM 2560 MFCM).
The goal was therefore to offer triple the performance within the S / 360-20 architecture
with a core memory that exploited the full 32kB boundary of the architecture,
and in the same box as the previous machine.
The technology advancement came in the form of a faster and more physical way
smaller core memory and in an increased circuit density on the card to
Help, but still it required a complete change in the design concept.
The combination of a 3.6 microsecond core memory for the program and a 0.6 microsecond TROS
for the microprogram was done now
No more sense, because the core memory is set to two microseconds cycle at a
Access time of 560 nanoseconds had improved, but the TROS at the 600
Nanoseconds had stopped.
The radically new design concept was based on a design study of groundbreaking under
Wilhelm Spruth for a system below the S / 360-20
but for this area had proved too expensive. The basic idea was to completely abandon
the read-only memory for the microprogram and now the faster one
Core memory for the microprogram mitzubenutzen. Of course, this required a drastically
different microprogram type - instead of the horizontal nature of control bits for
each function in each processor cycle, a vertical one was needed now
was coded more strongly and therefore could take over the control over several cycles.
Only then could it coexist in memory with the S / 360 program,
without slowing it down too much. Of course, this higher functionality of the
microinstruction set also requires more hardware. The data flow
has been extended from four to 16 bits, the same width as the core memory.
Thus, the microinstruction was limited to 16 bits, which is an address counter
instead of the follow-up address in the microinstructions of the predecessor needed.
So we went all the way to vertical microprogramming,
and this remained a hallmark of the Böblinger processors for the subsequent period.
A serious consequence of this concept, however, was the need to first read in the
microprogram from a set of punched cards each time the system was switched on,
previously the machine was 'faceless'. The reading in of the first card of
this routine therefore had to be fully hardware-controlled, which then received
the initialization routine. By the way, a positive side effect of this concept was
that was given the opportunity to load in principle any architecture, too
if then the microinstruction set did not support everyone equally well. For the
creation of a 1401 emulator, however, it was very helpful.
Technical innovations
The vertical microinstructions required corresponding temporal activation of the
Control signals, ie timing charts. By having a punched card for each microinstruction
with the up to eight cycles as columns and the individual microinstructions generated
and these cards were then sorted by microinstructions
Make a list for each control signal when it had to appear. The
was a great help in the design and something like the first step to automatic design
processing. For easier diagnosis in case of error were important
Control signals monitored in each cycle and stored in a register. in the
In case of error, this information has been frozen, so that its state in the cycle, the
brought the error, could be read out. The S / 360 registers, yes at the
The previous model was still stored in the core memory and had now migrated to the
hardware were not realized in circuit registers, but in a small semiconductor memory,
the local store. Thus, unnoticed, semiconductor memory was introduced into computer design.
Internal competition between laboratories
In this case too, the Böblinger laboratory had to face internal competition again
put. The Endicott laboratory had been responsible for the development of the
S / 360-30 and was now planning to fill the void with a cost-reduced S / 360-20
Close S / 360 system. that they called 30-D. In addition, they offered to cover
by Microprogrammänderung also the S / 360-20 mode. Böblingen countered
with the offer, through minor modifications and corresponding microprogram
to develop a fully S / 360 compatible version of the 20-I.
In a three-week task force in Endicott, both sides had to prove that they were
were able to cover each other's area with their design, taking
the real problems lay less in the basic architecture than in the peripheral areas
of disk and I / O control. Finally gave, how
expects the significantly lower costs of the Böblinger design to prevail. The
Solomon's decision was: "A joint program based on
the 20-I data flow. But nine days later, this decision was revised and then read:
'Both programs are continued separately, the Böblinger
as S / 360-20 submodel 5, the endicotter as S / 360-25. ‘
4.3 The Early Bipolar S / 370 Systems
From 1969, IBM went to a complete reissue of the S / 360 series. In addition to some
Extensions in the instruction set and in the maintenance area as well as the possibility
for parallel operation of several processors to a memory was the introduction
the Virtual Storage concept is a major innovation. The maximum amount of memory
available in the architecture is made available to the programmer. Unnoticed by the user,
the Storage Manager loads the required program and data segments from the disk into the physical memory.
This new package of extensions was named S / 370 to accentuate progress over S / 360.
The S / 370-125 (internally called NS-T)
The code name for the new systems was New Systems (NS). After due to the
As technology progressed, the difference between the stripped - down and
full - fledged architecture did not matter so much, Böblingen decided
S / 370 version change. The Endicotter laboratory, previously responsible for
the lowest fully compatible S / 360 machine, had dubbed its new design NS-0. Böblingen
Convinced that the line could be extended down, she set up a program naming
NS-T (Threshold Threshold).
The technology had progressed rapidly. Integrated circuits heralded the
breathtaking density race on the chips with almost
a factor of 2 per year and corresponding cost per circuit. Especially with
regular structures such as saving the density progress was on
largest. This offered for the first time the chance to replace the core memory with ICs. The
NS-T-Design consistently focused on this trend, but he also used it creatively
for the internal structure of the system. While with core memories the basic
unit cost was high, the cost of enlargement was small and therefore
the need to use an existing memory for as many functions as possible, was in a
semiconductor memory, the cost in the first approximation
linearly dependent on size - many small stores were barely more expensive than one
greater.
On the other hand, many small stores offered the chance to use them in parallel and
thereby increasing the speed. And the chance took advantage of the NS-T design
sent out. First, the microprogram got its own program memory again. But then the
processor itself was freed from all control tasks for input / output devices and
the channel. Each type of device - card devices, printers, disk storage, etc.
- has its own small microprocessor
and the associated microprogram memory. This specially designed for it
IOP (Input Output Processor) fitted with memory on a card and was through
Personalized micro-program and so-called front-end hardware for each device.
The actual processor, the IPU (Instruction Processing Unit), was a
16-bit design with a 16-bit microinstruction set. And finally, the control panel,
with its lights and switches, was replaced by a console with a screen controlled
by a third type of processor, the SVP (Service Processor). This SVP not only
replaced the control panel, but took over
also the initialization by a floppy disk instead of by card sets. This principle
was then applied in all subsequent systems.
As with the 20-I, we attached great importance to optimally matching the
design to the technology. The circuits had the new MST technology
Jump made from 2.5 to 30 circuits per chip. An extension of the meanwhile
standard 2-times wide and 2-times high card on 3-fold height,
which could finally be enforced against tenacious defense of the technology
fraction, brought the breakthrough to an optimal functionality - Functional
Packaging had finally prevailed at the card level, a generation
before it finally reached the chip.
4.4 The interlude Future Systems
In view of the rapid progress of the semiconductor technology, in particular
visible at the triumphal march of the microprocessors beginning of the 70's
increased in IBM's fears that the revenues from the computer hardware would
not be enough, the price of hardware falling through volume expansion
of the offer. One possible answer seemed to be a radical expansion of the
functions offered by the computer
To create balance. The proposal was essential parts of the operating systems
and integrate many common features into the architecture and directly
in hardware. This was no longer possible through a gradual expansion
the S / 370 architecture, but required a similar effort
as in 1964 with a simultaneous introduction of new hardware and software over the
whole range of power levels and applications. The Future Systems program,
launched in 1973, involved all development laboratories. Böblingen
was already traditionally responsible for the lower end of the series and
participated in the draft of an FS-A, codenamed Alabama. However, the
new architecture was much less design-intensive than the other laboratories,
as essential parts were still implemented in microprograms rather than hardware.
By 1974, however, it became apparent that the risk of the "big jump" was
an incalculable magnitude. The assumed circuit density on the
Chip could only be achieved for larger functional units because of the otherwise
favorable ratio of required connection lines to the circuit number,
which would require chips the size of a wafer with serious impact on the yield.
Even the conversion problems threw on a new architecture
In the customer area obviously too many problems. It speaks for the vitality and
Flexibility of the company, how determined it reacted now. Within a few weeks
the helm was torn and the strategy reoriented. In a historic task force, the
so-called 7/11 Task Force (after building No. 7/11
in White Plains, where it took place), representatives of all laboratories,
programming centers, factories, marketing, etc. worked out a new strategy
and strategy in four weeks a product plan. And Böblingen took over again the
lower end with the Design of the INCA, which was then finally announced as 4331.
|