Re: GREAT presentation on the history of the mainframe
l...@garlic.com (Anne & Lynn Wheeler) writes: > 3090 added vector processing as part of playing in the supercomputer > market ... however that required that they also be able to support > 100mbyte/sec (and/or 1gbit/sec) I/O. 3090 was barely able to get up to > 4.5mbyte/sec transfers ... so what to do? re: http://www.garlic.com/~lynn/2017d.html#4 GREAT presentation on the history of the mainframe as mentioned mainframe bus half-duplex had increasing throughput problems, handling 3mbyte/sec disks and then 4.5mbyte/sec disks ... but unable to handle the engineering 40mbyte/sec disk arrays. I've also mentioned that ESCON didn't finally get announced until it was already obsolete (1990 w/ES9000) ... at 17mbytes/sec, it couldn't also handle the 40mbyte/sec disk arrays. This also basically precluded a project that the father of 801/risc roped me into ... doing a "wide" disk head that did 18 tracks in parallel. This is somewhat analogous to the 60s 2301 drum, essentially the same as the 2303 drum but read/wrote four tracks in parallel at a time, four times the transfer rate with 1/4th the number of tracks that were four times larger. Original 3380 had 20track width spacing between every data track. This was later reduced to 10track width spacings for double density 3380 with twice the number of cylinders ... and the spacing was reduced again for triple density 3380. Tne 3380 "wide-head" disk would have 16 adjacent data tracks plus a 17th servo track. The "wide-head" would span 18tracks, two servo tracks on either side of the 16 data tracks. It would read/write at 16*3mbytes/sec=48mbytes/sec. The problem for the project was that none of IBM mainframe I/O could handle that data rate. some old email about the wide-head r/w 16 data tracks. http://www.garlic.com/~lynn/2006s.html#email871122 http://www.garlic.com/~lynn/2006s.html#email871230 following year (1988), I get asked to help LLNL standardize some serial stuff they are playing with ... which quickly evolves into fibre channel standard (initially @1gbit/sec full-duplex, 2gbit/sec aggregate) ... but mainframe heavy-duty protocol running over fibre channel standard isn't available until much, much later http://www.garlic.com/~lynn/submisc.html#ficon past posts getting to play disk engineer in bldgs 14&15 in the late 70s and much of the 80s http://www.garlic.com/~lynn/subtopic.html#disk past 16+2 disk head posts: http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ? http://www.garlic.com/~lynn/2007m.html#23 Bulkiest removable storage media? http://www.garlic.com/~lynn/2007o.html#64 Toshiba Boosts Hard Drive Density By 50% http://www.garlic.com/~lynn/2009e.html#41 "A foolish consistancy" or "3390 cyl/track architecture" http://www.garlic.com/~lynn/2009i.html#66 Was there ever a 10in floppy? http://www.garlic.com/~lynn/2009k.html#75 Disksize history question http://www.garlic.com/~lynn/2009p.html#12 Secret Service plans IT reboot http://www.garlic.com/~lynn/2010m.html#52 Basic question about CPU instructions http://www.garlic.com/~lynn/2011g.html#70 History of byte addressing http://www.garlic.com/~lynn/2012e.html#39 A bit of IBM System 360 nostalgia http://www.garlic.com/~lynn/2012e.html#103 Hard Disk Drive Construction http://www.garlic.com/~lynn/2013e.html#3 The Big, Bad Bit Stuffers of IBM http://www.garlic.com/~lynn/2013g.html#41 A History Of Mainframe Computing http://www.garlic.com/~lynn/2013o.html#92 Cylinder buffer http://www.garlic.com/~lynn/2014b.html#17 Quixotically on-topic post, still on topic http://www.garlic.com/~lynn/2014l.html#78 Could this be the wrongest prediction of all time? http://www.garlic.com/~lynn/2016f.html#2 IBM DASD RAS discussion -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
re: http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#89 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#94 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#95 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017d.html#1 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017d.html#3 GREAT presentation on the history of the mainframe even more 3090 trivia: before starting work on LLNL fibre channel standard (pair of fibre-optic dedicated to transmission in each direction, original getting 1gbit/sec concurrent, full-duplex, 2gbit/sec aggregate) ... LANL started standardization of the Cray 100mbyte/sec parallel channel. HIPPI https://en.wikipedia.org/wiki/HIPPI there then forms some competition between LLNL FCS and LANL HIPPI, where HIPPI is being extended to serial HIPPI fiber optic and 200MB/s. 3090 added vector processing as part of playing in the supercomputer market ... however that required that they also be able to support 100mbyte/sec (and/or 1gbit/sec) I/O. 3090 was barely able to get up to 4.5mbyte/sec transfers ... so what to do? turns out that physical memory packaging had created a problem for 3090 and to address the problem they came up with memory hierarchy with extended store ... wide, fast bus with instructions to syncronously move 4k bytes between processor memory and extended store memory (although the memory chip technology was the same). The extended store interface turns out to be the only part of 3090 capable of handling the data rate. There is kludge that hooks HIPPI I/O interface into reserved addresses in the extended store bus ... and a sort of PC I/O paradigm using sort of peek/poke convention for doing I/O (extended store bus instructions moving data to/from these reserved addresses). That enables being to attach things like 40mbyte/sec disk arrays to 3090. There was lab. in kinstaon that worked with these kinds of applications ... but it was populated with dozen FPS (floating point systems) boxes that included 40mbyte/sec disk array support as part of native environment. one of projects I had was HSDT and was suppose to get $20M from the director of NSF to interconnect the NSF supercomputer centers (or at least before congress cuts the budget). However, one of my internal HSDT links was into the (IBM) kingston datacenter that had all these FPS boxes. some past HSDT posts http://www.garlic.com/~lynn/subnetwork.html#hsdt some past 3090 extended store posts http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs? http://www.garlic.com/~lynn/2008i.html#10 Different Implementations of VLIW http://www.garlic.com/~lynn/2013g.html#41 A History Of Mainframe Computing http://www.garlic.com/~lynn/2013h.html#3 The cloud is killing traditional hardware and software http://www.garlic.com/~lynn/2013i.html#50 The Subroutine Call http://www.garlic.com/~lynn/2013m.html#99 SHARE Blog: News Flash: The Mainframe (Still) Isn't Dead http://www.garlic.com/~lynn/2017b.html#69 The ICL 2900 past posts mentioning FPS boxes (and 40mbyte/sec disk arrays in the mid-80s) http://www.garlic.com/~lynn/2000c.html#5 TF-1 http://www.garlic.com/~lynn/2000c.html#61 TF-1 http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore? http://www.garlic.com/~lynn/2001d.html#32 Imitation... http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002j.html#30 Weird http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix http://www.garlic.com/~lynn/2006m.html#4 The Power of the NORC http://www.garlic.com/~lynn/2006o.html#1 harris http://www.garlic.com/~lynn/2009j.html#54 A Complete History Of Mainframe Computing http://www.garlic.com/~lynn/2010b.html#72 Happy DEC-10 Day http://www.garlic.com/~lynn/2010f.html#61 Handling multicore CPUs; what the competition is thinking http://www.garlic.com/~lynn/2011h.html#74 Vector processors on the 3090 http://www.garlic.com/~lynn/2011n.html#36
Re: GREAT presentation on the history of the mainframe
mitchd...@gmail.com (Dana Mitchell) writes: > 4331 had integrated disk and communication adapters built in, no 3274, > 3705, 3880 controllers required. Later machines just had parallel > channels just sort of built in, not really on cards. 3090 was first > with ESCON re: http://www.garlic.com/~lynn/2017d.html#1 GREAT presentation on the history of the mainframe "4331" was "boeblingen" machine, like 115&125, with integrated channels & integrated controllers http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#95 GREAT presentation on the history of the mainframe ... while "4341" was "Endicott" machine, with integrated channels like 370/158 ... however 4341 was faster than 158&3031 ... and 4341 integrated channels were much faster than 158 integrated channels (158 integrated channels was also used as external channel for all 303x processors). 4341 integrated channels were so fast that with slight tweak ... they could be used for 3380 3mbyte/sec testing. http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of the mainframe past posts getting to play disk engineer in bldgs14&15 htttp://www.garlic.com/~lynn/subtopic.html#disk mid-range disks for 4331&4341 were FBA (3310 & 3370) also low environmentals so straight-foward to deploy in non-datacenter environments. https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3370.html https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3370b.html high-end datacenter disks were 3380 3mbyte/sec, still CKD ... but small fixed cell size (for things like error correcting) ... so record lengths had to be rounded up to cell size ... for determining records/track. As POK favorite son operating system continued to fail to deploy FBA support ... and all physical disks moved to industry standard fixed-block, CKD became an legacy anachronism, all simulated on industry standard fixed-block disks (decades after CKD stopped being built). past posts http://www.garlic.com/~lynn/submain.html#dasd -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
mitchd...@gmail.com (Dana Mitchell) writes: > 4331 had integrated disk and communication adapters built in, no 3274, > 3705, 3880 controllers required. Later machines just had parallel > channels just sort of built in, not really on cards. 3090 was first > with ESCON minor nit, ESCON announced with ES/9000 in 1990 ... https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS9000.html Enterprise Systems Connection (ESCON) Architecture implementing fiber optic channels, which provide significantly higher data rates than traditional parallel channels and which permit input/output equipment to be located at distances up to nine kilometers (5.6 miles) from the processor; ... snip ... from Computerworld, 20Jan1992, volXXVI, #3, pg. 29 article, "No stampeded to IBM's Escon" IBM's Escon architecture, introduced in September 1990, is a fiber-optic-based method of connecting processors, storage devices and peripherals. ... snip ... 1980, STL cons me into doing channel extender support. They are moving 300 people from the IMS group to an offsite bldg with remote access back to STL datacenter. The victim group had tried remote 3270 support and found the human factors totally unacceptable. The channel extender support puts 3270 channel attached controllers at the offsite bldg. The channel extender support ... downloads channel programs to channel simulator at the remote site ... significantly offsetting the latency and overhead of the intensive channel protocol chatter over the extended distance. Instead streams data & channel programs simultaneously over full-duplex connection (side-by-side 3270 demos with real local channel attached and channel-extender running loop-back to offsite bldg and back ... it is not possible to tell difference). Vendor then tries to get IBM to allow release of my support. However there is a group in POK that is playing with some fibre stuff that gets it blocked because they are concerned that if it was in the market, it would make it harder to get their stuff released. some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender STL does a special 3270 logon screen for the IMS people at the offsite bldg (standard login for all of STL is VM370, even for people working on IMS, DB2, MVS, etc). This was also in the days of increasing focus on productivity from subsecond response. Standard TSO at best was second, and most of the time much worse. Lots of internal VM370 systems were .2sec ... but I did "SJR/VM" systems that lots of internal datacenters ran that would get .1sec using same hardware with identical load (when I was at science center, it was CSC/VM that lots of internal datacenters ran, before I transfered to san jose research) http://www.garlic.com/~lynn/vmhyper.jpg In 1988, I'm asked to help LLNL standardize some serial technology they are working with ... which quickly becomes Fibre Channel Standard ... including concurrent streaming in both directions of data & downloaded I/O programs (minimizing latency of I/O program protocol chatter). Then ESCON is announced 1990 with ES/9000 when it is already obsolete. Then some POK engineers became involved with fibre channel standard and defined an extremely heavy-weight protocol that drastically cuts the native throughput, which is eventually announced as FICON. Most recent "peak I/O" benchmark I can find is z196 getting 2M IOPS using 104 FICON. About the same time there was native FCS announced for E5-2600 blade claiming over million IOPS (for single FCS, two such FCS having higher throughput than 104 FICON running over 104 FCS). There is some mention of zHPF/TCW that is a little like what I had done originally in 1980 ... but claims only 30% improvement over standard FICON (possibly 2M IOPS with only 70 FICON?) some past posts http://www.garlic.com/~lynn/submisc.html#ficon 3090 trivia: engineers were really upset being directed to use slow, vertical microcoded JIB-prime for 3880 disk controller. It had special hardware bypass for 3mbyte/sec data transfer ... but the controller was really slow at processing channel programs and rest of the channel protocol chatter, signicantly increasing channel busy (much, much slower than the previous horizontal microcode 3830 disk controller). 3090 had designed balanced configuration throughput assuming that channel protocol overhead busy would be similar to 3830 (with improvement that data transferred at 3mbyte/sec). When they found how bad 3880 channel busy was going to be, they had to significantly increase the number of channels ... which required an additional TCM, which increased manufacturing cost. There were semi-facetious references that the 3090 group was going to bill the 3880 controller organization for the additional TCM. Then marketing spins all the additional channels as how much it increases the 3090 I/O throughput (obfuscating the fact that the additional channels were required for the significant increase in channel busy overhead). past posts
Re: GREAT presentation on the history of the mainframe
Dana, Thank you for the response, I appreciate it. Just minor remarks: * HMC in 9672 was OS/2 based (at least since G3) * There were some crypto options in pre-9672 machines, it was rather predecessor of CCF, not the cards. I have some information it was ICRF (Integrated CRyptographic Feature) which consisted of TCM and KSU (Key Storage Unit). Not to mention earlier 4753 aka NSP or 3945. * I believe first OSA in 9672 was OSA2 and of course there was OSA (1) before. * I vaguely remember some photograph of pre-9672 machina (which one?) with cards similar to those in 9672. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2017-03-27 o 16:09, Dana Mitchell pisze: On Fri, 24 Mar 2017 20:44:10 +0100, R.S.wrote: BTW: What about LPARs? 3090 was first generation with PR/SM facility. CEC could be PORed in PR/SM mode or 370 mode. How HMC looked like? Was it PC-DOS-based? 4331/4341 had a dedicated 3278 with extra buttons and LED's on keyboard, could also be used as operating system console. 3083/3081 had dedicated 3270s one mounted inside 3082 processor controller. 3090 had dedicated 3180 displays for system control. 9672 had first linux based HMC. What about I/O cards? were they similar to cards available in 9672? 4331 had integrated disk and communication adapters built in, no 3274, 3705, 3880 controllers required. Later machines just had parallel channels just sort of built in, not really on cards. 3090 was first with ESCON What OSA options were available? First on 9672, I think was basically a 3172 built into frame. What about cryptoHW? nope Dana -- -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On Fri, 24 Mar 2017 20:44:10 +0100, R.S.wrote: >BTW: >What about LPARs? 3090 was first generation with PR/SM facility. CEC could be PORed in PR/SM mode or 370 mode. >How HMC looked like? Was it PC-DOS-based? 4331/4341 had a dedicated 3278 with extra buttons and LED's on keyboard, could also be used as operating system console. 3083/3081 had dedicated 3270s one mounted inside 3082 processor controller. 3090 had dedicated 3180 displays for system control. 9672 had first linux based HMC. >What about I/O cards? were they similar to cards available in 9672? 4331 had integrated disk and communication adapters built in, no 3274, 3705, 3880 controllers required. Later machines just had parallel channels just sort of built in, not really on cards. 3090 was first with ESCON >What OSA options were available? First on 9672, I think was basically a 3172 built into frame. >What about cryptoHW? nope Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
t...@harminc.net (Tony Harminc) writes: > Boeblingen got their hands slapped for anti-trust reasons for moving > the controllers inside (shades of the 2319 disk), or because corporate > inherently favoured Endicott over Boeblingen (and presumably POK over > both)? Or something else? re: http://www.garlic.com/~lynn/2017.html#74 The ICL 2900 http://www.garlic.com/~lynn/2017.html#86 GREAT presentation on the history of the mainframe memory bus with generalized 9-positions for microprocessors (& microprocessor all the same) was much more advanced design than other IBM systems were (suppose to be) doing. which in part, made it straight-forward to do the 5-way SMP, past posts http://www.garlic.com/~lynn/submain.html#bounce note some of this would have been similar (but different) to effort later in the 70s to migrate the large number of different internal microprocessors to 801/risc (Illiad). past 801 posts http://www.garlic.com/~lynn/subtopic.html#801 because of the difficulty having all the unique development and operations for each unique microprocessor. I've previously told story after working on ECPS for endicott and 5-way SMP for Boeblingen, I got involved in doing 16-way SMP which lots of people thought was really great ... even getting 3033 processor engineers to work on it in their spare time (lot more interesting than remapping 168-3 logic to 20% faster chips) That is until somebody informed the head of POK that it could be decades before the POK favorite son operating system had (effective) 16-way support ... at which time some of us were invited to never visit POK again (and 3033 processor engineers to stop being distracted). IBM eventually ships 16-way system more than two decades later ... recent reference http://www.garlic.com/~lynn/2017c.html#30 The ICL 2900 past SMP posts http://www.garlic.com/~lynn/subtopic.html#smp -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
t...@harminc.net (Tony Harminc) writes: > How were either of the 4331 or 4361 scope'able? Surely both were at > about the same level of integration as the TCMs in the 30x0... > > Or had the scope'able requirement quietly disappeared by that point in > favour of redundancy, leaving the other advantages of the service > processor? re: http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#89 GREAT presentation on the history of the mainframe 3081&3090 had significant denser physical packaging contained within TCM modules (no contacts to scope) ... built probes into the TCM packaging and diagnositic using the probes from the service processor. https://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV2137.html originally single 4331 and then upgraded to pair of redundant 4361s ... scopable ... less dense. 4300s and DEC VAX saw similar explosion in sales in the low & mid-range market for single or few unit orders ... old post with decade of VAX sales sliced by year, model, US/non-US http://www.garlic.com/~lynn/2002f.html#0 Big differrence between 4300 & DEC VAX was large corporations ordering multiple hundred 4300s at a time for placing out in departmental areas ("leading edge of the distributed computing tsunami"). IBM (& DEC) was expecting continued explosion in low/mid range sales with 4300 followon; 4361 & 4381. However as can be seen in the VAX numbers, by mid-80s, the low/mid range market was starting to move to workstations and large PC servers. Folklore is that 3092 went to pair of redundant 4361s ... because there were large number of unsold 4361s in warehouses. other folklore about 3081 (density/weight). 3081 was originally designed to be multiprocessor only (two processors & channels in single "heavy" frame). Problem came up with ACP/TPS which had loosely-coupled support but no tightly-coupled multiprocessor support. The clone mainframe makers was still making single processor machines and there was concern that the whole ACP/TPS market moves to clone makers. The decision was made to come out with single processor 3083 for the ACP/TPS market (3081 with one processor removed). The easiest would have been to keep processor0 and remove processor1. The problem was that processor0 was at the top of the box and simple removal of processor1 (in the middle, channels at the bottom), could have made the box dangerously top-heavy. https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3081.html this talks about 3033 and 3081 quickly kicked off (including 3081 had enormous excess number of circuits for the level of performance) after failure of FS project http://www.jfsowa.com/computer/memo125.htm past FS posts http://www.garlic.com/~lynn/submain.html#futuresys Note while the above IBM 3081 history page says: Model D is capable of an instruction execution rate of up to 21 times that of a 3033UP running under MVS/SP with identical programs and similar configurations. ... snip ... however there were quite a few benchmarks that had application running on single 3081D processor having lower throughput than on 3033 (single processor). IBM then comes out with 3081K with double the cache size of 3081D (somewhat similar to 168-3 having twice cache size of 168-1), assuming it would improve cache hit rate (and therefor throughput) for some number of applications. past multiprocessor SMP posts http://www.garlic.com/~lynn/subtopic.html#smp -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On 24 March 2017 at 13:43, Anne & Lynn Wheelerwrote: > boeblingon got their hands slapped by corporate for the 370/115 & > 370/125. The 370/115 had nine-position memory bus for microprocessors > ... all identical ... one microprocessor was programmed for simulating > 370 instructions and one or several other microprocessors programmed > with controller microcode (i.e. not only integrated channels, but also > integrated controllers). Boeblingen got their hands slapped for anti-trust reasons for moving the controllers inside (shades of the 2319 disk), or because corporate inherently favoured Endicott over Boeblingen (and presumably POK over both)? Or something else? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On 24 March 2017 at 16:38, Anne & Lynn Wheelerwrote: > FE had failure diagnoses requirement for bootstrap scope'able process. > 3081 were inside TCM and no longer scope'able. Process was then a > scope'able service processor ... that could be diagnosed/repaired and > then the service processor had large number of probes into TCMs and the > service processor could be used to diagnose the TCMs. The 3081 service > processor was UC microprocessor and everything had to be developed and > implemented from scratch. > > For the 3090, they originally planned on using a 4331 with a highly > modified version of vm370/cms release 6 as the service process ... with > all service screens done in CMS IOS3270. This was upgraded to a pair of > redundant 4361s. The 3092 ("service processor", i.e. pair of 4361s) has > requirement for two FBA3370s (even for MVS customers that never > supported FBA). ... 3090 announced 12Feb1985 (including requirement for > two FBA3370s for 3092 service processor) How were either of the 4331 or 4361 scope'able? Surely both were at about the same level of integration as the TCMs in the 30x0... Or had the scope'able requirement quietly disappeared by that point in favour of redundancy, leaving the other advantages of the service processor? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On 03/23/2017 06:58 AM, Tom Marchant wrote: > On Thu, 23 Mar 2017 02:27:32 +, scott Ford wrote: > >> One of my first sysprog jobs was on a 370-155 un-dated ..no dynamic address >> translation ran Intel's DOS look-a-like. > ITYM IBM Disk Operating System, which predated Intel by years. > It is nothing like MSDOS. Did Intel ever have a DOS? > No, I'm pretty sure he instead means Itel DOS. I think it was compatible (from application standpoint) with IBM DOS/VS but ran on 360 architecture without DAT. The company I went to work for in 1978 was running all corporate computing under Itel DOS on two IBM 360/65 processors with 1 MiB central memory each (also from Itel) and Itel 3330 compatible DASD and tape drives after an upgrade attempt to IBM 370 combined with an attempt to run VM to enable a migration path to MVS failed miserably because the 370 turned out to have insufficient real memory to run the existing workload. Itel's offer to back out the 370 and replace with dual 360/65's was the fastest and cheapest fix to get things functional again. We had resident CE's from both Itel and IBM (who worked quite well together). Around 1980 we were finally able to convert to two IBM 4341's with DOS/VSE, but still ran with Itel DASD and tape for many years. It took until 1985 before management could be convinced to repeat the attempt to migrate to MVS, this time with an IBM 3033 under VM with multiple DOS/VSE systems and a IBM 3083 under VM XA Migration aid for DOS/VSE and MVS/XA systems. By the time we finally did get off DOS/VSE we were seriously constrained by the limits DOS/VSE placed on virtual memory, despite running the max of four coupled DOS/VSE systems with shared POWER spool. Joel C. Ewing -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
l...@garlic.com (Anne & Lynn Wheeler) writes: > For the 3090, they originally planned on using a 4331 with a highly > modified version of vm370/cms release 6 as the service process ... with > all service screens done in CMS IOS3270. This was upgraded to a pair of > redundant 4361s. The 3092 ("service processor", i.e. pair of 4361s) has > requirement for two FBA3370s (even for MVS customers that never > supported FBA). ... 3090 announced 12Feb1985 (including requirement for > two FBA3370s for 3092 service processor) > https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html re: http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of the mainframe other 3092 lore. Early in the days of REX (before rename to REXX and release to customers), I wanted to demonstrated REX was not just another pretty scripting language so I chose as demonstration to rewrite IPCS (dump reader, huge amount of assembler code) in less than 3months elapsed time working less than half time would have ten times the function and run ten times faster (some tricky coding to make interpreted rex run ten times faster than assembler). I finished early, so developed a set of automated library routines that would examine for the most common types of failures. I thot that it would then be released to customers as upgrade to existing IPCS, but for some reason that never happened even tho it came to be in use by nearly every internal datacenter and customer PSR. I eventually got permission to make presentations on DUMPRX and how it was implemented ... and within several months, similar implementations started appearing at customers. Eventually the 3092 service process group contacted me about including it in 3092 release. Since their vm370/cms release 6 was heavily modified and out-of-date, they had to do almost all the service themselves and they relied heavily on DUMPRX. some old email from the 3092 group http://www.garlic.com/~lynn/2010e.html#email861031 http://www.garlic.com/~lynn/2010e.html#email861223 past posts mentioning dumprx http://www.garlic.com/~lynn/submain.html#dumprx -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
r.skoru...@bremultibank.com.pl (R.S.) writes: > BTW: > What about LPARs? re: http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of the mainframe FE had failure diagnoses requirement for bootstrap scope'able process. 3081 were inside TCM and no longer scope'able. Process was then a scope'able service processor ... that could be diagnosed/repaired and then the service processor had large number of probes into TCMs and the service processor could be used to diagnose the TCMs. The 3081 service processor was UC microprocessor and everything had to be developed and implemented from scratch. For the 3090, they originally planned on using a 4331 with a highly modified version of vm370/cms release 6 as the service process ... with all service screens done in CMS IOS3270. This was upgraded to a pair of redundant 4361s. The 3092 ("service processor", i.e. pair of 4361s) has requirement for two FBA3370s (even for MVS customers that never supported FBA). ... 3090 announced 12Feb1985 (including requirement for two FBA3370s for 3092 service processor) https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html I had done a lot of work on ECPS microcode assist and later would give talks on the implementation at monthly user group meetings ... and the Amdahl people would talk to me about their hypervisor implementation ... old email from 1980 http://www.garlic.com/~lynn/2006p.html#email801121 mentioned in upthread discussion in this post archived here http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe IBM eventually responds to Amdahl's hypervisor with PR/SM & LPAR on the 3090 (announced 12Feb1985) -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
John McKown wrote: No HMC. The console looked like a 3270 which was "built into" the machine. Was that the specialized console where I used to type things like L1 and A2 (or whatever it was) to set the load address and IPL? I don't remember the exact commands - from 3084 days. And then there was the really loud beep when a box would go into a disabled wait state. Ouch. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
I totally agree with the dismay expressed at omission of 9672/9674. I've only been in this biz since the late 70s, but I was blown away at the architectural upheaval represented by the move from bipolar to CMOS. Yet the 9672 still ran decades-old programs without even recompile, let alone revision. The 9672 ran rather like a dog in the early days. We had to modify SMF exits to allow up to three times the coded CPU limit for batch jobs to avoid S322. But it worked, and as time went on, the CMOS processors became faster than the bipolar machines they replaced. I smell genius. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, March 24, 2017 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: GREAT presentation on the history of the mainframe On Fri, Mar 24, 2017 at 2:44 PM, R.S.wrote: > W dniu 2017-03-24 o 18:04, Pommier, Rex pisze: > >> The only thing I wish he would have included in the presentation was >> the original 9672/9674 which was a huge shift from the GA-AS >> technology to silicon. >> > > I wish I hadn't worked on pre-9672 machines. > Was it really non-silicon? I was pretty sure it was silicon, but ECL, > not CMOS. > > BTW: > What about LPARs? > Yes. In "partitioned mode". > How HMC looked like? Was it PC-DOS-based? > No HMC. The console looked like a 3270 which was "built into" the machine. Older ones had _dials_ and _buttons_ and _LIGHTS_! Oh, how I miss the lights. > What about I/O cards? were they similar to cards available in 9672? > What OSA options were available? > No OSAs. Had to have an outboard controller on a regular byte multiplexer channel (not block or selector). > What about cryptoHW? > No co-processor cards. Unless you think of integrated channels as a co-processor, that is. > > -- > Radoslaw Skorupka > Lodz, Poland > > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
l...@garlic.com (Anne & Lynn Wheeler) writes: > Endicott then complains tht the 5-way 370/125 SMP has better > performance and better price/performance than 370/148 and I'm required > in escalation meetings to argue both sides. Endicott wins ... and the > 5-way SMP 370/125 is never announced. re: http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe note later, 3033 was really threatened by 4341 ... clusters of 4341 had better performance, throughput, price/performance, lower floor footprint, lower environmentals and power/instruction than 3033. at one point head of POK was so threatened that he got allocation of critical 4341 manufacturing component cut in half. some large customers were also ordering hundreds of 4300s at a time for placing out in departmental areas ... the leading edge of the coming distributed computing tsunami. Internally, IBM was putting so many distributed 4300s out in departmental conference rooms that conference rooms became a scarce commodity. The big explosion in distributed 4300s also attracted the MVS group, they had the problem was that the only disks for non-datacenter were FBA and MVS never bothered with FBA support. Eventually they did come out with 3375, CKD simulated on FBA3370 ... however it didn't do much good, the distributed environment requirement was also for scores of 4300 systems per support person ... while MVS required scores of support people per system. some old 4300 email http://www.garlic.com/~lynn/lhwemail.html#4341 I also got sucked into doing early benchmarks (on engineering 4341) for LLNL that was looking at getting 70 for computer farm ... leading edge of the coming cluster supercomputers. single 4341 benchmarked faster than 370/158 and 3031 (in addition to clusters having better throughput and price/performance than 3033). past posts mentioning "RAIN" benchmark (objective was that it run approx. as fast as CDC6600) http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe? http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine? http://www.garlic.com/~lynn/2002b.html#0 Microcode? http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750) http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006y.html#21 moving on http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction http://www.garlic.com/~lynn/2009d.html#54 mainframe performance http://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source Apps http://www.garlic.com/~lynn/2009r.html#37 While watching Biography about Bill Gates on CNBC last Night http://www.garlic.com/~lynn/2011c.html#65 Comparing YOUR Computer with Supercomputers of the Past http://www.garlic.com/~lynn/2011d.html#40 IBM Watson's Ancestors: A Look at Supercomputers of the Past http://www.garlic.com/~lynn/2012n.html#45 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe? http://www.garlic.com/~lynn/2013.html#38 DEC/PDP minicomputers for business in 1968? http://www.garlic.com/~lynn/2013c.html#53 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2014c.html#61 I Must Have Been Dreaming (36-bit word needed for ballistics?) http://www.garlic.com/~lynn/2014j.html#37 History--computer performance comparison chart http://www.garlic.com/~lynn/2015h.html#71 Miniskirts and mainframes http://www.garlic.com/~lynn/2015h.html#106 DOS descendant still lives was Re: slight reprieve on the z http://www.garlic.com/~lynn/2016e.html#116 How the internet was invented http://www.garlic.com/~lynn/2016h.html#44 Resurrected! Paul Allen's tech team brings 50-year-old supercomputer back from the dead http://www.garlic.com/~lynn/2016h.html#49 Resurrected! Paul Allen's tech team brings 50-year -old supercomputer back from the dead http://www.garlic.com/~lynn/2016h.html#51 Resurrected! Paul Allen's tech team brings 50-year -old supercomputer
Re: GREAT presentation on the history of the mainframe
On Fri, Mar 24, 2017 at 2:44 PM, R.S.wrote: > W dniu 2017-03-24 o 18:04, Pommier, Rex pisze: > >> The only thing I wish he would have included in the presentation was the >> original 9672/9674 which was a huge shift from the GA-AS technology to >> silicon. >> > > I wish I hadn't worked on pre-9672 machines. > Was it really non-silicon? I was pretty sure it was silicon, but ECL, not > CMOS. > > BTW: > What about LPARs? > Yes. In "partitioned mode". > How HMC looked like? Was it PC-DOS-based? > No HMC. The console looked like a 3270 which was "built into" the machine. Older ones had _dials_ and _buttons_ and _LIGHTS_! Oh, how I miss the lights. > What about I/O cards? were they similar to cards available in 9672? > What OSA options were available? > No OSAs. Had to have an outboard controller on a regular byte multiplexer channel (not block or selector). > What about cryptoHW? > No co-processor cards. Unless you think of integrated channels as a co-processor, that is. > > -- > Radoslaw Skorupka > Lodz, Poland > > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
W dniu 2017-03-24 o 18:04, Pommier, Rex pisze: The only thing I wish he would have included in the presentation was the original 9672/9674 which was a huge shift from the GA-AS technology to silicon. I wish I hadn't worked on pre-9672 machines. Was it really non-silicon? I was pretty sure it was silicon, but ECL, not CMOS. BTW: What about LPARs? How HMC looked like? Was it PC-DOS-based? What about I/O cards? were they similar to cards available in 9672? What OSA options were available? What about cryptoHW? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
arno...@us.ibm.com (Todd Arnold) writes: > 360 processors with special microcode were used in a number of things. > Early in my career, I worked on development of the IBM 3890 high-speed > check sorter. (https://en.wikipedia.org/wiki/IBM_3890) The controller > in that sorter was a 360 mod 25, with all the code written in native > microcode - no 360 instruction set. It turned out to be very fast, > and it was many years before IBM was able to find anything to replace > that old mod 25 with its core memory. re: http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) nearly all 360s & 370s had integrated channels (engine was shared between simulating 360/370 instructions and running channel microcode) ... it was only the high-end machines that had dedicated external channles 360/65 & above, 165/168, etc. boeblingon got their hands slapped by corporate for the 370/115 & 370/125. The 370/115 had nine-position memory bus for microprocessors ... all identical ... one microprocessor was programmed for simulating 370 instructions and one or several other microprocessors programmed with controller microcode (i.e. not only integrated channels, but also integrated controllers). The 370/125 was identical to the 370/115 except the microprocessor running the 370 instruction simulation microcode was 50% faster (than the othere microprocessors). Very few customer 115/125 configurations had more than 2-3 controller microprocessors, so they suck me into doing a 5-way SMP multiprocessor design for 370/125 (I also do a bunch of enhancements including queued IO/interrupt akin to what is later seen with 370/xa, I also drop microcode queued interface for multiprocessing dispatching). Endicott also sucks me into do a lot of work on the microcode enhancements for 138/148. Endicott then complains tht the 5-way 370/125 SMP has better performance and better price/performance than 370/148 and I'm required in escalation meetings to argue both sides. Endicott wins ... and the 5-way SMP 370/125 is never announced. In the late 70s, there was an effort to replace the myriad of different internal microprocessors with 801/risc (Illiad) ... to simplify the enormous development & programming environments for each unique microprocessor ... aka the 4361&4381 followon to 4331&4341, the S/38, nearly every controller. etc. The followon to the displaywriter was also going to be 801/risc romp. In any case, all of these efforts floundered for various reasons. The channel latency processing of the 370/158 intergrated channels was much slower than the high end external channels ... characteristic which is then carried over to the whole 303x family (3031, 3032, 3033). An example was that even the 4341 integrated channel with minor tweak was able to handle the 3880/3380 3mbyte/sec speed (and could be used in bldg14&15 for 3880/3380 testing). trivia: 138/148 microcode enhancement. Typical 370 (vertical) microcode simulation ran avg. of ten native instructions for every 370 instruction. I was told that there was 6kbytes worth of available microcode space ... and the objective was identify the highest used 6kbytes of supervisor code for dropping into microcode for 10:1 speedup. old post that 6kbytes of kernel highest used pathlength accounted for 79.55% of kernel processing time (reduced to 8% when dropped into native microcode, 10:1 speedup) http://www.garlic.com/~lynn/94.html#21 other trivia: low was vertical microcode ... so those 360&370 machines were little like the Hercules simulation (and native MIP rate was ten times faster than 370 MIP rate). The high-end machines were horizontal micrcode ... and rather than measured in avg native instructions to 360/370 instructions ... high-end machines were measured in avg. machine cycles per 360/370 instructions (in part because of high level of hardware integration and overlap). Part of the move from 370/165 to 370/168 was replacing the 2mic memory with 400ns memory (cache miss latency reduced). The other part was optimizing the horizontal microcode reducing the avg. machine cycles from 2.1 to 1.6. 3033 started out with moving 168 logic to 20% faster chips ... but they also further optimized horizontal microcode getting down close to avg of one machine cycle per 370 instruction. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
The only thing I wish he would have included in the presentation was the original 9672/9674 which was a huge shift from the GA-AS technology to silicon. Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
I had thought that the 3890 check sorter used a S/3 CPU because of right-left movement (which those machines did). As I recall, with SCI code, one had to think the reverse of what a S/360 did in a move. Granted, I didn't do very much 3890 programming, but I did a lot of CPCS programming to handle various tasks and so had to be familiar with that and know that a 1419 check sorter (Read/Write direct thing) was a backup (never used it). Regards, Steve Thompson On 03/24/2017 09:51 AM, Todd Arnold wrote: 303x external channels (channel director) was 158 engine with integrated channel microcode (and no 370 microcode). 360 processors with special microcode were used in a number of things. Early in my career, I worked on development of the IBM 3890 high-speed check sorter. (https://en.wikipedia.org/wiki/IBM_3890) The controller in that sorter was a 360 mod 25, with all the code written in native microcode - no 360 instruction set. It turned out to be very fast, and it was many years before IBM was able to find anything to replace that old mod 25 with its core memory. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
> 303x external channels (channel director) was 158 engine with integrated > channel microcode (and no 370 microcode). 360 processors with special microcode were used in a number of things. Early in my career, I worked on development of the IBM 3890 high-speed check sorter. (https://en.wikipedia.org/wiki/IBM_3890) The controller in that sorter was a 360 mod 25, with all the code written in native microcode - no 360 instruction set. It turned out to be very fast, and it was many years before IBM was able to find anything to replace that old mod 25 with its core memory. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
Between 360 and 370 there was ACS/360 ... that was killed w/o ever being announced (executives thought it might advance state-of-the-art too fast and company might loose control of the market). note discussion that some of the ACS/360 features show up more than 20yrs later with es/9000 https://people.cs.clemson.edu/~mark/acs_end.html Old discussion about justification for all 370s moving to dynamic address translation. Problem was that MVT storage management was so bad, regions had to be four times larger than normally used (standard 370/165 1mbyte configurations only can practically run four regions). Moving to virtual memory, MVT could increase number regions by four times with little or no paging. http://www.garlic.com/~lynn/2011d.html#73 During Future System program (which was going to be completely different from 370 and going to replace 370) internal politics was killing off 370 efforts; the lack of 370 products during FS period is credited with giving clone processor makers a market foothold. With the death of FS, there was mad rush to get products back into the 370 pipeline. 3033 and 3081 were kicked off in parallel. some detailed references on FS, 3033, and 3081 http://www.jfsowa.com/computer/memo125.htm 303x external channels (channel director) was 158 engine with integrated channel microcode (and no 370 microcode). 3033 started out as 168-3 logic remapped to 20% faster chips. 3032 was 168-3 with new covers and using channel director. 3031 was 158 engine with just 370 microcode (and no integrated channel microcode) and 2nd 158 engine with integrated channel microcode (and no 370 microcode) ... a 3031MP was four 158 engines ... two dedicated for processors and two dedicated for channel directors. The head of POK also managed to convince corporate to kill off vm370 product, shutdown the vm370 development group and transfer all the people to POK (or otherwise they weren't going to be able to ship MVS/XA on time some 7-8yrs later). They weren't going to tell the vm370 until the very last minute to minimize the number of people that might escape. Somehow the information leaked early and number of the people managed to find other employment in the Boston area (joke that head of POK was one of the major contributors to the new DEC VAX/VMS project). Endicott did manage to save the vm370 product mission but had to reconstitute a development from scratch. During this period there was customer comments about VM370 code quality on VMSHARE http://vm.marist.edu/~vmshare There were some of the original VM370 that went to POK that did work on the tool virtual machine facility in support of MVS/XA development that was never intended to be made available to customers. Later when customers weren't migrating to MVS/XA as planned, there was decision to release the tool as the migration aid. As part of the tool, there was SIE (interpretive execution) microcode. SIE was never intended to be production performance, in part because there was insufficent room for the microcode, so it had to be swapped in and out. Old email discussion that for 3090 SIE was designed to be some real production operation (compared to 3081). http://www.garlic.com/~lynn/2006j.html#email810630 http://www.garlic.com/~lynn/2003j.html#email831118 old email about Amdahl's hypervisor, I had done a lot of work on Endicott's ECPS microcode assist and gave presentations on the implementation at monthly user group meetings. http://www.garlic.com/~lynn/94.html#21 Amdahl would talk to me about their hypervisor implementation http://www.garlic.com/~lynn/2006p.html#email801121 a number of yrs later IBM responds to hypervisor with PR/SM for 3090; 3090 announce 12Feb1985 https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html 3090 service processor (3092) was originally to be a 4331 running customized version of vm370 release 6 with all service screens done in CMS IOS3270. The service processor was then enhanced to a pair of redundant 4361s ... which also explains the requirement for pair of 3370 FBA devices (even for MVS customers, which has never supported FBA devices). CKD devices are still being required, even tho no real CKD devices have been made for decades ... simulated on industry standard fixed-block. Other trivia, original sql/relational (System/R) was done in bldg28 on vm370 370/145. The official followon new corporate DBMS was EAGLE. While company was preoccupied with EAGLE, was able to do technology transfer to Endicott for release as SQL/DS. When EAGLE finally implodes, a request is made about how long it would take to port to MVS which is eventually announced as DB2 ... originally for decision support only. Lots of history at the System/R reunion site http://www.mcjones.org/System_R/ initial release 1983 https://en.wikipedia.org/wiki/IBM_DB2 other trivia ... before ms/dos https://en.wikipedia.org/wiki/MS-DOS there was seattle computer https://en.wikipedia.org/wiki/Seattle_Computer_Products before seattle computer
Re: GREAT presentation on the history of the mainframe
Intel had an operating system (ISIS) and a language. I worked for a hardware startup and we used them. It was an embedded, bare-bones OS that could be burned into ROM, PROM or EPROM. I remember the language better, having struggled with it many a late night. It was called PL/M, programming language for microcomputers. Ha! You can find anything on Wikipedia: https://en.wikipedia.org/wiki/PL/M and https://en.wikipedia.org/wiki/ISIS_(operating_system) . (Did not realize it had been written by the late, great Gary K.) It had some quirks. ! (exclamation point) was the address-of operator, like & in C. Try spotting an extra or missing ! on a dot-matrix printer with a tired ribbon. 8-bit integers that were fundamentally unsigned but could be treated as signed. So you could say FOO=-1 but then (FOO < 0) would be false because fundamentally -1 was just a synonym for 255. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, March 23, 2017 4:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GREAT presentation on the history of the mainframe On Thu, 23 Mar 2017 02:27:32 +, scott Ford wrote: >One of my first sysprog jobs was on a 370-155 un-dated ..no dynamic >address translation ran Intel's DOS look-a-like. ITYM IBM Disk Operating System, which predated Intel by years. It is nothing like MSDOS. Did Intel ever have a DOS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On Wed, Mar 22, 2017 at 9:27 PM, scott Fordwrote: > Charles, > > One of my first sysprog jobs was on a 370-155 un-dated ..no dynamic address > translation ran Intel's DOS look-a-like. > Was that DOS/MVT (Software Pursuits)? https://books.google.com/books?id=P1x-hwc3_LcC=PA7=PA7=dos/mvt=bl=iKrEzIMXX5=W-VyQJs-Dd30FfQBssSFpx8c_NU=en=X=0ahUKEwjBle6Ez-zSAhUL5WMKHe3DAqgQ6AEILzAE#v=onepage=dos%2Fmvt=false WARNING! That is a blast from the past and may negatively impact your productivity today as you fade back into historic nostalgia. Adds for ADM-3A series terminals. TOPS-10 & TOPS-20 software. > > It was a wierd beast. > > Scott > > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
On Thu, 23 Mar 2017 02:27:32 +, scott Ford wrote: >One of my first sysprog jobs was on a 370-155 un-dated ..no dynamic address >translation ran Intel's DOS look-a-like. ITYM IBM Disk Operating System, which predated Intel by years. It is nothing like MSDOS. Did Intel ever have a DOS? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
Charles, One of my first sysprog jobs was on a 370-155 un-dated ..no dynamic address translation ran Intel's DOS look-a-like. It was a wierd beast. Scott On Wed, Mar 22, 2017 at 9:53 AM Charles Millswrote: > And it's not just a "nostalgia" presentation. I learned things I did not > know about the thinking inside IBM that led to the 360. And it goes all the > way through the EC12. Answered my question about Interlocked-Access > Facility 2. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > > Sent: Wednesday, March 22, 2017 5:59 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: GREAT presentation on the history of the mainframe > > > > Thanks for sharing Charles, like George my operations and systems > programming background is similar.. > > > > Learning BAL on a 360/20 did this while a Oprator on a 360/40 DOS/VS/POWER > Worked on 370/135 , 370/158 OS/VS2/HASP with TSO and TCAM Worked on 9000 > series on VM ans VSE On On > > > > Took me back..loved it > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
And it's not just a "nostalgia" presentation. I learned things I did not know about the thinking inside IBM that led to the 360. And it goes all the way through the EC12. Answered my question about Interlocked-Access Facility 2. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: Wednesday, March 22, 2017 5:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GREAT presentation on the history of the mainframe Thanks for sharing Charles, like George my operations and systems programming background is similar.. Learning BAL on a 360/20 did this while a Oprator on a 360/40 DOS/VS/POWER Worked on 370/135 , 370/158 OS/VS2/HASP with TSO and TCAM Worked on 9000 series on VM ans VSE On On Took me back..loved it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
Thanks for sharing Charles, like George my operations and systems programming background is similar.. Learning BAL on a 360/20 did this while a Oprator on a 360/40 DOS/VS/POWER Worked on 370/135 , 370/158 OS/VS2/HASP with TSO and TCAM Worked on 9000 series on VM ans VSE On On Took me back..loved it On Wed, Mar 22, 2017 at 6:59 AM George Rodriguez < george.rodrig...@palmbeachschools.org> wrote: > Awesome presentation! My first job coming out of school was at a service > > bureau and they had a 360/20 (used to print) 360/30 (most production ran > > there) and a 360/40 for testing new apps... This presentation took me back > > to those days! > > > > Thanks for sharing! > > > > > > *George Rodriguez* > > *Specialist II - IT Solutions* > > *IT Enterprise Applications* > > *PX - 47652* > > *(561) 357-7652 (office)* > > *(954) 415-7586 (mobile)* > > *School District of Palm Beach County* > > *3348 Forest Hill Blvd.* > > *Room B-251* > > *West Palm Beach, FL. 33406-5869* > > *Florida's Only A-Rated Urban District For Eight Consecutive Years* > > > > On Tue, Mar 21, 2017 at 9:40 PM, Edward Finnell < > > 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > > > > > When Dr. Rainey migrated to NIU from UT, Knoxville felt a sense of loss > > > never regained. Virtual paddle and all. > > > > > > > > > In a message dated 3/21/2017 4:54:35 P.M. Central Daylight Time, > > > charl...@mcn.org writes: > > > > > > Just happened to run into this while searching for one specific answer. > > > (What model gave us Interlocked-Access Facility 2? Answer: EC12) > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > -- > > > > > > *Disclaimer: *Under Florida law, e-mail addresses are public records. If > > you do not want your e-mail address released in response to a public > > records request, do not send electronic mail to this entity. Instead, > > contact this office by phone or in writing. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
Awesome presentation! My first job coming out of school was at a service bureau and they had a 360/20 (used to print) 360/30 (most production ran there) and a 360/40 for testing new apps... This presentation took me back to those days! Thanks for sharing! *George Rodriguez* *Specialist II - IT Solutions* *IT Enterprise Applications* *PX - 47652* *(561) 357-7652 (office)* *(954) 415-7586 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-251* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Eight Consecutive Years* On Tue, Mar 21, 2017 at 9:40 PM, Edward Finnell < 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > When Dr. Rainey migrated to NIU from UT, Knoxville felt a sense of loss > never regained. Virtual paddle and all. > > > In a message dated 3/21/2017 4:54:35 P.M. Central Daylight Time, > charl...@mcn.org writes: > > Just happened to run into this while searching for one specific answer. > (What model gave us Interlocked-Access Facility 2? Answer: EC12) > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *Disclaimer: *Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
When Dr. Rainey migrated to NIU from UT, Knoxville felt a sense of loss never regained. Virtual paddle and all. In a message dated 3/21/2017 4:54:35 P.M. Central Daylight Time, charl...@mcn.org writes: Just happened to run into this while searching for one specific answer. (What model gave us Interlocked-Access Facility 2? Answer: EC12) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN