[email protected] (Tom Marchant) writes: > The 3850 was much larger. When I was an Amdahl SE, one of > my accounts had one. It was probably 20 feet long, maybe > more. My impression was that it was a much improved version > of the 2321.
re: http://www.garlic.com/~lynn/2017k.html#44 Can anyone remember "drum" storage? http://www.garlic.com/~lynn/2017k.html#46 Can anyone remember "drum" storage? 2841 and Associated DASD ... 2311, 2302, 2303, 2321 http://www.bitsavers.com/pdf/ibm/28xx/2841/GA26-5988-7_2841_DASD_Component_Descr_Dec69.pdf more 2321 from IBM https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2321.html https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2321B.html even more 2321 https://en.wikipedia.org/wiki/IBM_2321_Data_Cell http://www.columbia.edu/cu/computinghistory/datacell.html magnetic stripes directly read/written when I was undergraduate in the 60s, I got hired fulltime to be responsible for IBM mainframe systems. The univ. library got an ONR grant https://en.wikipedia.org/wiki/Office_of_Naval_Research to do an online catalog. Part of the money went to getting a 2321. The project was also selected to be be betatest for original CICS product and I got tagged to support/debug the implementation. One troublesome "bug" to find was that CICS had (undocumented) hard-coded BDAM options for OPEN ... and the library was using files with different set of BDAM options. some past CICS &/or BDAM posts http://www.garlic.com/~lynn/submain.html#cics some more CICS history, gone 404, but lives on at wayback machine http://web.archive.org/web/20050409124902/http://www.yelavich.com/cicshist.htm 3850 from IBM https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3850.html https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3850b.html https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH3850A.html other 3850 https://en.wikipedia.org/wiki/IBM_3850 3850 automated tape library with 200mbyte tape cartridges for 3330-1 caching/staging hierarchy. virtual 3330-1 would be staged to/from a pool of 3330-1 drives (hardware HSM mount/unmount 3330-1 pack ... rather than files). Later they would support 3330-11 drives simulating two 3330-1 drives. Even later they would support 3350 drives simulating 3330-1 drives (could be considered experience for current situation where industry standard fixed-block disks are used to simulate CKD DASD, real CKD DASD hasn't been made for decades). from pg. 510 https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830509.pdf If the specific cylinder required by the CPU (1/404th of a Mass Storage Volume) is already on DASD, an I/O operation proceeds. If not, and data is being accessed, the MSC causes the cartridge containing the cylinder to be placed on a Data Recording Device (DRD), and the data contained in that cylinder to be transferred to the DASD staging buffer. ,,, If the Operating System knows which cylinders will be accessed, it can cause the MSC to stage only those cylinders containing the data set; reducing the number of times cartridges need to be accessed. ... snip ... aka a pool of real 3330 staging drives can be used to simulate a much larger number of "mounted" 3330 virtual packs. trivia topic drift. 1980, I had been con'ed into doing extended channel support for IBM STL (rename silicon valley lab, SVL) ... moving 300 people from IMS group to offsite bldg. recent (ibm-main) posts referencing effort http://www.garlic.com/~lynn/2017d.html#1 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017d.html#88 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017e.html#94 Migration off Mainframe to other platform http://www.garlic.com/~lynn/2017j.html#3 Somewhat Interesting Mainframe Article other posts http://www.garlic.com/~lynn/submisc.html#channel.extender 1985, I was considered IBM export on the vendors hardware used for the channel extender ... and the NCAR/UCAR IBM rep. tracked me down to help NCAR. NCAR had bunch of (non-IBM) supercomputers and 4381 implementing HSM function using some of the vendors hardware boxes (the vendor implemented their own channel protocol between their boxes). The 4381 would get supercomputer network request for file/data, it would stage the data (from tape) if required (to IBM DASD), and download a channel program (CCWs) into one of the vendor's A515 boxes ... and return the "handle" for that channel program to the requesting supercomputer. The supercomputer would then request that channel program to be executed, transfer the data to/from directly between supercomputer and IBM DASD. I've mentioned before a senior disk engineer getting talk scheduled at communication group conference where he said that the communication group was going to be responsible for the demise of the disk division (i.e. stranglehold on datacenters, not only hitting to disk division but significant contributing to driving IBM business into the red in the early 90s) recent (ibm-main) references http://www.garlic.com/~lynn/2017c.html#19 Check out Massive Amazon cloud service outage disrupts sites http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays major role in U.S. government breaches http://www.garlic.com/~lynn/2017d.html#42 What are mainframes http://www.garlic.com/~lynn/2017d.html#81 Mainframe operating systems? http://www.garlic.com/~lynn/2017d.html#82 Mainframe operating systems? http://www.garlic.com/~lynn/2017f.html#11 The Mainframe vs. the Server Farm: A Comparison http://www.garlic.com/~lynn/2017h.html#89 z14 and zBX http://www.garlic.com/~lynn/2017j.html#28 Db2! was: NODE.js for z/OS http://www.garlic.com/~lynn/2017k.html#34 Bad History http://www.garlic.com/~lynn/2017k.html#38 CMS style XMITMSG for Unix and other platforms The disk division had come up with various solutions to reverse the situation, but they were constantly being vetoed by the communication group. Later, disk division is adstar https://en.wikipedia.org/wiki/ADSTAR and senior ADSTAR executive is investing in startups that would use IBM disks (as a way of circumventing communication group vetos) ... and would have us in periodically, asking us to lend a hand to some of these efforts. One of the efforts was NCAR spinoff of its HSM implementation as "Mesa Archival". trivia reference https://spacefrontier.org/space-phoenix/ In addition to the Space Phoenix Program, the foundation is engaged in assisting UCAR with technology transfer and communication issues deriving from programs such as the "Airport of the Future" Doppler radar technology, which promises early warning of sudden atmospheric down-drafts (microbursts) near and over airport runways, and the commercial development by Mesa Archival Systems, Inc. of mass data file transfer software for supercomputers. ... snip ... Implementation was upgraded to HIPPI channel https://en.wikipedia.org/wiki/HIPPI with "3rd party" transfers ... the channel program executed directly by the HSM server, but using HIPPI "3rd party" transfers to transfer data to/from the disk and the client. Part of the work then for fibre-channel standard was also support "3rd party" transfers for HSM implementations ... beginning to morph into network attached storage https://en.wikipedia.org/wiki/Network-attached_storage and storage area network https://en.wikipedia.org/wiki/Storage_area_network posts referencing communication group dumb terminal paradigm, including references to communication group stranglehold on datacenters and going to be responsible for demise of disk division http://www.garlic.com/~lynn/subnetwork.html#terminal -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
