> On Dec 21, 2017, at 12:33 PM, Seymour J Metz <[email protected]> wrote: > > I have a dispute at > <https://en.wikipedia.org/wiki/Talk:History_of_hard_disk_drives#Competing_devices > > <https://en.wikipedia.org/wiki/Talk:History_of_hard_disk_drives#Competing_devices>> > with another Wikipedia editor about the nature of the 3850, and would like > some feedback on who used it for what. Thanks. > >
Seymour: The unit for us was used to limit the floor space for DASD. I can’t give you the number of square feet it saved us, but we had a two floor DC, one floor was at first strictly tape and tape library and printers. Later on, 1/5th of the floor was another CPU. The 2nd floor was CPU’s and DASD and the 3850. The one bay of the computer room was all DASD (again no idea of square feet). The crowding of first 3330’s then the 3350’s was getting so tight IBM was grumbling about access to fix the drives. Management “tried” to get a unit that held 4 3350’s in one unit and if memory serves me it shared heads between the four 3350’s. We used to call it “the washing machine” as when it got busy the unit would almost walk across the floor (I do not remember the details too much as I was not in the know for a lot of the decisions. But I think when they were first installed they were used as temporary work disks, and that meant the heads were flying. After a couple of head crashes, we were told to put them as Data Base packs. I think that stopped the head crashes, but it slowed online response time, so we were told to find another use that wasn’t time sensitive, and we could not come up with anything appropriate. After much research, we decided that the tech support people would have to take the hit and we put a full pack DB that contained information on all IBM fix reports. When I used it, I noticed a slowness but enough to be annoying. Then when all of us were doing inquiries into the DB, it was SLOW, and we ended up talking to each other until the data appeared on the screens. We protested. We then put other files on it that were not were not time sensitive and then people were complaining how long their jobs also took we had more head crashes. Management finally got the hint and got rid of it. The 3850 came in, and it was long, I would guess at least 20 feet (maybe 24). Then came the staging drives (real 3350’s) I think 16 but could be wrong. At first, it worked like a charm but when we loaded it up it was slow. I do not remember how much of the dataset it preloaded; I have vague remembrances of trying different numbers (could be wrong here). The more we loaded up on the 3850 the slower it became. For batch it was probably acceptable (but we did hear some minor complaints from the users). What killed it for use was that on the MVS side the way allocation and how the 3850 worked were not all the compatible. For simplicity sake, MVS would wait when a disk (virtual) was dismounted and mounted causing any allocation to be put in a serialized “Que,” and it was single-threaded, so a tape drive mount was mixed into the disk mount/unmount of the 3850, causing everything to slow down. After so many system outages IBM finally realized that the allocation bottle-neck had to be rethought. That took about 6 or so months (I don’t know if this issue had hit other places as it did ours, but it did hurt us). The issue was a lot on how we chose to use it, example large sequential tape replacement would have worked. DASD replacement not so much if it was response sensitive. Ed > -- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
