Post by Tom MarchantThe 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN