Talk:History of IBM magnetic disk drives

Winchester Blvd
It was my (admittedly undocumented) impression that the Winchester Disk was named not for the Winchester Rifle, but for the location of the IBM office on Winchester Blvd in San Jose. Perhaps this is an urban legend but I recall hearing it many years ago. Jim Bowery 23:35, 19 September 2006 (UTC)


 * Added IBM source to article. 30-30 must be a Winchester [rifle] tooold (talk) 06:35, 21 January 2009 (UTC)


 * The folklore I've heard is that the technology was named Winchester after the rifle, because the team was working on dual 30 MB drives (30+30 MB), hence the "30-30" connection with the rifle. — Loadmaster (talk) 01:09, 22 March 2013 (UTC)
 * Ken Haughton code named it Winchester for the rifle because the program was initially two thirty MB spindles in a box, called "30 - 30" by some. See his oral history, p.9. Tom94022 (talk) 05:32, 22 March 2013 (UTC)

The folklore about Winchester road name was widespread in the years I worked at the San Jose plant. This may be a case where a name was suggested and multiple reasons were found to sustain it.HiTechHiTouch (talk) 01:27, 3 March 2016 (UTC)

Note that these two lines of folklore are connected. Winchester Blvd was named for Winchester House, which was built by Sarah Winchester, who inherited 50% of the Winchester Repeating Arms Company, inventor of the .30-30 Winchester center fire cartridge. 02:58, 3 March 2016 (UTC)


 * The source of the urban legend about the boulevard is not known, but it is clear from Haughton that the name came from the rifle. Given the bredth of the urban legend it might be worth an in-line note in the article debunking it.  Tom94022 (talk) 18:37, 3 March 2016 (UTC)

Sizes
Drive sizes are listed as "decimal digits" and "characters". What are they in bytes or bits or octets? - Omegatron 15:41, May 13, 2005 (UTC)

And make sure to remember the difference between megabytes and mebibytes.


 * decimal digits were either 4 or 5 bits plus 1 parity bit; characters were either 6 (BCDIC) or 8 (EBCDIC) bits plus 1 parity bit. -- 205.175.225.5 00:23, 18 March 2006 (UTC)

Number of platters
I used to work with these things and I'm fairly sure they had six platters not five. However the top surface of the top platter and the bottom surface of the bottom platter were not used so there were ten surfaces coated with the magnetic material, giving ten tracks per cylinder. The reason the outside surfaces were not used is that they were liable to be touched when the disk was removed from its drive. In fact operators would place their hands on the top surface to slow them down. This led at least one manufacturer to coat the top with abrasive.

Here is a photograph of the disk which shows six platters. If anything this one is even clearer. Is this enough proof to merit editing the article? --R Cornwell 13:20, 4 May 2006 (UTC)
 * I fixed it under 2311. The section on the 1311 had it right. --agr 19:11, 4 May 2006 (UTC)

3380
IBM 3380 redirects here, but this article doesn't say anything about it. A netnews article I read suggests that there are still some in operation. 121a0012 19:06, 5 May 2006 (UTC)
 * Thanks, I've added some info.--agr 00:07, 11 May 2006 (UTC)

Tub file?
I'm not sure what is meant by "the punch card tub file used by most businesses of the time." Please elaborate.--agr 03:24, 20 September 2006 (UTC)

2311 rememberances
The shop where I got my first operators job had a string of 4 2311s and here is what I remember about them.

One of the previous posts mentioned operators slowing them down with their hands. There were really 2 parts to a 2311, and all the disks until Winchester. There was the drive that contained the electronics, drive motors, and heads. There was also the disk pack. Storage was so expensive, thousands of dollars for one 7MB drive, that nobody thought of having all their data online and it was not necessary since everything was batch jobs. So, you would have a pack for your payroll files, one for the GL, etc. When you ran a job you would have to mount the packs that contained the data.

Push the stop button and the drive would spin down but this took forever and who has the time? When you opened the lid there was something that engaged to prevent the disk from turning. If you just opened the top on a spinning disk this would take some damage so that was out. If you just opened the top a little you could reach up under it and get your fingers on the top platter and slow it down. I don't think lawyers to sue had been invented yet.

Once it sopped you opened the top and took the top of the case, a clear plastic tub with a handle on the top, put it over the disk. Spinning the top would attach it to the top of the disk and detach the disk from the drive. You lifted it up and stuck the bottom on to keep some of the crud out.

I don't see how any PC person can conceive of the size of one of these things. The pack was about 16 inches in diameter by about 6 inches high. In this massive area the drive could write 100 or 200 tracks (I think the 2311 had 100 and the 2314 had 200. the 2314 also doubled the number of platters) In fact when you were doing a backup of the drive you could tell how far you had gotten by going over to the drive and looking down through the glass top. The arm holding the heads came straight out from the side and on to of it was a scale with the tracks marked. You could literally look down and see what track you were up to.

Now, everybody knows that the heads are moved by that nice clean voice coil. Not the 2311s. They were hydraulic. Nice little pump, hoses, pistons, etc. In fact one of our 2311s had a small leak and when the CE came in to do preventative maintenance (There was so much mechanical stuff associated with a computer that every week the guy form IBM came and spend a few hours trying to fix things before they broke.) he would get a hand full of the little bits from the card punch and literally put them inside the disk drive to soak up the oil. —The preceding unsigned comment was added by P7willm (talk • contribs) 15:49, 22 March 2007 (UTC).

Jan 14 2014 I worked on the 2311, 3330, and 3380 disk drives as an IBM CE. The hydraulics in the 2311 were always leaking. I used to calim the drive would not work if there was no hydraulic oil in the base. When you removed the cover of the hydraulic unit there was another cover inside that covered the hydraulic pistons. To replace one of the pistons or make adjustments you had to remove that cover. If you forgot to put it back on, and you manually actuated the hydraulic unit it would squirt oil several feet into the air, then you had a real mess to clean up.

William H. — Preceding unsigned comment added by 75.163.186.25 (talk) 00:56, 15 January 2014 (UTC)

Great memories! That time is completely different from what's currently perceived by an average "PC era" user... While nowadays you can buy a quite reliable 1 TB HDD for peanuts (when compared to those old storage prices), I don't think people became much smarter and more productive, especially not as many times as storage technology advanced. &mdash; Dsimic (talk) 00:04, 16 January 2014 (UTC)

I was in the Army in 1976 and one of my duties was carrying platters that had gone bad from the Pentagon to a Navy facility to get the platters degaussed by a big magnet. Those platters are big and heavy. Sam Tomato (talk) 00:40, 14 September 2021 (UTC)

The floppy disk
This text "Another important IBM innovation was little noticed when it was introduced initially with the System 360, in the 2835 Storage Control for the 2305 Drums, to be attached to the high end processor models 2075 and 2095. Then it became more popular with introduction of the System/370 in 1971. IBM needed a way to load new microcode into the IBM Storage Control Units 2835 and 3830, and into the IBM System/370 Model 155 and developed the 23FD floppy disk 'read only' for this purpose."

needs help. The first two "it"s are unknown references, other than "important IBM innovation". The text begins with the 2835, advances the time with "Then it became" to describe the System/370, then writes about both "2835... and 370 model 155" as if the two were at the same time.

Suggest saying first what the innovation is, followed by implementations sequenced by time.tooold (talk) 05:33, 21 January 2009 (UTC)
 * The subject is well covered in other articles, so I shortened the section to the bare minimum and linked to the most appropriate article/section. Tom94022 (talk) 06:17, 21 January 2009 (UTC)

Scope
The article is about Early disk storage. "Early" is a relative term. Regardless of what it means, it should be used consistently. The article mentions that IBM sold its disk operations to Hitachi in 2002. It discusses 3.5 inch HDDs as of 2004. However, it leaves out RAMAC Virtual arrays. The RAMAC introduced in 1989, unrelated to the original RAMAC, used 3.5 inch RAID 5 arrays, 5 drives per drawer. One of the drawers was a dynamic spare. Each unit held up to 90GB when all other drawers were populated. It had a built in controller that connected to up to 4 fiber optic channels. It had three levels of cache: drive level, drawer level, and unit level. It used algorithms to pre-cache based on areas of disk likely to be read.

It emulated 3380 or 3390 drives (and 3880/3990 controllers), and although systems programmers continued to allocate space at the "physical" level, it was truly virtual. In case of a drive failure, it would "phone home" to IBM, and start migrating to the spare drawer, optimizing performance for ongoing operations. IBM maintenance staff could hot swap drives, literally creating situations where computer room staff was unaware that anything had failed, and no noticeable degradation in performance had occurred. These were somewhere in the million dollar range, but the savings in floor space, energy and monthly maintenance made them competitive with older existing 3380 and 3390 drives.

Anybody who had to restore a mainframe after a failed 3380 can appreciate the importance of this alone, not to mention the performance gain. However, I mention all of this because even if you don't consider this "early," it predates the 2002 period mentioned as the end of the era. It also serves as a basis to compare 33xx technology to 3.5 inch drives, since these were the ones that were direct replacements for "early" technology, not the 2004 3.5 inch drives mentioned in the article.

It makes no sense to end things at 2002, and consider 2004 a fair point for comparison. If 2002 3.5 inch drives were to be used for comparison, the fastest of which were used in the latest generation of RAMAC, they not only could be used as a starting point for the "raw" comparison, but could more accurately reflect the true performance edge that they gave to mainframes compared to the "early" drives that they replaced.

--Hagrinas (talk) 17:48, 18 May 2009 (UTC)


 * I agree that the ending is inappropriate, my choice would be to end with the 3390 which is the end of IBM's mainframe line of disk drives, sometimes called SLEDs (Single Large Expensive Disks). After the 3390 the IBM world went to arrays of which RAMAC is just one of many so I would not add in the RAMAC Array or for that matter any other subsystem product to this article.  Probably the article should be renamed IBM Mainframe Disk Drives (the 3370 would then be dropped). A separate article on storage subsystems would be the appropriate place for the RAMAC and its ilk.  Any other thoughts Tom94022 (talk) 23:13, 18 May 2009 (UTC)


 * I think the scope should be the history of IBM disk drives up to the beginning of the PC/RAID era. I have no problem adding 3390 (the physical/virtual stuff is very interesting) and I would end with a mention of the new RAMAC and IBM and the market's switch to RAID technology, referencing the RAID article as the main article. I would still include a comparison to consumer grade disks because the extent of progress, while keeping the same basic architecture introduced in the the 1405, is so dramatic, perhaps unequalled in human history. However, I would not limit the article to mainframe disks. IBM did not make that distinction through the 1960's. Indeed, the RAMAC 305 was a midsized machine, as were the 650 and 1401.  IBM 1311's were sold with the 1620, a low end machine; while the earliest use of the floppy was to load microcode on 360s that were mainframes. Early IBM mainframe installations (700 - 7000 series) generally did not include disk drives; they were too small (in capacity) and too slow to be of much use in most commercial mainframe shops, and their potential was not recognized in scientific shops (IBM operating systems did not include file management). Tape ruled. There are so few IBM pre-PC drives that were exclusively for small machines, e.g. the 2315, that I see no need to exclude them. --agr (talk) 11:33, 28 May 2009 (UTC)


 * I don't want to get into a semantics debate, but all those early computers are mainframes, small, large, scientific, commercial, etc - at least that's what the US government alleged in the anti trust suit. IMO the computer industry and the disk drive industry first changed with the emergence of the mini-computers.  Since most of the disk drives in the article were only offered on IBM mainframes and IBM was very successful in these mainframe SLEDs, I'd rather limit the scope to what's there, enhance it and focus on IBMs successes with its SLEDs rather than bring in all the extraneous stuff about low end drives, where IBM was less than successful. I suppose I could retitle the article IBM SLED History (Single Large Expensive Disk Drives) :-)
 * I believe you are very mistaken about the low end of IBMs disk drive family both as to number of products and their relative production quantity (the first disk drive product line to exceed 100,000 units was the CDC SMD circa 1981 and that took 7 years, today a volume product does that in three days). Off the top of my head, the low end IBM disk drive line included the 2315, 5444, 3370, 62GV, G2PC, 681, Sawmill and others.  The 2315 and 5444 class drives were used by all mini's in the early 70s, but most were made by other than IBM.  And I bet the IBM 1130 outsold most if not all S/360's.
 * The PC era starts in 1983 while the RAID era for IBM mainframes starts in either 1991 with EMC or 1994 with the RAMAC, so I am unclear as to when you would end it. BTW, the first IBM RAID was the IBM 9337 in 1992 for the AS/400 a mini, not a mainframe.
 * So without agreement on scope, I guess the article stays as is :-( Tom94022 (talk) 20:01, 28 May 2009 (UTC)

stellar?
Please tell me in plain English for non-native people, what means the following saying in the introduction: a stellar improvement. Does it mean 'great improvement' or 'fast improvement'? --Sibazyun (talk) 07:35, 13 September 2009 (UTC)
 * It's gone, see if what i wrote makes more sense. Tom94022 (talk) 22:26, 13 September 2009 (UTC)
 * Thank you for the new saying. --Sibazyun (talk) 23:04, 14 September 2009 (UTC)

Name versus scope
If this article is intended to just be about early disk drives, then the material on the 2321 Data Cell doesn't belong in it. If it is intended to be a general article on early IBM DASD, then the 3850 and half a dozen drums, e.g., 7320, 2301, 2303, need to be added and the name changed.

As a side note, there were a few abortive disk drive on the IBM 1400 and IBM 7000 series that were based on the 350 and displaced by the 1301 and 1311. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:09, 17 June 2010 (UTC)


 * I agree the article's name and scope are inconsistent, see 8. Scope discussion above. The 2321 should be dropped and there should be a cut off related to "early".  I proposed renaming the article to IBM Mainframe Disk Drives, which is mainly what is currently covered but didn't get a lot of buy in.  The cut off would be the 3390.   FWIW, aren't the "abortive disk drives" the 353, and 355 discussed in the article?  If not, why not add them? Tom94022 (talk) 04:16, 18 June 2010 (UTC)


 * I'd read 8. Scope, but it seemed to relate only to dates, not to type of DASD covered.
 * 8. Scope points out the absence of many small disk drives which is definitely a scope issue. So what do you want to do, expand the mis-named "Early" article or rename and focus it on what it really covers that is mainframe (SLED) disk drives or ? Tom94022 (talk) 18:00, 18 June 2010 (UTC)
 * There's more than one scope issue; the one that I was concerned with was whether the article should cover only disk drives. If you want it to cover all types of DASD then I can give you references on, e.g., the 3850 Mass Storage system (MSS), but I don't have anything on the early drums.
 * The article is about Disk Drives not DASD, the question is how to we fix this article given its content exceeds its title, its scope is incomplete and the time covered is inconsistent with "early" Tom94022 (talk) 00:32, 19 June 2010 (UTC)


 * Removing the 2321 and adding the 7300 would address the issues that I was concerned with. As for your issue, is it possible to arrive at a consensus on what the cutoff is for early?


 * Perhaps the article should be split into articles covering early and later disks? Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:02, 20 June 2010 (UTC)


 * I don't consider the 353 and 355 to be abortive; I was referring to, e.g., the 1405, the 7300. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 18 June 2010 (UTC)
 * The 1405 is in the article. I am looking into the 7300 and will add it when done - FWIW, it appears to be a rebadged 355. Tom94022 (talk) 18:00, 18 June 2010 (UTC)
 * I believe that both the 1405 and 7300 were rebadged 355's, and that the announcements of the 1301 and 1311 rendered both the 1405 and 7300 noncompetitive. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:20, 18 June 2010 (UTC)

Here is my proposal. Rename this article to:
 * IBM MAGNETIC DISK DRIVES with the following sections
 * Early IBM Disk Drives - Every drive in the article prior to System/360 using Pugh's "IBM's Early Computers" as a basis
 * IBM Mainframe Disk Drives - the SLEDs 2302 thru 3390
 * IBM Small Systems Disk Drives - 2310, 5540, 62GC, 62PC, etc
 * IBM OEM Disk Drives - needs work, links to DeskStar
 * IBM Floppy Disk Drives - probably just a few words and a link to Floppy disks
 * Retrospective - IBM's exit from the HDD business and a comparison between RAMAC and their last disk drive
 * See also, etc.

I used "Magnetic" in the article title to avoid having to add the various Optical disk drives that IBM OEM'ed from other suppliers. Comments and/or suggestions Tom94022 (talk) 19:30, 20 June 2010 (UTC)
 * Redirect Early_IBM_disk_storage to Section 1 of IBM MAGNETIC DISK DRIVES, as above.
 * Move IBM 2321 Data Cell to its own article


 * If the title drops the word early, shouldn't the IBM Mainframe Disk Drives section of the article be expanded to include magnetic disk drives beyond the 3330, e.g., RAMAC Virtual Array (yes, they recycled the name)? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:17, 1 July 2010 (UTC)
 * I don't think any subsystem or storage control unit belongs in an article with the term "disk drive" in the title. They are not in the current article and need not be in the retitled article.  The topic of subsystems in general and IBM in specific is interesting and could be a separate article.  You might want to take a look at the Computer History Museum's Storage Subsystems site for one approach.  Tom94022 (talk) 19:04, 1 July 2010 (UTC)


 * Then perhaps the alternate title should be IBM disk storage. Or perhaps the article should be split into separate drive and storage articles. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:17, 1 July 2010 (UTC)


 * This is a drive article as written so there is nothing to split away. All I am proposing is correct the title and expand the coverage to all IBM disk drives.  The problem with IBM disk storage is both the ambiguity between devices and subsystems and the inclusion of optical. The proposed title avoids both problems.  If you want to write an article on DASD subystems, that would be great.  It is a different article. Tom94022 (talk) 20:26, 1 July 2010 (UTC)
 * OK, Please get off this site Tom. You are everywhere I go. Why must you insist you change articles? 209.188.60.49 (talk) 02:37, 14 July 2010 (UTC)


 * I am taking the absence of discussion as consensus to go ahead and rename and restructure this article. My draft sandbox is at IBM magnetic disk drives. Right now I am struggling with organizing the disk drives of the 1980s that were both internal to IBM small systems and sometimes offered as an OEM drive.  The common thread is only the internal code name, e.g. Piccolo was variously the 62PC (internal number), 0680 (OEM), 3310 (low end 370), 4963 (Series/1), 5430 (System/34), 5381 (System/38) and with the 8100 processing unit.  As soon as I figure out a structure that makes sense I will finish the sandbox and then rename and reorganize this article.  Any suggestions?  Tom94022 (talk) 22:55, 5 April 2011 (UTC)


 * Not so fast. I think there is value on focusing on the early IBM drives as they pioneered modern mass storage. I would prefer a separate article on more modern IBM mass storage. System 390 might be a good dividing line.--agr (talk) 02:38, 8 April 2011 (UTC)


 * First of all this is not fast - the discussion was first posted almost a year ago. My work is responsive to the then posted comments.
 * Your System/390 proposed cut off of 1990 is not much different than my "Star" series cutoff of 1994, so it appears that your objection boils down to changing the article title. Early is rather subjective, personally I think anything prior to S/360 is early.  Disk storage is broader than just magnetic disk, leaving out all optical disk.  So the title needs to be changed.  The proposed revisions fixes the title, adds many of the missing magnetic disk storage and cuts off when IBM switched from designing principally for its customers to designing principally for OEMs.  Nothing is lost from the article and a lot of content is added.  After I move the article I will redirect the current title into the subsection of the new article, Early IBM HDDs.  If you have a better new title, I'd love to hear of it.  If you have specific comments about the content I am proposing to add, please take a look at my sandbox; you can comment there or here.  I see no reason to not go ahead - do u?  Tom94022 (talk) 20:24, 11 April 2011 (UTC)

If the article is intended to be solely about magnetic disk drives, then it should split so as to not include either the 2301 or the 2303. If they are to stay then the article should be moved to a new title and updated with, e.g., 7320, 2321, 3850. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:21, 18 April 2021 (UTC)
 * Possibly right. I though about that when adding the drum devices, but they’re not worth an article by themselves, and they don’t fit anywhere else either. I’d support renaming the article. Peter Flass (talk) 20:56, 18 April 2021 (UTC)
 * This is a very old and stable article. Magnetic disk includes HDD and FDD but precludes optical and some tape. DASD adds other technologies but leaves out FDD. Most readers will see an equivalence between "magnetic disk drives" and the more common HDD.  For these reasons I do not support renaming the article so the 2301 and 2303 should be removed to their own article. Unfortunately as storage, they don't fit into the Drum Memory article although maybe some clever wordsmithing would make them fit.Tom94022 (talk) 23:50, 18 April 2021 (UTC)
 * ITYM Drum memory; lower case M. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:46, 19 April 2021 (UTC)
 * If the drum information stays then there should also be text describing the 733 for the 704 and for the 709. AFAIK the drum on the 650 doesn't have a separate model number but is just part of the 650 Console Unit. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:46, 19 April 2021 (UTC)
 * Note the UNIVAC FASTRAND, a drum, has its own article. I suggest an article on IBM Drum Storage could be appropriate for all such IBM products. If someone wants to be aggressive an article on Drum storage might work or renaming Drum memory to "Drum memory and storage" would work too. Or maybe even just redirect "Drum storage" to Drum memory and expand its scope.  Lots of belter alternatives to changing the scope of this article.  Tom94022 (talk) 02:51, 19 April 2021 (UTC)
 * The Drum memory article already has this statement "Some drum memories were also used as secondary storage." I suggest adding drums used as storage into the Drum memory article with a redirect from "Drum storage" is the best solution.  Editors can then add other storage drums as it appears appropriate.  Tom94022 (talk) 02:57, 19 April 2021 (UTC)
 * Seems to me that IBM calls them DASD just so that this distinction isn't a problem. It the article was meant to be more general than IBM, then things might be different. WP:COMMONNAME says: the term or name most typically used in reliable sources is generally preferred. If those sources are IBM manuals, then they will say DASD. I am not sure how many non-IBM sources do it when mentioning IBM devices. Otherwise it would seem consistent to name it History of IBM magnetic disk drives and drums, with redirects from the current name and History of IBM direct address storage devices. (I am not sure of the right capitalization.)
 * Don't forget that the 2321 data cell and the 3850 Mass Storage System (MSS) are also DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 06:30, 19 April 2021 (UTC)
 * Definitely the 2321. For the 3850, it might only be the staging drives, which are the ones that are direct(ly) accessed. What unit number is used with MSS? (And reminding me that I don't think that there is an emulation of the 3850 yet.) Gah4 (talk) 12:54, 19 April 2021 (UTC)
 * The Mass Storage Facility (MSF) has one pool of addresses for virtual drives and a separate pool of addresses for real, staging and convertible drives. The Mass Storage Control (MSC) manages the staging and destaging of 8 cylinder pages, a cylinder at a time, between cartridges and staging drives, transparently to the OS. To a first approximation, a 3330V looks like a real 3330-1, even if the staging drives are 3330-11 or 3350. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:13, 19 April 2021 (UTC)
 * DASD was not used by IBM to describe all of its magnetic disk drive products (i.e. pre-S/360 disc storage, many OEM HDDs, FDDs and all the Star series HDDs were never labeled DASD by IBM) This article is complete and consistent and has been for a long time; the term "magnetic disk drive" is far more common and understood than DASD. To turn it into a history of IBM DASD would break it apart for no good reason and create some strange inconsistencies. If an editor feels the need for a list of IBM DASD article it can link to those DASD in this article as necessary along with other DASD, not HDD,  such as the 2321.  In summary, at different times IBM called some of its magnetic disk drives it manufactured using the terms, disc storage, DASD, FDD or HDD.  The fact that some other technologies were also called DASD by IBM is no justification to split this article.  Furthermore, magnetic disk drive, FDD and HDD are the terms in much more common usages than DASD and therefore is a better subject for this article.  Tom94022 (talk) 23:03, 19 April 2021 (UTC)
 * Definitely the 2321. For the 3850, it might only be the staging drives, which are the ones that are direct(ly) accessed. What unit number is used with MSS? (And reminding me that I don't think that there is an emulation of the 3850 yet.) Gah4 (talk) 12:54, 19 April 2021 (UTC)
 * The Mass Storage Facility (MSF) has one pool of addresses for virtual drives and a separate pool of addresses for real, staging and convertible drives. The Mass Storage Control (MSC) manages the staging and destaging of 8 cylinder pages, a cylinder at a time, between cartridges and staging drives, transparently to the OS. To a first approximation, a 3330V looks like a real 3330-1, even if the staging drives are 3330-11 or 3350. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:13, 19 April 2021 (UTC)
 * DASD was not used by IBM to describe all of its magnetic disk drive products (i.e. pre-S/360 disc storage, many OEM HDDs, FDDs and all the Star series HDDs were never labeled DASD by IBM) This article is complete and consistent and has been for a long time; the term "magnetic disk drive" is far more common and understood than DASD. To turn it into a history of IBM DASD would break it apart for no good reason and create some strange inconsistencies. If an editor feels the need for a list of IBM DASD article it can link to those DASD in this article as necessary along with other DASD, not HDD,  such as the 2321.  In summary, at different times IBM called some of its magnetic disk drives it manufactured using the terms, disc storage, DASD, FDD or HDD.  The fact that some other technologies were also called DASD by IBM is no justification to split this article.  Furthermore, magnetic disk drive, FDD and HDD are the terms in much more common usages than DASD and therefore is a better subject for this article.  Tom94022 (talk) 23:03, 19 April 2021 (UTC)
 * DASD was not used by IBM to describe all of its magnetic disk drive products (i.e. pre-S/360 disc storage, many OEM HDDs, FDDs and all the Star series HDDs were never labeled DASD by IBM) This article is complete and consistent and has been for a long time; the term "magnetic disk drive" is far more common and understood than DASD. To turn it into a history of IBM DASD would break it apart for no good reason and create some strange inconsistencies. If an editor feels the need for a list of IBM DASD article it can link to those DASD in this article as necessary along with other DASD, not HDD,  such as the 2321.  In summary, at different times IBM called some of its magnetic disk drives it manufactured using the terms, disc storage, DASD, FDD or HDD.  The fact that some other technologies were also called DASD by IBM is no justification to split this article.  Furthermore, magnetic disk drive, FDD and HDD are the terms in much more common usages than DASD and therefore is a better subject for this article.  Tom94022 (talk) 23:03, 19 April 2021 (UTC)

2305 as paging device of choice
I looked for but could not find any evidence to support the statement that the 2305 was the paging device "of choice" on any system. The IBM 2305 site does NOT mention this at all, but instead talks about it providing "greater data-handling power for database applications and batch processing. It was initially used on two large System/360 processors, the Model 85 and Model 195, and later used with the System/370 Model 155 and Model 165." It like most DASD was supported as a paging device under VM and other OSes but just another, albeit for a while fastest, DASD. In the absence of evidence, I suggest we strike the sentence. Tom94022 (talk) 05:39, 18 December 2010 (UTC)
 * Change made Tom94022 (talk) 00:32, 12 April 2011 (UTC)


 * A google search shows multiple references to IBM manuals referring to the 2305 as a high performance paging device. The hardware reference manuals are not the proper place to determine support or usage. Please reinstate the text. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:21, 3 August 2011 (UTC)


 * I searched IBM "high performance paging device" and got nothing to support the claim; ditto for IBM "paging device." I do not dispute that at its time the 2305 was a "high performance paging device" even "the highest" but I have seen no evidence that it was "of choice" for any system.  So please give some references that support such a claim.  BTW, depending upon the page space the fixed head feature on the 3350 may have become a better choice. Tom94022 (talk) 17:34, 4 August 2011 (UTC)


 * Computer History


 * The fixed-head area of a 3350 was not useful for paging because access to it would be delayed by I/O to other areas of the disk. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:59, 15 August 2011 (UTC)


 * It was initially used on two large System/360 processors, the Model 85 and Model 195, and later used with the System/370 Models 155/158 and Models 165/168, then on the model 3033." It was supported as a paging device under VM and other OSes for large mainframes, and was the fastest DASD.


 * The 2305 was also in use on the later 3081 Extended Architecture processors (announced on November 12, 1980, with the use of a re-developed microcode on its controller, the 2835.)


 * The 2305/2835 facility was the device of choice for paging and extra fast access to records, starting on the System 360 models 85 and 95
 * and continued on all large Models for System 370 and 380, well into the late 1980's.IgnacioM (talk) 21:23, 1 September 2014 (UTC)


 * The IBM 2305 "high performance paging device" was the choice for all large IBM mainframe systems, due to its fixed head design (having in effect zero 'seek access time'), Rotational Position Sensing (RPS), and Multiple Exposures, which allow it to minimize 'latency' and providing the requested data records in a very efficient manner.


 * Benchmarks show that the RPS and Multiple Request features provided an improved 16x factor to existing DASD's latency delay, and a much faster access due to zero seek time, compared to the other DASD using actuators to position the R/W heads. IgnacioM (IBM Microcoder) — Preceding unsigned comment added by IgnacioM (talk • contribs) 21:23, 1 September 2014 (UTC)


 * The SLAC 370/168's each had a 2305 for paging. I never asked about any other systems at the time, though expect that SLAC wasn't the only place using them. It might be that they were the paging device of choice on 168's, but not other systems. Gah4 (talk) 07:55, 14 August 2017 (UTC)


 * At the Technion we used a 2305-2 for SYS1.SYSJOBQE on a 370/165, later upgraded to a 370/168, and for PLPA when we converted to SVS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:12, 14 August 2017 (UTC)

Moving this page again
The page discusses all IBM magnetic disk drives and no Optical disk drives or other DASD devices. As such the title is accurate and should not be changed to encompass all disk storage or all storage unless there is a commitment on the part of the editor to expand the article accordingly. Actually it should not have been moved peremptorily in the first place, but now that it is accurately titled I hope there will be some discussion before any move. Tom94022 (talk) 20:24, 29 July 2011 (UTC)

2310
I had added a sentence about the 2310 being a standard feature on the 360/44, which a subsequent editor removed as being "too much information." Rethinking this, I see that the 2310 is listed under "HDDs offered only on IBM small systems," so I believe my update was relevant. Rather than just re-add it, I'd like to ask for other opinions. Peter Flass (talk) 13:13, 14 February 2012 (UTC)
 * I agree it's an important detail that belongs in the section.--agr (talk)


 * I disagree. For the most part in this article we do not mention any system model usage beyond the first to introduce an embedded HDD.  The 360/44 was well after the introduction of the 2310.  Furthermore it was a special scientific computer not really a part of the S/360 mainframe line so I am not sure we even need to change the section title but I suppose we should consider that.  Tom94022 (talk) 23:05, 14 February 2012 (UTC)


 * The IBM System/360 model 44 featured a special disk drive that accepted the IBM 2315 cartridge, but formatted it differently than the IBM 2310. I added some text about this drive. 05:50, 8 March 2012 (UTC)  — Preceding unsigned comment added by John Sauter (talk • contribs)


 * I reverted the text, see next section in this talk. I would point out that the formatting is a function of the disk controller and has little to do with the drive itself.  As near as I know the S/360 M44 drive was a 2310.  Tom94022 (talk) 20:02, 8 March 2012 (UTC)

S/360 M44 Disk Drive
Many disk drives were either bundled with or attached to IBM systems and we have not identified them separately as such herein. This is particularly true in the later years and on small systems. The drive used on the S/360 M44 was a 2310 so for consistency it should not be listed separately just as we do not list separately the various system usages of the 667. 669, 681, etc. Tom94022 (talk) 20:00, 8 March 2012 (UTC)


 * But note that the integrated drive on the System/360 model 44 formatted the cartridge in a different way than did the IBM 2310. The article includes the IBM 2302, which differed from the IBM 1302 only in formatting (according to the article).  It could be argued that the IBM 2302 is particularly notable because of its use on System/360, but I could also argue that the integrated drive on the System/360 model 44 is particularly notable because it represents IBM's first use of Fixed Block Architecture on System/360. John Sauter (talk) 13:29, 10 March 2012 (UTC)


 * As noted above formatting is a function of the controller and the the drive; this is an article about drives. If in fact the only difference between the 2302 and 1302 is the format then we should combine the sections.  Finally, if in fact the integrated drive on the System/360 model 44 is particularly notable because it represents IBM's first use of Fixed Block Architecture on System/360 then it probably belongs in the FBA article not hear. BTW didn't the 2311 on the 360/20 use FBA?  Tom94022 (talk) 22:31, 11 March 2012 (UTC)


 * IMHO it's notable because it was the only occurrence of an integrated drive on a 360 system. Peter Flass (talk) 23:53, 11 March 2012 (UTC)


 * I agree it is notable, and it is so noted in the DASD section of the S/360 article. But it is still just a 2310 and therefore not suitable for listing as a separate section in this article. Tom94022 (talk) 00:41, 12 March 2012 (UTC)

didn't the 2311 on the 360/20 use FBA?
The IBM System/360 Model 20 Functional Characteristics manual is on bitsavers, and it reveals on page 62 that yes, the interface to the IBM 2311 did use a 270-byte fixed block architecture. Furthermore, the model 20 preceded the model 44, so, if you consider the model 20 a &ldquo;real&rdquo; System/360 then it, not the model 44, is the first use of FBA on System/360. John Sauter (talk) 04:13, 12 March 2012 (UTC)


 * Are u sure that every usage by IBM of a fixed block size corresponds to what IBM meant by the term "Fixed Block Architecture?" I'm not.  The first disk drive, the RAMAC had a fixed block size.  I don't think the phrase "Fixed Block Architecture" appears in either the S/360 M20 or M44 manuals although their data block sizes were fixed (based upon Google site search of the Bitsavers S/360 site.  To the best of my recollection, the term was first introduced by IBM in the System/38 and AS400 36 (maybe S/34) as the only surviving relic of FS and it applied to all levels of memory .  Furthermore I seem to recall, without much research, that it was then ECKD that introduced fixed block sizes but not the term FBA into S/390 (maybe E9000).  This makes the FBA article quite wrong and IMO the usage of fixed block sizes on the S/360 M44 not notable, at least in this article.  Tom94022 (talk) 18:03, 12 March 2012 (UTC)


 * I don't think the name that IBM marketing calls something is very relavent to this article, which focuses on the size, speed, internal organization and announcement date of the various disk drives. IBM has a definition of &ldquo;fixed block architecture&rdquo; which fits any drive that offers only fixed-size blocks of storage through its interface.  This article doesn't seem to consider the disk drive's interface to be very important, so perhaps (by the standards of this article) it is not notable that the System/360 model 44 was the first System/360 that included a disk drive for which the count-key-data interface was not provided. John Sauter (talk) 02:12, 13 March 2012 (UTC)


 * I think you are confusing access method, channel and controller functions with the drive interfaces. For both the 2311 on the M20 and the 2310 on the M44 the drive interface was not natively fixed block but could support any format imposed by its controller including CKD as in fact the 2311 did on other systems.  I bet if you looked at the formatted disk you would find CHR track format with DL fixed and KL=0.  In other words, if you looked at a formatted track you could not tell whether it was written on a system with fixed blocks or not. So I agree by the standards of this article which is all about the drives that the 2310 on the M44 is not notable for the fixed block size imposed by the M44 controller. Tom94022 (talk) 07:10, 13 March 2012 (UTC)


 * Your speculation about the model 20's version of the 2311 is close but not correct. Bitsavers has an image of the field engineering manual at IBM 2311 FE Theory of Operation.  It describes in detail the differences between the IBM 2311 models 11 and 12 (used of the System/360 model 20) and the model 1 (used on System/360 models 30 and higher through the IBM 2841).  It turns out that the model 20 uses a special format which cannot be read by the IBM 2841. John Sauter (talk) 03:32, 14 March 2012 (UTC)

How many megabytes the first disk drive (IBM 350) stored
There is some disagreement and confusion on this, based on the edit history.
 * 06:47, 16 December 2011 – The 350 stored 5 million 6-bit characters ( megabytes). (→IBM 350:  5*6/8=3.75.  The channel word was 8 bits but the data word was 6 bits - the industry uses data bits.)
 * 02:29, 16 December 2011 – The 350 stored 5 million 7-bit (6-bits plus 1 odd parity bit) characters ( megabytes). (→IBM 350: you don't count the parity (ECC) bits when you quote "gigabytes" for modern HDs; you don't count the parity bits on the 350 either)
 * 17:23, 5 March    2007 – The 350 stored 5 million 7-bit (6-bits plus 1 odd parity bit) characters ( megabytes). (→IBM 350)
 * 08:01, 17 November 2006 – The 350 stored 5 million 7-bit characters ( megabytes). (→IBM 350:   text merged from IBM RAMAC trademark)
 * 04:57, 16 March   2006 – The 350 stored 5 million characters ( 5 megabytes).  (→IBM 350:  minor edit)
 * 16:09, 27 July    2004 – The 350 stored 5 million characters. (create)

First we need the definition of megabyte—from the article– ...one million bytes (106, see prefix mega-) generally for computer storage. ...and for byte—from the article– ''... Historically, a byte was the number of bits used to encode a single character of text in a computer and for this reason it is the basic addressable element in many computer architectures. The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size... The term byte was coined by Dr. Werner Buchholz in July 1956.''

So, from that we have... the term byte is never used in the 305 RAMAC Manual of Operation, as surely the system was designed before the term was even coined. For our purposes, a character is a byte is a character. We are dealing with 6-bit bytes, which means the machine only supports upper case characters. Machines supporting lower case characters using 7-bit ASCII came along later. And now Wikipedia uses UTF-8 8-bit bytes. Now, if anyone wants to precisely compare apples and oranges (1950s vs. modern HDDs), they should compare how many bits, or megabits, or gigabits they can store.

I say, the 350 stored exactly 5 * 106 bytes. That's what Five decades of disk drive industry firsts, DISK/TREND said too. – 5 megabytes – Wbm1058 (talk) 02:46, 19 October 2012 (UTC)


 * The term byte today means 8 bits and has pretty much been so since 1964 or thereabouts. The RAMAC had 3.75 megabytes in 5 million 6 bit characters is accurate and meaningful.  To say the RAMAC had 5 million bytes is to mis-inform the public.  Furthermore the RAMAC had an 8th bit which like the parity bit is irrelevant to the information content of the characters stored on the RAMAC.  My good friend, now deceased, Jim Porter agreed with this definition, not withstanding the error on the cited page.  Tom94022 (talk) 02:58, 19 October 2012 (UTC)


 * Agree with Tom94022. The claim of "5 million bytes" is flatly wrong. IBM marketed it as "five million characters", the characters being six bits each, as was common on many IBM machines of the day. That's not the same as five million bytes. Jeh (talk) 18:39, 19 October 2012 (UTC)


 * Historicaly, a byte was a string of bits that the CPU could access as a unit; it could cross word boundary and could have an arbitrary size. Ever since the advent of the IBM S/360, the unqualified term byte has frequently been used to refer to 8 bit bytes on an 8 bit boundary, especially when refering to stroage capacity. Multiplying the capacity of the 350 by 3/4 to get a size in 8-bit bytes is meaningful, if not particularly useful. Referring to the capacity as 5 million 6-bit bytes would be meaningful, but refering to it as 5 million bytes is simply misleading. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:39, 22 October 2012 (UTC)

again
This issue was raised again by a series of five edits on November 1 that added megabyte equivalents to the descriptions of the 353, 355, 1405, 1301 and 1311. I am inclined, having re-read the above discussion, to change the unit from megabytes to bits. If there is objection to that, my second choice would be to remove the megabyte descriptions. Any thoughts? John Sauter (talk) 13:30, 4 November 2016 (UTC)


 * The bytes/bits difference is always confusing, especially when people use MB and Mb.  Recently thinking about inflation adjusted prices,   $xxx (equivalent to $yyy in 2015), if we put  xxx million characaters (equivalent to yyy megabytes today).  People are more used to megabytes (Note that the 3330 seems to have been designed for 100 million bytes.)  To further the confusion, it seems that marketers of magnetic tape (consider LTO for example) believe that bytes have four bits. Note that bit (and so also byte) has meaning in terms of hardware (something that can have two states) and in information theory (where it means something with two equal probability states).  English text has about four bits of information (entropy) per character, and so compresses about 2:1.  We could make it explicit:  (... equivalent to xxx (8 bit) megabytes).  But is that 1,000,000 byte megabytes, or 1,048,576 byte megabytes?   Gah4 (talk) 19:05, 4 November 2016 (UTC)

I would avoid both the MB/Mb problem and the MiB/MB problem by spelling out the number of bits. I see that the incorrect description of the 355 has already been removed, so I would describe the 1405 model 1 as storing 60,000,000 bits. John Sauter (talk) 13:20, 5 November 2016 (UTC)

I have changed megabytes to bits as described above. John Sauter (talk) 16:54, 6 November 2016 (UTC)

RAMAC Disk Diameter
A IP and I have been ping-ponging over what set the size of the RAMAC disk to 24-inches. AFAICR, the IBM door requirement was 30-inches but even if it was 29.5-inches a constrained disk could be as large as 28.5-inches and still fit in a 29-inch cabinet so the chosen size of 24-inches shows no evidence of the cabinet size as a constraint. Furthermore there is no evidence in the many books and articles that the cabinet size was a factor in the choice of disk diameter. They started with 16-inch disks and apparently went to 24-inch to meet the 5 million character requirement. The pressure if anything was to make the diameter as small as possible for cost reasons within the constraint of meeting the capacity requirement. So this whole line within the article is TMI at most and likely wrong. I think it is best to just state the cabinet size and leave out all the rest. Tom94022 (talk) 00:25, 25 February 2013 (UTC)


 * Okey Dokey. But I'm not a newbie.  :-)   Incidentally, I actually did do some search for a reference on the "gotta be able to get in through the door" purported requirement and I couldn't find any.  I found a bunch of statements that were word-for-word the same as our original passage from this article.  Initially, it looked like WP lifted from them, but ultimately I realized it was the other way around, so citing them would be a classic WP circular ref!  :-)


 * Please allow me to argue a bit about the idea of "TMI". I'm not sure it's a very valid criterion for non-inclusion.  It's very subjective.  (The phrase comes from "Pulp Fiction", as I recall.)  I would expect it might apply in cases where an article is too long and needed to be whittled down, perhaps.  It might be another word for "digression" or "off topic"?  I don't think "TMI" would apply in this case at all.  Instead, "notability" and "verifiability", and "on-topic" apply, and it fails on verifiability.  "Notability", "verifiability", and "on-topic" are strong, and very emphasized as important criteria in WP directives.  "TMI" doesn't have that same heft.  In this particular case, if the disk size was limited by the cabinet size and the cabinet size was limited by doorway sizes, and if that was backed up by a reliable ref, then that I would argue is very notable, and even interesting, and very suited for inclusion.  Calling it "TMI" is ambiguous and subjective and has an air of capriciousness.  Okay, those are my thoughts on "TMI" for what they're worth.  Best regards, 108.7.8.93 (talk) 20:21, 28 February 2013 (UTC)

Disk drives on IBM 7030 (Stretch) - 353 versus 7303?
IBM had both a 353 and a 7303 disk drive for the 7030; the article mentions only the 353. Does anybody have information on the differences between the 353 and the 7303?

Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:08, 14 June 2013 (UTC)


 * I'll look into it, but I wonder of the whole group of 350 variants (e.g. 355, 1405, etc.) should be listed separately or within the 350 section. It may well be that they were just rebadged models with minor changes and not worthy of separate sections.  This is what we do later on when one OEM model appears in many systems with various model numbers and/or feature codes. The 353 had a head per surface which was different than the 350 and its ilk, I don't know about the 7303 but because it was on Stretch my guess is it is a variant on the 353 and possibly should be combined with it.  I would further guess that it was a double density 353.  Will research this Tom94022 (talk) 12:55, 15 June 2013 (UTC)


 * Still looking into this; however, FWIW, the specified capacity of the 7303 at 2,097,152 64 bit words works out to about 26 MB on a 50 disk machine (the 7303 purports to use on 32 disks for data leaving the others to other purposes, 2.1*8*50/32=26.5) which suggests the 7303 is an enhanced version of a double capacity IBM 350 (only 10 million characters). This suggests the 353 was based in the single capacity 350.  Given the 7030 shipped in 1961 it is likely the 353 never shipped but it may have been announced.  Tom94022 (talk) 19:46, 15 January 2015 (UTC)


 * Another clue - the IBM September 1960 fact sheet gave the disk capacity as "more than 1,250,000 alphabetic characters." perhaps referring to the 353. Tom94022 (talk) 20:51, 15 January 2015 (UTC)

This is probably still OR, but i think the 7303s only shipped with the first 7030; they were followed and replaced by 353s. The 353s were 2.1 million words; the 7303s were likely the same but could have been about 1 million words. The facts and/or assumptions that lead me to this conclusion are: I need to get my IBM friends to post some of this at their RAMAC site so as to have an RS instead of my OR. Tom94022 (talk) 07:25, 16 January 2015 (UTC)
 * My retired IBM SJ friends tell me the first Stretch system shipped with drives having "air" heads (like the 350) but all subsequent Stretch Drives shipped with "flying heads" (like the 1301/1405). The first drives were likely replaced.
 * The model number 7303 is only found in some system literature with early dates; we can find no product documentation
 * The model number 353 appears in product literature with later dates.
 * The earliest literature gives a capacity of about 1 million words, the later literature states 2.1 million 64-bit words
 * The 353 CE manual confirms it used "flying" heads like those in the 1301.
 * The "air" heads of the double capacity 350 at 7.5 MB could do about 1 million words. The "flying" heads of the 1405 at about 15 MB could do about 2 million words.
 * The Stretch drive at the Computer History Museum came from Lawrence Labs, the second 7030 installation (Nov 1961), and is badged as 353.

More OR, but contemperaneous documents (1961 abd 1963) indicate that the first 7030 shipped to Los Alamos had Model 353 disk storage units, so it is likely the 7303 was withdrawn in favor of the 353 before first shipment. Tom94022 (talk) 22:36, 19 May 2015 (UTC)

IBM 2314 address plugs
Moved from User talk:Tom94022

The first time I saw those I thought they were the most amazingly good idea ever. That's why I put it in. :) Jeh (talk) 08:11, 23 December 2013 (UTC)
 * I think they only existed in the IBM world for two generations, 2314 and 3330, but it is not clear why. I'm told the projected reliability of the original bundled 2314 was so low that they had to have a spare so the customer would always have full capacity but that then necessitated a means to match a specific pack to a specific channel address, perhaps for booting.  A switch to take a drive off line is a lot cheaper than the plugs and that is what IBM did before and after. BTW, I am pretty sure the 3340 channel address of the drive was hard wired as in the 2311 even though the 3348 data module was movable.  I suppose there are other situations where moving a pack and a plug is easier or preferable to dismount/mount operations.  This all became moot with fixed media drives.  BTW, I was involved in the design of the plugs for the Memorex 3330 equivalent - they were a pain and in my view good riddance :-)  Tom94022 (talk) 18:15, 23 December 2013 (UTC)
 * One situation: Job "A" which needed pack 1 on address x is about done, and next up is Job "B" that needs pack 2 on the same address. A good operator could have pack 2 already spinning on the spare drive. When Job A is finished you just move the plug to the spare drive. Of course it would also be possible to point the job at a different drive address with a DD JCL command, but a lot of operators weren't trusted with such things. Jeh (talk) 04:36, 24 December 2013 (UTC)


 * If a drive failed but the pack was still good, the address plugs let you move the pack to another drive in the middle of the job and continue running. Of course, if the pack was damaged then this also allowed you to destroy the drive you switched it to.


 * Allowing an operator to change the user's JCL was an invitation to disaster. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:07, 24 December 2013 (UTC)

Neither situation seems significant enough justify the cost and problems with address plugs.
 * Were there many JCL situations where the job required a specific volume to be at a specific address? I thought DOS and OS were a bit more sophisticated :-)
 * Since head crashes were a significant portion of disk pack drive failures moving a pack (and plug) from a failed drive really had a high probability of crashing a second drive (about 1 in 3 if I recall my statistics). There are apocryphal stories of operators destroying entire strings of drives by moving a crashed disk pack.

I really do believe address plugs were a consequence of the DASD product marketing decision to bundle 9 drives (original 2314 Model 1) on one control unit that only was capable of 8 online drive addresses. To bring the 9th drive online you had to take a drive off line and give its address to the "spare" drive - plugs solved that problem. Whether the bundling decision was to assure availability or to protect the 2311 revenue stream is another discussion. Tom94022 (talk) 22:00, 24 December 2013 (UTC)

Level of detail?
User:Tom94022 recently removed some material from the section on the IBM 2311, and that raises the question of the appropriate level of detail. In particular, should the paragraph describe the differences among the 2311-1, 2311-11 and 2311-12 and how much should it say about those differences? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 6 February 2014 (UTC)


 * Sounds like it should be a table. The guidelines have nothing that fits -  it's not "overly detailed."  A comparison of how speeds and capacities have changed over the years sounds like valuable information to me.  As I recall this article has some fairly zealous editors who work to keep it on topic, but in this case I think the mateial belongs here in some fashion or other, Peter Flass (talk) 17:31, 6 February 2014 (UTC)

On yr broad question of appropriate level of detail I suggest the material needs be notable and not "overly detailed" For example: Specifically with regard to the 2311-11 and 12 and I suggest saying nothing more than the 2311-11 & -12 were were variants for use on the System 360 M20, with the 2311-1 and 2311-11 field convertible and the 2311-12 a half capacity drive. A table seems too much. Tom94022 (talk) 20:14, 6 February 2014 (UTC)
 * The article generally does not mention A2, B2 or B1 models of IBM's later HDDs.
 * On the other hand the article goes thru the various 2314 derivatives because they are notable in context of the IBM responses to the market in the late 60s.
 * The 1311 section IMO appears to be too detailed.

Do we need three 1311 Photos
We now have three 1311 photos, two of which are essentially the same and appear distorted. I'm going to find one good color photo with a disk pack to replace the color ones unless someone objects. Tom94022 (talk) 01:19, 12 February 2014 (UTC)


 * Yeah, the same crossed my mind while reviewing latest edits. To me, the first one from the bottom looks most usable (though not of the best picture quality), as it also shows the disk pack. &mdash; Dsimic (talk | contribs) 02:47, 12 February 2014 (UTC)


 * Someone near the CHM might be able to get a better pic. Peter Flass (talk)

Most Expensive Hard Drive
Is the External Link to either notable enough or reliable enough for this article? I'm pretty sure the drive is likely not the World's most expensive one, certainly not if adjusted for inflation and I recall from the last time I went through that there were several factual errors. I don't want to go through it again, and even if I did, how could I correct the factual errors? So my recommendation is to not link to it on the basis that it is neither notable nor reliable. Tom94022 (talk) 18:10, 17 February 2014 (UTC)


 * The title of this video is bad for sure (and obviously created as such in order to attract more views on YouTube), but the content can't be that wrong – this guy is taking apart an old-generation HDD and showing its internals, what isn't that easily available to be seen.  Probably at least a few of the comments in this video are having issues (especially the comments on the HDD's read/write heads, for example), but the visual part can't be that wrong.
 * If we could end up with a more accurate title (containing just the exact HDD model), that would be good enough to keep the link, in my opinion, as I don't think there's a better freely available video or paper showing the internals of such old HDDs. If you disagree, please feel free to delete the link, I'm far away from being married to it. :) &mdash; Dsimic (talk | contribs) 18:45, 17 February 2014 (UTC)

RAMAC Purchase Price
The purchase price stated for the RAMAC in IBM's first HDD versus its last HDDs is actually that of the later (~1959) double density 350 Model 3 (7.5 MB) rather than that of the original Model 1 (3.75 MB). This is the price of the Model 3 in Montgomery Phister, Jr's "Data Processing Technology and Economics." It is possible that there never was a separate purchase price for the 350 Model 1 since it was originally bundled into the 305 System at a time when IBM was not necessarily selling products but only renting them. However, we do have a reliable source, in Emerson Pugh’s book “Building IBM” that the rental price of the 350 Model 1 was $650/month (out of a 305 rental price of $3,200/month). We also have from Phister that the Price:Rent ratio for the 350 Model 3 was 53 months which implies a 350 Model 1 purchase price of $31,800 $34,450. The 1956 consent decree required IBM to sell its products in addition to renting them and my recollection is that they were rigorous in establishing Rental Equivalent Selling Prices. A 53:1 ratio is consistent with IBM's practices into the 1970s. Therefore I believe such a calculation is a mathematical process and not original research but I can see when some might disagree.

If anyone has any reliable source for the Model 1 purchase price that would solve this problem; otherwise, it appears we have several choices:
 * 1) Go with the Model 3 purchase price, reflecting its capacity and live with the inapposite tabulation
 * 2) Use the estimated Model 1 purchase price, reflecting the calculation in a footnote
 * 3) Change the table to the Model 3 throughout

Comments and suggestions would be appreciated. Tom94022 (talk) 18:25, 24 August 2014 (UTC)

The Ballistic Research Laboratories "A THIRD SURVEY OF DOMESTIC ELECTRONIC DIGITAL COMPUTING SYSTEMS," March 1961, section on IBM 305 RAMAC (p. 314-331) is mainly about the double density 350s but does have several instances of Model 1 pricing; a $650/month rental at WE Aurora, Georgia State & Hamilton AFB and (confirming Pugh) and a $34,500 purchase price at Boeing Wichita ( somewhat higher than essentially the same as the estimate above). Tom94022 (talk) 06:52, 25 August 2014 (UTC)
 * I would go with the $34,500 price since it is sourced and is close enough to Tom's estimate. I'd also add "($ in current dollars)." --agr (talk) 10:04, 25 August 2014 (UTC)
 * Sorry for the math error, but we got there anyhow. Tom94022 (talk) 19:19, 25 August 2014 (UTC)

Editing Review Requested
An IP just asserted in this article and in the Hard disk drive article that the capacity of the RAMAC was 4.4 MB (more accurately 4.375 MB) based upon a 7 bit character. The actual RAMAC was an 8 bit encoded character with a parity bit and a space bit giving 6 data bits. I've asked the IP to move the discussion to this article but so far he has not done so. He/she seems to respond to multiple editor inputs so your review of RAMAC Price and Ratio would be appreciated.

IBM Micro Drive should be included in final comparison?
https://en.wikipedia.org/wiki/Microdrive — Preceding unsigned comment added by 70.36.223.208 (talk) 01:48, 2 March 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 2 one external links on History of IBM magnetic disk drives. Please take a moment to review my edit. You may add after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add to keep me off the page altogether, but should be used as a last resort. I made the following changes:
 * Attempted to fix sourcing for http://www.disktrend.com/5decades2.htm
 * Attempted to fix sourcing for http://www.magneticdiskheritagecenter.org/MDHC/RAMACBrochure.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 13:26, 29 March 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on History of IBM magnetic disk drives. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive http://web.archive.org/web/20110828062242/http://chmhdd.wetpaint.com:80/page/Disk+Drive+Patent to http://chmhdd.wetpaint.com/page/Disk+Drive+Patent

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 16:35, 27 June 2016 (UTC)

Alphameric
As well as I remember, alphameric is the IBM term for what everyone else calls alphanumeric. Then again, shouldn't this article be titled History of IBM Direct Access Storage Devices? Gah4 (talk) 02:01, 13 February 2017 (UTC)


 * The term alphameric included alphabetic, numeric and some special characters.


 * The article currently only includes disks. An article on DASD should also include drums, e.g., 7320, 2301, 2303, and mass storage devices, e.g., 2321, 3850. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:44, 14 February 2017 (UTC)


 * Yes! The 2321 Data Cell drive. "Random access tape". I never saw one in action "live". NCR had a version as well. Jeh (talk) 21:04, 14 February 2017 (UTC)


 * Well, the 2321 "noodle picker", like the RCA 3488 (RACE) and the NCR 353 (CRAM) used magnetic strips rather than a reel or cartridge of tape. The later IBM 3850 MSS used a pair of cartridges for each virtual 3330. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:52, 16 February 2017 (UTC)
 * For actual random access tape, there is DECtape. The 3850 is more like cached random access, where the whole cartridge (does it have to do both?) is written to disk, modified, then written back.  Do only cylinders modified have to be written back?  Gah4 (talk) 19:55, 16 February 2017 (UTC)


 * No, the entire cartridge is not written to disk. Pages 8 cylinders long are written to disk (staged) and written back to tape (destaged). The MSC did not write back unmodified pages. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:11, 17 February 2017 (UTC)

Isn't patent US3134097 the foundational patent, not US3503060
US Patent US3134097 https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US3134097.pdf, "Data Storage Machine," was filed Dec. 24, 1954, and is referenced in US3503060. It's clearly the foundational patent; why is US3503060 listed as the patent here?

Simsong (talk) 23:29, 12 August 2017 (UTC)
 * Short answer: No - see the fixed link.
 * Long answer: Both patents come from the same application but only the 3503060 patent claims disk drives and IBM cited it as such in awarding the inventors, not 3134097. Tom94022 (talk) 00:08, 13 August 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 6 external links on History of IBM magnetic disk drives. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20100129071535/http://chmhdd.wetpaint.com/page/IBM+350+RAMAC to http://chmhdd.wetpaint.com/page/IBM+350+RAMAC
 * Added archive https://web.archive.org/web/20101220051758/http://web.mac.com/ashoagland/Site/About_us.html to http://web.mac.com/ashoagland/Site/About_us.html
 * Added archive https://web.archive.org/web/20120829030155/http://www.bitsavers.org/pdf/ibm/140x/A26-5991-0_1311diskDrive.pdf to http://www.bitsavers.org/pdf/ibm/140x/A26-5991-0_1311diskDrive.pdf
 * Added archive https://web.archive.org/web/20110718040754/http://chmhdd.wetpaint.com/page/IBM+Sawmill to http://chmhdd.wetpaint.com/page/IBM+Sawmill
 * Added archive https://web.archive.org/web/20110918005148/http://www.blingcheese.com/video-4/dasd.htm to http://www.blingcheese.com/video-4/dasd.htm
 * Added archive https://web.archive.org/web/20120829030155/http://www.bitsavers.org/pdf/ibm/140x/A26-5991-0_1311diskDrive.pdf to http://www.bitsavers.org/pdf/ibm/140x/A26-5991-0_1311diskDrive.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 18:11, 4 November 2017 (UTC)

I have fixed the two references to A26-5991-0 in bitsavers. It appears that the directory structure at bitsavers has changed. John Sauter (talk) 15:18, 5 November 2017 (UTC)

Density calc seems off
On mobile, so i cant (or dont want) to calculate myself, but the "mb/mm cubed" calc is clearly off. Most likely it should be "mb/cm cubed", but possibly it's simply crap. Please recalc, and post w correct unit. Thx. קיפודנחש (aka kipod) (talk) 20:34, 27 January 2018 (UTC)
 * Where is this calc - I don't find it in either the article or the talk page? Tom94022 (talk) 20:57, 27 January 2018 (UTC)


 * The table near the bottom has gigabyte/in**3 and megabytes/mm**3. I didn't check so carefully, but it looks like some might be wrong.  Gah4 (talk) 13:25, 28 January 2018 (UTC)


 * It looks like the line MB/mm3 is off by a factor of 1000 which would make it MB/cm3. I'll check the math and correct the label.Tom94022 (talk) 02:23, 29 January 2018 (UTC)
 * done Tom94022 (talk) 21:10, 13 March 2018 (UTC)

Scare quotes?
A recent edit to History of IBM magnetic disk drives by user:Cherkash put scare quotes around load mode and move mode.

The same edit changed page ranges to use what look like em dashes, an apparent violation of WP:DASH. It also changed Load Mode and Move Mode to lower case. Neither the old text nor the new match the capitalization in the 1401 manual. Is there a legitimate reason to use scare quotes there? Should I revert the edit and change the case to match the 1401 documentation? Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:14, 23 April 2020 (UTC)
 * From scare quotes it seems that they are used when a term is unusual, or used in an unusual sense. If they are common CS terms, then I would expect a page, either with the same name or a different name, that could be linked to. If they are not common, then quoting and a reference to the 1401 manual that defines them, including the page reference, would be nice.  If they actually are common (enough) terms (even with a different name), then they should have their own page. I have thought about "locate mode" I/O before, which PL/I has, and which otherwise seems rare now, and wondered if it should have a page. Is one of them similar to "locate mode"?  It seems that CMS Pipelines mentions locate mode, and also the PL/I article. Otherwise, it seems to be a lost art. Gah4 (talk) 00:47, 23 April 2020 (UTC)
 * I looked there, and it seems pretty clear that scare quotes are generally considered pejorative. Also, QUOTEMARK says "Italics can be used to mark a particular usage as a term of art", so I'll go with a revert, fixing the capitalization and marking italics. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:51, 23 April 2020 (UTC)
 * Italics sound fine to me. Now for the actual meaning. As well as I know, move mode (I would have called it copy mode) is the alternative to locate mode. Is load mode similar to locate mode?  Gah4 (talk) 04:19, 23 April 2020 (UTC)
 * It seems that VMS also has move mode and locate mode.Gah4 (talk) 04:31, 23 April 2020 (UTC)
 * Italics sound fine to me. Now for the actual meaning. As well as I know, move mode (I would have called it copy mode) is the alternative to locate mode. Is load mode similar to locate mode?  Gah4 (talk) 04:19, 23 April 2020 (UTC)
 * It seems that VMS also has move mode and locate mode.Gah4 (talk) 04:31, 23 April 2020 (UTC)
 * It seems that VMS also has move mode and locate mode.Gah4 (talk) 04:31, 23 April 2020 (UTC)
 * It seems that VMS also has move mode and locate mode.Gah4 (talk) 04:31, 23 April 2020 (UTC)


 * Move and Load on the IBM 14xx/7010 refer to the format; specifically whether word marks are included. Move and Locate on OS/360 and successors refers to whether GET and PUT copy a record or only provide its address. VMS took its nomenclature from OS/360.


 * OS/360 Data Management isn't a lost art, but there's no wiki article on it. I'm not willing to undertake the task until Wikipedia has an effective dispute resolution mechanism, but I can give you links to contemporary documentation if you're willing to do it. I can't provide the dates at which various transitions occurred.


 * FYI, see Template talk:Citation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:57, 23 April 2020 (UTC)

Drums
It has been suggested that drums be moved elsewhere. Looking around, I don’t see a good fit. There is this article, which is specifically IBM, and Drum memory, which is a general article, a companion to Disk storage. I can see moving Data cell to its own article, because it’s a unique device, but there’s not enough material on specifically IBM drums for an article, but the material is too specific to fit the general article. I’d like to see the System/360 drums kept here, perhaps stretching the definition of “magnetic disk”. I think renaming the article has been proposed, but I can’t think of a title that fits and isn’t confusing. Peter Flass (talk) 18:35, 30 April 2021 (UTC)


 * I'd prefer to include all IBM DASD and change the title accordingly. The "noodle picker" (2321 Data Cell) and the 3850 Mass Storage System could reasonably included as well as the drums.


 * I thought of that, but optical drives are also DASD, though floppies aren’t, so a “DASD” article would have to at least mention these. Peter Flass (talk) 23:05, 30 April 2021 (UTC)
 * How are floppy disk drives not direct access storage devices? Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * BTW, IBM wasn't the only one to have mass storage devices, less expensive but slower than disks, nor the first to use magnetic strips. There were, e.g., NCR CRAM, RCA R.A.C.E., TBM. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:45, 30 April 2021 (UTC)
 * Such a change has been discussed several times in the past and always rejected, most recently at talk started by Chatul on April 18 at Talk:History_of_IBM_magnetic_disk_drives. As I noted therein, at different times IBM described some of the magnetic disk drives it manufactured using the terms, disc storage, file, DASD, FDD or HDD; the term first came into usage circa 1966. The fact that some other technologies were also called DASD by IBM is no justification to split this article. Furthermore, magnetic disk drive, FDD and HDD are the terms in much more common usages than DASD and therefore is a better subject for this article's title. Tom94022 (talk) 21:10, 30 April 2021 (UTC)
 * The IBM 2321 Data Cell, IBM 3850 and NCR CRAM have articles. Why not expand the Direct-access storage device article to link to this article, pick up DASD existing articles, have sections on missing DASD and explain what it means today in the absence of CKD DASD.  Renaming this article which is accurate, complete and uses generally accepted terminology,magnetic disk drives, is not appropriate.  Tom94022 (talk) 21:10, 30 April 2021 (UTC)
 * Those are not history articles, nor is IBM 7320.
 * BTW, there are no articles for IBM 2301 and 2303, but AFAIK they were a lot more common than the 7320. 22:45, 30 April 2021 (UTC) Shmuel (Seymour J.) Metz Username:Chatul (talk)
 * I'm not sure what you mean by "history" articles but the devices are history and can be linked from an expanded Direct-access storage device article if someone wants to expand the scope. Likewise there is nothing to stop adding the 2301 or 2303 as sections in such an article.  The 7320 is a different problem since it was never a DASD in IBM literature so it would be as inappropriate in the Direct-access storage device article as it would be here.  Finally doesn't the existence and size of theIBM 7320 article suggest articles on the IBM 2301 and IBM 2303 or a IBM 230x Drums is the place for these DASD and not here?  Tom94022 (talk) 22:56, 30 April 2021 (UTC)
 * that’s what started this section. I added them and someone commented them out because they weren’t disks. Peter Flass (talk) 23:05, 30 April 2021 (UTC)
 * The 2301 doesn't belong in Drum memory, as that is for main storage drums. The 2301 is used logically in the way a disk is used, but is faster. It seems, then, (using the usually wording) that it logically, but not physically, belongs in this article. Maybe that can be used to explain it in the article. I am less sure about how to explain the 2321. Gah4 (talk) 23:10, 30 April 2021 (UTC)
 * The Drum memory article does mention that Drums were also used as secondary storage which IMO does make it suitable for expansion into drum storage devices, or maybe that is the article that could be renamed to accommodate the 2301 and 2302 2303. Tom94022 (talk) 23:52, 30 April 2021 (UTC)
 * The 2302 is a disk drive, not a drum. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * Sorry, 2303, I always get that wrong Peter Flass (talk) 01:54, 1 May 2021 (UTC)
 * There’s also the staging system that defined virtual 3330s and downloaded disk images from tape on request. I can’t remember the model, but there doesn’t seem to be an article. Peter Flass (talk) 23:39, 30 April 2021 (UTC)
 * See IBM 3850 - it actually used 3330 DASDs as part of the subsystem but the permanent data were stored on tape. As best I recall the 3850 presented itself to the system as a array of DASD much larger than the actual DASD used therein. Tom94022 (talk) 23:52, 30 April 2021 (UTC)
 * The MSS used a pair of cartridges for each 3330V, making it look like a 3330-1. It could use a combination of 3330-1, 3330-11 and 3350 as staging drives. The 3851 staged and destaged a cylinder at a time although the allocation unit (page) size was larger. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * I don't understand what is unclear about the term history article. The article is concerned primarily with chronology rather than technical details, and the word history appears in the title.
 * The 7320 most certainly was considered to be a DASD, and was part of the early lineup for S/360.
 * Following your logic, doesn't the existence of articles on, e.g., the IBM 2302, IBM 2305, IBM 2311, IBM 2314, 3310, IBM 3330, IBM 3340, IBM 3350, IBM 3370, IBM 3380, IBM 3390, suggest that they shouldn't be in this article? Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * Most, if not all, are redirects to a section of this article. I didn't test all of them. Gah4 (talk) 09:05, 1 May 2021 (UTC)
 * Thanks, I added the 3850 as a “see also” Peter Flass (talk) 00:21, 1 May 2021
 * The MSS used a pair of cartridges for each 3330V, making it look like a 3330-1. It could use a combination of 3330-1, 3330-11 and 3350 as staging drives. The 3851 staged and destaged a cylinder at a time although the allocation unit (page) size was larger. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * I don't understand what is unclear about the term history article. The article is concerned primarily with chronology rather than technical details, and the word history appears in the title.
 * The 7320 most certainly was considered to be a DASD, and was part of the early lineup for S/360.
 * Following your logic, doesn't the existence of articles on, e.g., the IBM 2302, IBM 2305, IBM 2311, IBM 2314, 3310, IBM 3330, IBM 3340, IBM 3350, IBM 3370, IBM 3380, IBM 3390, suggest that they shouldn't be in this article? Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:48, 1 May 2021 (UTC)
 * Most, if not all, are redirects to a section of this article. I didn't test all of them. Gah4 (talk) 09:05, 1 May 2021 (UTC)
 * Thanks, I added the 3850 as a “see also” Peter Flass (talk) 00:21, 1 May 2021
 * Thanks, I added the 3850 as a “see also” Peter Flass (talk) 00:21, 1 May 2021
 * Thanks, I added the 3850 as a “see also” Peter Flass (talk) 00:21, 1 May 2021

Based on this discussion I added back the 2301 and 2303 stuff, plus a sentence on the 2321 with a link to that article. Peter Flass (talk) 15:56, 1 May 2021 (UTC)
 * On what in the above discussion do you base your decision to add devices that are not magnetic disk drives to an article entitled "History of IBM magnetic disk drives?" As near as I can tell you are the only person supporting the change.  Some people have argued for renaming the article do encompass DASD but there is no consensus on that either.  Please explain yourself before I revert.  Tom94022 (talk) 01:35, 2 May 2021 (UTC)


 * That still leaves the issues of the 7320 and the article name. How about adding the 7320 in two places, with tailored wording based on the 7320 article, and renaming (via WP:RM) the article to History of IBM magnetic disk drives and other DASD?
 * The 353, 1301, 1302 and 7300 were all mainframe disk drives. Accordingly, shouldn't History of IBM magnetic disk drives be renamed to IBM System/360 and later IBM mainframe HDDs?
 * In The IBM 2321, while not a disk, is a DASD device, the word device is redundant. Also, there should be similar language about the 2301 and 2303. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:00, 2 May 2021 (UTC)
 * Did IBM have any optical DASDs? The place to cover DASD is the Direct-access storage device article; I will add a section to that article, "Devices" and link the various existing articles and mover the 2301 and 2302 from this article.  Any objections?  Tom94022 (talk) 05:18, 2 May 2021 (UTC)
 * BTW the Direct-access storage device already says, "IBM coined the term DASD as a shorthand describing hard disk drives, magnetic drums, and data cells." Adding a section on Devices seems highly appropriate for all device technologies and will enhance that article.  Tom94022 (talk) 05:24, 2 May 2021 (UTC)
 * I suppose, but I still vote for keeping the descriptions here. I am now wondering about Solid State Disk, though the article seems to avoid the problem as Solid-state drive, as far as I know, most people still call them disks. I do wonder how many people know what an actual disk (the round part) is? Maybe they are just used to the name, without any connection to something with the actual shape? I suspect it is now a generic name, without a necessary connection to the physical object. Gah4 (talk) 08:47, 2 May 2021 (UTC)
 * I've seen people staring right at the spinning disks of a 2305 and claiming that it was a drum, so I would ask what the usage is in the technical literature. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:30, 2 May 2021 (UTC)
 * I've started a WP:RM to formally discuss the name issue.
 * I've seen people staring right at the spinning disks of a 2305 and claiming that it was a drum, so I would ask what the usage is in the technical literature. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:30, 2 May 2021 (UTC)
 * I've started a WP:RM to formally discuss the name issue.
 * I've started a WP:RM to formally discuss the name issue.


 * I believe that Direct-access storage device is not an appropriate place for DASD chronology. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:30, 2 May 2021 (UTC)
 * Would you mind elaborating on why DASD and subsystems that look like DASD don't belong in an article entitled Direct-access storage device? Tom94022 (talk) 16:04, 2 May 2021 (UTC)

Requested move 2 May 2021

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion. 

The result of the move request was: not moved. (closed by non-admin page mover) Elli (talk &#124; contribs) 06:13, 19 May 2021 (UTC)

History of IBM magnetic disk drives → History of IBM Direct access storage devices – IBM disks, drums and mass storage devices all have similar hardware and software interfaces, and IBM refers to them collectively as direct-access storage devices (DASD). There are not enough IBM DASD other than disk drives to justify separate articles on, e.g., history of IBM drums. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:27, 2 May 2021 (UTC)


 * Oppose You need to carefully define what is meant by the direct-access storage devices (DASDs) you think should be included herein. The current article is well defined as magnetic disk drives manufactured by IBM and complete since IBM stopped manufacturing such devices.  The proposed rename opens a lot of ambiguities that should be resolved before any move is approved including but not limited to:
 * The proposal is misleading when it asserts that "IBM refers to them collectively as direct-access storage devices (DASD);" only some such devices have been at some times referred to as DASD. IBM has used other terms such as disc storage and file and is currently using HDD.
 * IBM stopped using the term DASD to describe devices and moved on to the more common HDD, optical DD (e.g., "IBM Optical Disk Drive") and FDD yet these were supported by various IBM hardware and software interfaces. Is the renamed article limited to those devices that IBM explicitly called DASD or devices that looked to a system as DASD like or devices that performed like an HDD?
 * The 3850 Mass Storage System proposed for inclusion is not a "device." It is a subsystem comprising three types of devices including DASD (listed in this article), a Control Unit and the "3850 Mass Storage Facility."  The IBM literature clearly distinguishes between DASD, Tape Systems and "another alternative to for data storage - a mass storage system." To certain IBM OSes it emulates DASD but the 3851 is not a DASD; it stores data on cartridges containing about 770 inches of tape.  AFAIK the 3851 is not directly addressable by any IBM OS. IF the 3850 is a DASD then so are all of the other IBM subsystems starting with the IBM RAMAC Array Subsystem (1994) and continuing up to an including the many current IBM Storage Products that appear to an OS as DASD.
 * The term DASD is well know to those of a certain age with IBM experience but it is not in common usage and will be unfamiliar to most readers. "Magnetic disk drive" is far more understandable to our readers.
 * Furthermore, use of DASD in the title of this article fails to meet at least three of the five criteria for it's use in this article's title. (added) Tom94022 (talk) 20:11, 14 May 2021 (UTC)
 * I suppose for the acronym, but people should be able to figure it out spelled out. Given the ever increasing use of flash memory, this will have to change eventually. It seems that IBM was ahead of the game in their naming. Gah4 (talk) 00:18, 15 May 2021 (UTC)
 * IMO it is not worth the effort to resolve all the above ambiguities and if we did it would produce an overlong article with an obscure title. I suggest a better approach is to either add physical DASD material to the existing direct-access storage device article or alternatively, prepare a new article, List of IBM DASD devices and subsystems which would be a simple list article linking those devices and subsystems with Wikipedia articles and external references for those not having articles. Tom94022 (talk) 15:59, 2 May 2021 (UTC)
 * Wikipedia already has a List of direct access storage devices; it would not be undue to an article on IBM Drum Storage or separate articles on the 2301 and 2302 and link the devices listed to this list. It makes a lot more sense than any major revision and re-titling of this article.  Tom94022 (talk) 16:25, 2 May 2021 (UTC)
 * I have now placed an alternative request for move at Talk:IBM_7320 to create a single article on IBM drum storage by moving the drum material from this article to the new expanded and renamed IBM 7320 article. Tom94022 (talk) 17:07, 2 May 2021 (UTC)
 * The 3850 Mass Storage System proposed for inclusion is not a "device."
 * Almost none of the S/360 and descendants DASD are stand-alone; almost all require a control unit to provide their documented functionality. The fact that the 3850 Mass Storage System requires a bit more auxiliary hardware doesn't change that. And, yes, the 3851 does have a channel interface to the host, not just the 3830.
 * Exactly my point the last device IBM called a DASD AFAIK was the 3390. Beginning with the RAMAC Array Subsystem (1994), IBM subsystems (not devices) emulated DASD by using devices that IBM called hard disk drives and now flash storage.  You may want to call them DASD, IBM never did in any of their product literature and I see no basis for calling them such now. The 3851 having a channel interface doesn't make it a DASD or maybe in your definition it does, since AFAIK thru its interface one can stage the individual cartridge and update at the level of the stripe. IBM never called the 3851 a DASD, will you know list it here? Tom94022 (talk) 06:02, 3 May 2021 (UTC)
 * IBM has used other terms such as disc storage and file and is currently using HDD.
 * Those terms describe specific types of DASD; they are not synonyms for DASD, any more than Volt is a synonym for Ford.
 * So a UNIVAC FASTRAND drum is a DASD even though neither Sperry nor Univac ever so described it as such. DASD is a term unique to IBM (and a few mostly defunct PCMs).  As such I think inclusion in a renamed article should be limited to those devices (not subsystems) that IBM labeled in device literature as DASD.  Again I urge that proponents of the change list what DASD they think will be added to the article and what devices currently in the article will no longer be listed.  For example why won't the 3431 Optical disk drive now be added and why call the Star series DASD when IBM never did? Tom94022 (talk) 06:02, 3 May 2021 (UTC)
 * The Volt of course was made GM and one could call it a personal transportation device but that doesn't make sense. SSDs and HDDs now used by IBM in many products to emulate "DASD" would also have to be added to this article under the expansive definition used by the proponent of this title change.  So far the supporters have not addressed this issue by failing to propose a corresponding revision to the lede. Tom94022 (talk) 17:45, 10 May 2021 (UTC)
 * OK, one possibility is that disk is now a generic name for (lower case) direct-access storage devices. We are so used to them now, that we don't think much about it. As noted above, some called the 2305 a drum, as a generic name for seekless storage devices. (That might have more history in the Unix world, for reasons I don't know.) For users, and especially remote users, it isn't the shape that is important, but the function. As far as I know, most people believe that SSD is solid state disk, though it might be that even more people have no idea where bits go, other than that they magically reappear later. In any case, DASD more accurately describes the function, and ignores the shape. Gah4 (talk) 11:59, 11 May 2021 (UTC)
 * IBM stopped using the term DASD to describe devices and moved on to the more common HDD, optical DD (e.g., "IBM Optical Disk Drive") and FDD
 * No, IBM has not stopped using the term DASD and, in fact, current AIX documentation refers to floppy diskettes as DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:09, 3 May 2021 (UTC)
 * Yes, IBM has stopped using the term DASD to describe devices in any device or subsystem literature that I have looked at. For example, the IBM FlashSystem 5000 data sheet uses the terms disk drive 6 times and never uses DASD.  That fact that the term DASD is still used internally in some IBM OSes does not change the fact that the term hasn't been used by IBM to describe devices since last century.  Tom94022 (talk) 06:02, 3 May 2021 (UTC)
 * OK, one possibility is that disk is now a generic name for (lower case) direct-access storage devices. We are so used to them now, that we don't think much about it. As noted above, some called the 2305 a drum, as a generic name for seekless storage devices. (That might have more history in the Unix world, for reasons I don't know.) For users, and especially remote users, it isn't the shape that is important, but the function. As far as I know, most people believe that SSD is solid state disk, though it might be that even more people have no idea where bits go, other than that they magically reappear later. In any case, DASD more accurately describes the function, and ignores the shape. Gah4 (talk) 11:59, 11 May 2021 (UTC)
 * IBM stopped using the term DASD to describe devices and moved on to the more common HDD, optical DD (e.g., "IBM Optical Disk Drive") and FDD
 * No, IBM has not stopped using the term DASD and, in fact, current AIX documentation refers to floppy diskettes as DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:09, 3 May 2021 (UTC)
 * Yes, IBM has stopped using the term DASD to describe devices in any device or subsystem literature that I have looked at. For example, the IBM FlashSystem 5000 data sheet uses the terms disk drive 6 times and never uses DASD.  That fact that the term DASD is still used internally in some IBM OSes does not change the fact that the term hasn't been used by IBM to describe devices since last century.  Tom94022 (talk) 06:02, 3 May 2021 (UTC)
 * No, IBM has not stopped using the term DASD and, in fact, current AIX documentation refers to floppy diskettes as DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:09, 3 May 2021 (UTC)
 * Yes, IBM has stopped using the term DASD to describe devices in any device or subsystem literature that I have looked at. For example, the IBM FlashSystem 5000 data sheet uses the terms disk drive 6 times and never uses DASD.  That fact that the term DASD is still used internally in some IBM OSes does not change the fact that the term hasn't been used by IBM to describe devices since last century.  Tom94022 (talk) 06:02, 3 May 2021 (UTC)


 * Oppose. The only IBM drum devices in this article are the 2301 and 2303, not enough for a separate article. It seems cleaner to put theme here, together with the short sections on the 3850 and 2321 that link to the individual articles. That way, everything is tied up in a neat bundle. I think we're getting to hung up on the "disk" part. Peter Flass (talk) 19:41, 2 May 2021 (UTC)
 * Actually the phrase "magnetic disk drive" is composed of three quite specific elements; the problem is IBM DASD is ambiguous at best. Is it limited to those things IBM actually described as DASD in the drive literature (which I believe to be the only valid definition) or does it have a broader definition to include every device and subsystem that operates as, like or appears to be a DASD?  Paraphrasing Voltaire, if you wish to converse with me, define DASD! Tom94022 (talk) 06:02, 3 May 2021 (UTC)
 * May I suggest you fail to appreciate the ramifications of the term DASD - once the article name is changed it should bring in a whole bunch of other devices and systems. Please explain why the 3850 is in the article and why the IBM RAMAC Array Subsystem (1994) should not be added.  It like the drums does not have an article but it is likely far more significant than the drums or the 3850?  Tom94022 (talk) 20:33, 2 May 2021 (UTC)
 * Why is the 9394 not here, or in it’s own article? Probably no one has gotten around to adding it, I guess. I realize “DASD” might also bring in optical. I just put the 3850 in as a “see also link”. My feeling is that if it looks like a duck, and quacks like a duck (=DASD) it should at least have a mention or link in this article. You seem pretty adamant about this. I think I understand where you’re coming from; it’s a question of inclusion vs. exclusion. Peter Flass (talk) 00:09, 3 May 2021 (UTC)
 * It would clearly belong here even if there were a separate article, as do FCP attached SCSI drives. In fact, History of IBM magnetic disk drives does mention the 9334. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:09, 3 May 2021 (UTC)
 * Now that the drums are in the article may I suggest u change your position to Neutral or Oppose since the proponent of the name change has failed to address the many problems that would be caused by the name change. Tom94022 (talk) 00:23, 16 May 2021 (UTC)


 * Support. The 2301 and 2303 belong here. If it needs renaming to allow it, then I support it. There will be a redirect, so no-one will get confused in the end. Gah4 (talk) 23:48, 5 May 2021 (UTC)
 * As for the 3850, what goes in for UNIT in JCL? If it is the staging volume, then it doesn't seem that it needs to go here. All users know is that their data appears where they expect it to be. If we include the 3850, then should we also include tape drives that data might (automatically) get backed up to? If the JCL says UNIT=3850, then I would say it belongs here. (I did a little search, but it isn't easy to find.) Gah4 (talk) 23:48, 5 May 2021 (UTC)
 * UNIT=3330V. Only the MSS support code talks directly to the 3851. Normal DASD I/O goes to the address of a virtual drive. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:47, 6 May 2021 (UTC)
 * Thank you for pointing out that the term DASD as used by IBM in certain operating systems applies to emulated devices 3380 and 3390 and not to the many physical devices that make up the subsystems providing such emulation. Also thanks for pointing out that such information isn't easy to find.  It is hard to see how such usage justifies, for example, calling a Deskstar HDD a DASD.  18:36, 7 May 2021 (UTC)
 * Thank you for trying to put words in my mouth. Had I meant such a thing I would have written it. As for being hard to find, I just used a search engine and the DS8000 popped up. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:29, 7 May 2021 (UTC)
 * Now that the drums are in the article may I suggest u change your position to Neutral or Oppose since the proponent of the name change has failed to address the many problems that would be caused by the name change. Tom94022 (talk) 00:23, 16 May 2021 (UTC)


 * Oppose – We can stick to disks, and skip the odd IBM terminology, and move the few drums to the other article as Tom94022 proposed. Also, why the odd capitalization of "Direct"? Dicklyon (talk) 03:06, 9 May 2021 (UTC)
 * Since the if is satisfied, it seems close enough for me. How bad is it if I don't change it? Gah4 (talk) 09:50, 16 May 2021 (UTC)
 * Since the if is satisfied, it seems close enough for me. How bad is it if I don't change it? Gah4 (talk) 09:50, 16 May 2021 (UTC)


 * Oppose. The scope of this article is well-defined and encyclopedic. Perhaps there is a need for a separate article covering other DASD devices, or perhaps they are best just as a passing mention on the history of disk drives... IBM made little use of other technologies, unlike for example UNIVAC with its fastrand drum. Andrewa (talk) 11:28, 15 May 2021 (UTC)

Need to revise LEDE
While is easy to propose a change in the title of this article, the current LEDE is totally inappropriate for such a retitled article. As noted above the editor proposing this change "need[s] to carefully define what is meant by the direct-access storage devices (DASDs) ..." which should include as a minimum a new LEDE consistent with the new title and any new content supporting the lede. Tom94022 (talk) 18:40, 4 May 2021 (UTC)

Usage of term DASD
With regards to IBM no longer using the term DASD, I cite https://www.ibm.com/docs/en/zos/2.1.0?topic=reporting-cache-subsystem-status-overview, https://www.ibm.com/docs/en/ztpf/1.1.0.14?topic=hardware-storage-devices and https://www.ibm.com/docs/en/linux-on-systems?topic=linuxonibm/com.ibm.linux.z.ludd/ludd_t_dasd_wrk_list.html as examples that IBM still uses the terms. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 6 May 2021 (UTC)
 * To repeat myself, "Yes, IBM has stopped using the term DASD to describe devices in any device or subsystem literature that I have looked at.(emphasis added) For example, the IBM FlashSystem 5000 data sheet uses the terms disk drive 6 times and never uses DASD. That fact that the term DASD is still used internally in some IBM OSes does not change the fact that the term hasn't been used by IBM to describe devices since last century."  Tom94022 (talk) 19:22, 6 May 2021 (UTC)
 * And Ford has stopped describing the Volt as a vehicle. IBM normally used more specific terms in hardware manuals and more general terms in software manuals, because the software had to deal with a variety of devices and needed umbrella terms to refer to groups of similar devices. If IBM software manuals are still using the term DASD then IBM is still using the term DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:51, 6 May 2021 (UTC)
 * It turns out that the hardware folks were still using the term DASD in 2020. Is that recent enough for you? Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:01, 7 May 2021 (UTC)
 * It turns out that the hardware folks were still using the term DASD in 2020. Is that recent enough for you? Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:01, 7 May 2021 (UTC)


 * Okay, I’m happy with things as they are now. I just wanted to find a good home for the drums, etc. I think the present revision is a good solution.Peter Flass (talk) 01:07, 16 May 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Emulation
As well as I know, later IBM DASD in 3390 series were actually emulated using something like we now call RAID. Logically it looked like a 3390, including track size and such, but physically was not. To the OS and user, they all look the same, other than track size. Also, many of them emulate CKD on underlying FBA hardware. (That is separate from the emulation used for P/370 and P/390.) We should be even more used to this by now, with SSD, which are flash memory emulations of rotating disks. If you don't open the box, you won't know that the 2301 is a drum. (I believe it doesn't have a window, and is not otherwise easy to open.) One possibility is to have separate articles for the physical hardware and logical view of it seen by users and OSes. Gah4 (talk) 00:14, 6 May 2021 (UTC)

Also, the original DASD (and, for that matter, sequential devices) were designed when memory was expensive. There is very little buffering between the bits in storage and main memory. It seems that IBM calls this synchronous. Later, when memory was cheaper, more buffering was added, allowing for what IBM calls asynchronous. Much of the complication of earlier storage was to avoid channel overrun and underrun, in the timing between the physical device and main storage. But the user doesn't need to know that, unless everything fails in a big way. Then, the 3850 can be considered as an emulation of a much larger disk, or set of disks, with the staging volumes as cache. In the case of physical devices, one might want to know how exactly data is written onto the device? Is it MFM coded, for example? At the logical level, all one needs to know is that bytes come out in the same order they went in. (Except in tape with read backwards.) We could have separate articles for the physical and logical devices. Gah4 (talk) 00:14, 6 May 2021 (UTC)
 * None of the IBM 33xx devices were RAID; however, subsequent DASD subsystems simulated 3380 and 3390 geometries on sectored disks, and some of those subsystems did use RAID,e.g. 9394-002 IBM RAMAC 2 Array Subsystem Model 002. DS8000. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:49, 6 May 2021 (UTC)
 * If it quacks like a 3390, and UNIT=3390, then users believe it is a 3390. I thought that some had a 3390 number, but I didn't try to follow them so close. This one seems to describe them in RAID terms, without making it so obvious which ones are which. Also, this one seems to be actually from IBM, explaining the history and model numbers, and that once you get to the 3390-A, there are no higher model numbers! Gah4 (talk) 06:31, 7 May 2021 (UTC)
 * The largest 3390 is a model 9, however, users with newer DASD subsystems have been carving out larger volumes and using the unit names 3390-27 and 3390-54 for a very long time. When IBM introduced Extended Addressability Volumes (EAV), the configuration option was 3390-A, but that was not a model number and did not indicate a specific number of cylinders; a "3390-A" is whatever size you define it to be. Shmuel (Seymour J.) Metz Username:Chatul (talk) 07:51, 7 May 2021 (UTC)
 * Yes. If we were talking about products from some other company, then we might call them clones or some similar name. But these are IBM products. The fact that the number of cylinders varies isn't so significant, as VM has been doing that since forever. (Since CP/67, anyway.) They are still DASD and still disks! Combining and splitting physical volumes into logical volumes goes back a long way, too. As above, is this article only supposed to apply to physical disk devices, or only logical ones? Maybe we need two articles?  IBM still considers the 3390-A part of the 3390 family, or they would give it a different number!  (Considering how often they give different numbers to the same device, such as 2314 and 2319, they had plenty of chance here, too.) Gah4 (talk) 00:04, 8 May 2021 (UTC)
 * IBM uses, e.g., RAMAC, ESS, as product names. It does not use 3390-27, 3390-54 or 3390-A as product names.Those are options that you use when carving out a virtual disk from the DASD farm of the device. Note also that sensing device characteristics will only report virtual disks as 3390 models 1, 2, 3, 9 and A, never as model 27 or 54. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:46, 9 May 2021 (UTC)
 * It seems that there is a Minidisk (CMS) as a redirect to CMS file system. That doesn't seem quite right, as VM minidisks exist at the CP level, even without CMS. Gah4 (talk) 00:12, 8 May 2021 (UTC)
 * I am in the process of trying to clean up the more egregious issues relating to VM. I'd like to have minidisk (VM) linking to VM (operating system) rather than to CMS file system, and to fix minidisk. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:46, 9 May 2021 (UTC)
 * Sounds good to me. Gah4 (talk) 06:34, 9 May 2021 (UTC)
 * IBM uses, e.g., RAMAC, ESS, as product names. It does not use 3390-27, 3390-54 or 3390-A as product names.Those are options that you use when carving out a virtual disk from the DASD farm of the device. Note also that sensing device characteristics will only report virtual disks as 3390 models 1, 2, 3, 9 and A, never as model 27 or 54. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:46, 9 May 2021 (UTC)
 * It seems that there is a Minidisk (CMS) as a redirect to CMS file system. That doesn't seem quite right, as VM minidisks exist at the CP level, even without CMS. Gah4 (talk) 00:12, 8 May 2021 (UTC)
 * I am in the process of trying to clean up the more egregious issues relating to VM. I'd like to have minidisk (VM) linking to VM (operating system) rather than to CMS file system, and to fix minidisk. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:46, 9 May 2021 (UTC)
 * Sounds good to me. Gah4 (talk) 06:34, 9 May 2021 (UTC)
 * I am in the process of trying to clean up the more egregious issues relating to VM. I'd like to have minidisk (VM) linking to VM (operating system) rather than to CMS file system, and to fix minidisk. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:46, 9 May 2021 (UTC)
 * Sounds good to me. Gah4 (talk) 06:34, 9 May 2021 (UTC)
 * Sounds good to me. Gah4 (talk) 06:34, 9 May 2021 (UTC)

physical and logical
OK, now that that one is figured out, it seems that the physical vs. logical question is still there. For one, the 2301 has one head per physical track, four four per logical track. Does that matter? The four makes it four times (bytes/s) faster. I believe that one model of the 2305 also has a different track structure. And then there is the 3390 that runs at 1/3 the speed, so large latency but more bytes, so three logical tracks per physical track. Yes there are a lot of ways to put things together. Gah4 (talk) 10:14, 16 May 2021 (UTC)
 * FWIW I don't think it matters much to a system programmer since those physical difference translate into performance characteristics such as data rate and latency (as u noted for the 2301) but it does mean quite a bit to a device designer and to someone looking at the device at its interface.  My recollection of the 2305 was that all the fixed heads were 8 bits wide and depending upon the model you could have one or two heads transmitting at a time.  From a programmers viewpoint that's either 1.5 MB/sec or 3.0 MB/sec but from a device viewpoint it sure matters whether that data rate is achieved on 1, 8 or 16 wires.  Tom94022 (talk) 00:44, 17 May 2021 (UTC)
 * Yes all those, and those reasons. For the programmer (of CKD devices) things like logical track length are important, but physical track forms are not. For the 2305, the one I am trying to remember gives you less rotational delay by putting two heads on each track. At least I think that is what I remember. Gah4 (talk) 08:25, 17 May 2021 (UTC)
 * Yes all those, and those reasons. For the programmer (of CKD devices) things like logical track length are important, but physical track forms are not. For the 2305, the one I am trying to remember gives you less rotational delay by putting two heads on each track. At least I think that is what I remember. Gah4 (talk) 08:25, 17 May 2021 (UTC)
 * Yes all those, and those reasons. For the programmer (of CKD devices) things like logical track length are important, but physical track forms are not. For the 2305, the one I am trying to remember gives you less rotational delay by putting two heads on each track. At least I think that is what I remember. Gah4 (talk) 08:25, 17 May 2021 (UTC)

Capacity metrics
I have some questions about what the numbers for capacity should mean.
 * 1) Many IBM DASD have alternate tracks. Should the numbers include or exclude them.
 * 2) IBM gives the track sizes and formulae for calculating what will fit, e.g., on the 3330 the track size is 13165 but the largest records that you can write with a standard R0 on the track is 13030. Should the article mention both numbers? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:46, 16 May 2021 (UTC)
 * For the 3330 with N blocks per track, N*(135+BLKSIZE) <= 13165. The 135, then, includes block headers and gaps. But for earlier devices, such as the 2314, the overhead is less for the last (or only) block. In the early days, PC disk drives, and floppy disks, gave both unformatted and formatted capacity. Unformatted includes gaps and block headers. As capacity depends on block size, and the manufacturer doesn't necessarily know, it made some sense to give unformatted capacity. I don't think we should do that, but whichever one we should do it consistently. On the other hand for IBM DASD, R0 is a convention that, in theory and probably without IBM OS, one could do without. On the third hand, I don't think we need to use excessive precision in calculating capacity.  We could, for example, also add alternate tracks. Other than tradition, there is no reason one can't write data on them and use them.
 * The size and content of R0 is an OS convention; the special treatment of R0 is not. Various channel commands automatically skip over R0 when skipping to the next sequential track, and the chaining requirements of Write Count Key Data necessitate an R0. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 17 May 2021 (UTC)
 * The size and content of R0 is an OS convention; the special treatment of R0 is not. Various channel commands automatically skip over R0 when skipping to the next sequential track, and the chaining requirements of Write Count Key Data necessitate an R0. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 17 May 2021 (UTC)
 * The size and content of R0 is an OS convention; the special treatment of R0 is not. Various channel commands automatically skip over R0 when skipping to the next sequential track, and the chaining requirements of Write Count Key Data necessitate an R0. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 17 May 2021 (UTC)


 * Actually the 3330 track size is 13,440 bytes index to index. On CKD devices the device capacity is a function of the track format.  Both CKD and fixed block devices have spares.  I suggest we should use IBM's published capacity and ignore distractions like track format and sparing. At most maybe we should have a note for CKD devices that "the capacity is based upon a full track record with a standard IBM record zero and the actual formatted capacity may be lower," but I suspect that is TMI.  Tom94022 (talk) 21:58, 16 May 2021 (UTC)
 * Well, for the 3330, 13030 and 13165  are both IBM's published number, although the first is published in decimal and the second is published in hexadecimal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:30, 16 May 2021 (UTC)
 * You do understand that on IBM CKD control units after Index there is a gap followed by the home address field and then another gap after which can be one or more record fields so that the index to index number of bytes is greater than those published numbers. You should also understand that the published maximum record length refers to the length of the data field as does not include the space taken up by gaps, the count field and the ECC/EDC fields.  If you examined the maintenance literature and calculated the length of those fields you will come up with exactly 13,440 bytes index to index, no more, no less.  The 3300/3830 used a phase locked loop to synchronize the write data rate to the spindle rotation so it's track length was precise and there was no need for a speed tolerance Gap 4 as in prior IBM DASD.  Other companies formatted the 3336 disk pack differently and came up with other capacities but they were all limited by the 13,449 bytes per track unformatted, 411 tracks per surface and 19 data surfaces.  Tom94022 (talk) 23:58, 16 May 2021 (UTC)
 * Il va sans dire. I also realize that what IBM published as the capacity in the cited manual was based upon the space left after writing home address et al. The capacity calculation that IBM publishes yields correct results when using the numbers that IBM publishes. Other numbers that you can infer do not yield correct result and should not be shown without a caveat. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:03, 17 May 2021 (UTC)
 * S'il te plaît, ne mets pas de mots dans ma bouche. The calculated number will give accurate results for any format including IBM's CKD format, but I never proposed using any number other than the number IBM published for the capacity.  So do you agree we should go with the IBM number, e.g. 100 MB for the 3330, without any caveat?  Tom94022 (talk) 01:25, 17 May 2021 (UTC)
 * 200 MB is fine for the approximate capacity of a 3330-11, but that says nothing about which number to use for the track capacity. What IBM publishes for CKD DASD is two numbers: the track balance after writing a standard R0 and the largest possible physical record with KL=0. The article should make clear, and be consistent about, which is being used. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:24, 17 May 2021 (UTC)
 * As above, R0 is an OS convention, so it wouldn't be too strange to include it. But gaps and block headers are required, so it makes more sense not to count them. Gah4 (talk) 08:55, 17 May 2021 (UTC)
 * R0 is also required, due to the chaining requirements for Write Count Key Data. The same manual also shows a capacity calculation using a base of 13,165.
 * 200 MB is fine for the approximate capacity of a 3330-11, but that says nothing about which number to use for the track capacity. What IBM publishes for CKD DASD is two numbers: the track balance after writing a standard R0 and the largest possible physical record with KL=0. The article should make clear, and be consistent about, which is being used. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:24, 17 May 2021 (UTC)
 * As above, R0 is an OS convention, so it wouldn't be too strange to include it. But gaps and block headers are required, so it makes more sense not to count them. Gah4 (talk) 08:55, 17 May 2021 (UTC)
 * R0 is also required, due to the chaining requirements for Write Count Key Data. The same manual also shows a capacity calculation using a base of 13,165.
 * R0 is also required, due to the chaining requirements for Write Count Key Data. The same manual also shows a capacity calculation using a base of 13,165.
 * R0 is also required, due to the chaining requirements for Write Count Key Data. The same manual also shows a capacity calculation using a base of 13,165.


 * I believe one could write a full track R0 using IBM's channel commands which would be readable with channel commands but not usable with IBM access methods. True or not, isn't that pretty much irrelevant to this discussion.  AFAIK every IBM CKD drive came with a table giving various capacities under a variety of assumptions about RL and KL.  I see no need to go into such detail in this article and the only capacity we should cite is the top line one IBM published for the device and not the other capacities a consequence of track format.  Using the 3330 as a continuing example its capacities as stated by IBM in the reference manual are approximately 100 million bytes for the -1 and approximately 200 million bytes for the -11.  Those are the only two numbers that should appear in this article, with or without the "approximately".  Tom94022 (talk) 18:35, 17 May 2021 (UTC)
 * The primary issue is how to describe the track capacity, not the volume capacity. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:18, 17 May 2021 (UTC)
 * The primary issue is how to describe the track capacity, not the volume capacity. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:18, 17 May 2021 (UTC)

If as Chatul suggests:

I suggest the answer is don't do it in this article. FWIW the phrase track capacity appears just one in the article without any stated capacity. For purpose of this article only the device capacity as stated by IBM need be included. The fact that the capacity of CKD devices is a function of the track format is irrelevant and we should continue to use the "approximate" capacity as stated by IBM. Tom94022 (talk) 23:52, 18 May 2021 (UTC)
 * The article doesn't use consistent nomenclature; it gives some sizes without using the phrase track capacity. I believe that the question of whether to give track capacities at all warrants a separate section on the talk page. Certainly the article currently gives track sizes for a few, but not most, devices. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:28, 19 May 2021 (UTC)
 * OK, but volume capacity is track capacity time the number of tracks. Unlike FBA, where you don't have to worry about some of those things. For some reason I don't know, IBM changed the way the formula work starting with the 3330. It doesn't seem quite right that there is no block header or gap for the last block on a 2314, but just that they way the formulae were written was changed. Gah4 (talk) 05:17, 19 May 2021 (UTC)
 * Beginning with the 3330 and on all subsequent CKD devices the write frequency was synchronized with the spindle rotational speed so there was no need for a speed variation gap, G4, on these later devices. Prior to that the rotational speed could vary by as much as 5% so that at a constant write frequency the length of the track could vary typically due to wear over time but also due to things like line frequency changes.  Thus during format writes a G4 was appended to fill the excess space on a slow turning spindle. Tom94022 (talk) 16:08, 19 May 2021 (UTC)
 * OK, but volume capacity is track capacity time the number of tracks. Unlike FBA, where you don't have to worry about some of those things. For some reason I don't know, IBM changed the way the formula work starting with the 3330. It doesn't seem quite right that there is no block header or gap for the last block on a 2314, but just that they way the formulae were written was changed. Gah4 (talk) 05:17, 19 May 2021 (UTC)
 * Beginning with the 3330 and on all subsequent CKD devices the write frequency was synchronized with the spindle rotational speed so there was no need for a speed variation gap, G4, on these later devices. Prior to that the rotational speed could vary by as much as 5% so that at a constant write frequency the length of the track could vary typically due to wear over time but also due to things like line frequency changes.  Thus during format writes a G4 was appended to fill the excess space on a slow turning spindle. Tom94022 (talk) 16:08, 19 May 2021 (UTC)

Should the article give track capacities?
The article currently gives both track and volume sizes for a few, but nor most devices. Should it only give volume sizes, or should there be a brief statement of what metric is being used for track sizes and the information added for the other devices? Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:28, 19 May 2021 (UTC)
 * It is a feature (or not) of CKD that one can optimize blocking for the device. Though I do remember SCSI devices where the disk could be reformatted with a specified block size. Mostly that was done for systems using ECC on 520 byte blocks. But earlier, ST-506 style devices, could be formatted any way the user (or disk controller) wanted to. For OS that allowed for other block sizes, usually multiples of 512, in theory it could be done. As well as I know, modern SATA devices optimize all this internally. They might write physically larger blocks, and reblock between the cache and the disk. One could also give capacity for CKD devices based on 512 byte blocks, as that might be a fair comparison to FB-512 devices. Gah4 (talk) 05:32, 19 May 2021 (UTC)
 * It is a feature (or not) of CKD that one can optimize blocking for the device. Though I do remember SCSI devices where the disk could be reformatted with a specified block size. Mostly that was done for systems using ECC on 520 byte blocks. But earlier, ST-506 style devices, could be formatted any way the user (or disk controller) wanted to. For OS that allowed for other block sizes, usually multiples of 512, in theory it could be done. As well as I know, modern SATA devices optimize all this internally. They might write physically larger blocks, and reblock between the cache and the disk. One could also give capacity for CKD devices based on 512 byte blocks, as that might be a fair comparison to FB-512 devices. Gah4 (talk) 05:32, 19 May 2021 (UTC)


 * Oppose IMO, track capacity is a level of detail that is not necessary in this article particularly since for CKD devices the track capacity is a variable function of the format, for example, the "100 MB" 3330 with KL=0 and DL=80 has a capacity of 37.5 MB. For such CKD devices IBM uses the largest possible Data field length with a standard HA and RO and no Key field to state the nominal capacity of such devices and we should do the same.  The two track capacities given should be removed for consistency.  At most we should do is have a footnote for all CKD devices that notes, "this is a nominal capacity published by IBM and the actual capacity in operation may be less as a function of device formatting", or words to that effect."Tom94022 (talk) 16:29, 19 May 2021 (UTC)
 * FWIW in the 3330 example footnoted above, 13165 - 135 = 13030 which is the maximum R1 length with KL=0 and 135 corresponding to the length of HA and RO and associated gaps. So there is one maximum track length number using IBM's standard formatting times the number of tracks to get to 100 MB capacity.  Tom94022 (talk) 15:52, 25 May 2021 (UTC)
 * BTW the early FBA drives have the same problem, they could be formatted with a variety of block sizes, so what track capacity would we add to those devices, the unformatted track capacity or the track capacity with a specific block size? If so which one?  Another reason for just dealing with CKD HDDs with one footnote.  Tom94022 (talk) 06:24, 31 May 2021 (UTC)
 * Well, when they started selling disks separate from formatters, at least the ST506, it was usually in unformatted capacity. That is why a 5MB disk is ST506 and a 10MB disk is ST412. (Besides that marketing people always like bigger numbers.) For the common FBA block sizes, the difference in formatted size isn't so big, as the round-off to whole blocks for larger blocks partly makes up for the gaps of smaller blocks. It is a convenience of CKD that it allows small blocks on smaller systems, where there isn't enough memory for large buffers, and larger (more efficient) blocks on larger systems. Smaller S/360 models use 80 byte blocks. For larger systems, it was 1/4 or 1/2 track for 3330s. I suppose fairest would be unformatted size for all. Gah4 (talk) 08:55, 31 May 2021 (UTC)
 * Until spanned records, the block size couldn't be less than the record length, and the record length for print files was typically 121, 133 or 145, plus RDW if variable. Also, capacity was terrible for 80-byte blocks, so even small systems would use 5:1 blocking. Finally, load modules were typically much larger than 80 even on small systems.
 * It seems we all agree track capacity is a very difficult number to state precisely. Formatters were sold separately from the devices for much of the history of HDDs, especially after the emergence of the OEM industry in the late 1960s and continuing into the 1990s when embedded servo sectors forced a fixed block size which was low-level formatted by the HDD manufacturer (see: Low-level formatting (LLF) of hard disks.  Formatters were and in part still are in the controller or in the OS or both.  Prior to embedded servo sectors all drives had an unformatted capacity, index to index, most systems used FBA. IBM, its clones and near clones were unique with the CKD format and there were clever folks who produced special products to provide higher capacity by using larger block sizes than the standard - I seem to recall some FDD products that wrote full track block sizes.  Depending upon the device the stated unformatted track capacity may have only been nominal due to motor speed variations.  Highend HDDs beginning with IBM's 3330 had an exact number of bytes index to index, 13440 in the case of the 3336. IBM never made the number publically available but anyone making a plug compatible device or medium knew and publicized the number as part of selling their OEM version.  As Chatul noted, the 3330 track capacity is a forumula and if u look at the reference manual the track capacity table takes two pages.  So given the complexities, why should we add track capacity to all of the HDDs listed? Tom94022 (talk) 18:11, 31 May 2021 (UTC)
 * Until spanned records, the block size couldn't be less than the record length, and the record length for print files was typically 121, 133 or 145, plus RDW if variable. Also, capacity was terrible for 80-byte blocks, so even small systems would use 5:1 blocking. Finally, load modules were typically much larger than 80 even on small systems.
 * It seems we all agree track capacity is a very difficult number to state precisely. Formatters were sold separately from the devices for much of the history of HDDs, especially after the emergence of the OEM industry in the late 1960s and continuing into the 1990s when embedded servo sectors forced a fixed block size which was low-level formatted by the HDD manufacturer (see: Low-level formatting (LLF) of hard disks.  Formatters were and in part still are in the controller or in the OS or both.  Prior to embedded servo sectors all drives had an unformatted capacity, index to index, most systems used FBA. IBM, its clones and near clones were unique with the CKD format and there were clever folks who produced special products to provide higher capacity by using larger block sizes than the standard - I seem to recall some FDD products that wrote full track block sizes.  Depending upon the device the stated unformatted track capacity may have only been nominal due to motor speed variations.  Highend HDDs beginning with IBM's 3330 had an exact number of bytes index to index, 13440 in the case of the 3336. IBM never made the number publically available but anyone making a plug compatible device or medium knew and publicized the number as part of selling their OEM version.  As Chatul noted, the 3330 track capacity is a forumula and if u look at the reference manual the track capacity table takes two pages.  So given the complexities, why should we add track capacity to all of the HDDs listed? Tom94022 (talk) 18:11, 31 May 2021 (UTC)


 * Support Yes it isn't necessary, but then so is about half the article. It is nice to have it, and convenient to have it here. Unless you would rather have a new article with more fine details on CKD devices and physical construction? Detail of gaps, block headers, modulation methods, and such? Physical vs. logical track structure? Hydraulic vs. magnetic actuators? Yes we don't need all the details of the block calculation here, but it is an interesting and important part of CKD devices, and the hardware of the time. Allowing for smaller blocks was important in allowing for small memory machines. A 360/40 with 64K of core likely can't write a full track 2314 with a reasonable sized program. Gah4 (talk) 01:23, 21 May 2021 (UTC)
 * Is a common note for all CKD devices sufficient or do we have to go into the details for each CKD device of the specific maximum R1 under standard programming conventions times number of heads times number of cylinders to arrive at IBMs published number? Note also there is sometimes the complication of a number of access mechanisms per HDA and number of HDA's per machine type which can lead to a capacity per access mechanism and a capacity per machine type. So if you support multiple capacities, which ones, or is a common note sufficient? Tom94022 (talk) 15:52, 25 May 2021 (UTC)
 * If the article uses consistent nomenclature then a single discussion of standard R0 and other assumptions should suffice. That remains true if the article covers both capacity calculations and largest R1; what matters is that the individual descriptions use terms as defined in the nomenclature explanation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:35, 25 May 2021 (UTC)
 * If the article uses consistent nomenclature then a single discussion of standard R0 and other assumptions should suffice. That remains true if the article covers both capacity calculations and largest R1; what matters is that the individual descriptions use terms as defined in the nomenclature explanation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:35, 25 May 2021 (UTC)
 * If the article uses consistent nomenclature then a single discussion of standard R0 and other assumptions should suffice. That remains true if the article covers both capacity calculations and largest R1; what matters is that the individual descriptions use terms as defined in the nomenclature explanation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:35, 25 May 2021 (UTC)


 * Support. This article is "History of...", and one part of the history is increasing speed and capacity, so I think all the specs should be included: track and device capacity, access time, rotational delay, transfer rate, etc. Peter Flass (talk) 14:38, 21 May 2021 (UTC)
 * Seriously? An IBM JRD article on "A Quarter Century of Disk File Innovation" gives the following set of parameters for some (350, 1405, 1301, 1311, 2314, 3330, 3340, 3350, 3370 & 3380) but not all IBM DASD, most of which are CKD:
 * Year of first ship
 * Recording density
 * Areal density (Mb/in2)
 * Linear bit density (bpi)
 * Track density (tpi)	X
 * Key geometric parameters (microin.)
 * Head-to-disk spacing
 * Head gap length
 * Medium thickness
 * Air hearing & magnetic element
 * Bearing type
 * Surface contour
 * Slider material
 * Core material
 * Slider/cerc bond
 * Disk
 * Diameter (in.)
 * Substrate thickness (in.)
 * Rpm
 * Fixed/removable
 * Data surfaces/spindle
 * Actuator
 * Access geometry
 * Heads
 * Positioning
 * Final position
 * Actuator/spindle (max. no.)
 * Avg. seek time (ms)
 * Read/write electronics
 * Data rate (kbyte/s)
 * Encoding
 * Detection
 * Clocking::::*Year of first ship
 * Recording density
 * Areal density (Mb/in2)
 * Linear bit density (bpi)
 * Track density (tpi)	X
 * Key geometric parameters (microin.)
 * Head-to-disk spacing
 * Head gap length
 * Medium thickness
 * Air hearing & magnetic element
 * Bearing type
 * Surface contour
 * Slider material
 * Core material
 * Slider/cerc bond
 * Disk
 * Diameter (in.)
 * Substrate thickness (in.)
 * Rpm
 * Fixed/removable
 * Data surfaces/spindle
 * Actuator
 * Access geometry
 * Heads
 * Positioning
 * Final position
 * Actuator/spindle (max. no.)
 * Avg. seek time (ms)
 * Read/write electronics
 * Data rate (KbyteVs)
 * Encoding
 * Detection
 * Clocking
 * And this list doesn't include capacity per se. So which ones?  And if it is a long list then perhaps a separate article in tabular form? Tom94022 (talk) 15:52, 25 May 2021 (UTC)
 * I took a look at the article; it definitely belongs in the list of external references, even though it doesn't go into formatting and capacity. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:35, 25 May 2021 (UTC)
 * So why don't you add it there? Tom94022 (talk) 17:28, 28 May 2021 (UTC)
 * By my count there are 26 parameters above plus, device capacity, track format (CKD or FBA), track Capacity (formatted and unformatted); so which of the 30 or so do you think we should add to this article? Tom94022 (talk) 17:28, 28 May 2021 (UTC)


 * Most of the parammeters are technical, and of interest only to specialists. In my opinion parameters relating to capacity and speed are worthwhile for inclusion in this article. Looking at the list these would seem to be fixed vs. removable, seek time, rotational delay, data rate. disk surfaces, CKD vs. FBA. Other things are interesting where they deviate from the norm, for example number of actuators>1. Possibly disk diameter. As I said, since this is a “history of” article, things that show the progression of increasing capacity and transfer rates vs. decreasing cost per bit. The dead ends, like drums and the datacell, are interesting because they show paths not taken. Again, this is only my opinion about where I’d like to see the article go. I’m fairly happy with what’s there now. Peter Flass (talk) 19:22, 28 May 2021 (UTC)
 * Yes those are about the ones I would suggest, too. Seek and rotational delay determine access time, which everyone wants to be fast. Data rate is important for streaming sequential blocks at high speed. Gah4 (talk) 19:50, 28 May 2021 (UTC)
 * Note that the section IBM's first HDD versus its last HDDs covers the history and uses tabular form presenting 19 general interest parameters including power, size, weight and cost all of which progressed over time for the about 46 devices enumerated. I suggest those are likely of more interest than say number of disks.  If we are going down that path, a 46x19 matrix in a new article seems the better path than cluttering each paragraph of this article with 19 or so parameters many of which will be missing and the progression will be lost in the clutter.  On the other hand, picking only a very few such as date and advertised capacity seems to be a better way to keep the article reasonable. So far AFAICT the short list is:
 * Model Number
 * Year announced/shipped/withdrawn
 * Advertised capacity
 * Fixed/Removable, CKD/FBA
 * Devices/Model Number
 * Track capacity formatted/unformatted
 * Average seek time
 * Latency
 * Maximum data rate
 * Size
 * Weight
 * Price/Unit of Capacity
 * It's a lot of work to gather just this amount of data and IMO anything beyond the first five would clutter the article. To go beyond an embedded five I think our readers would be better served by a separate draft article in table format that we work on until it is near complete because it is lot of work and I'm not sure who will do it.  Tom94022 (talk) 06:24, 31 May 2021 (UTC)
 * It's a lot of work to gather just this amount of data and IMO anything beyond the first five would clutter the article. To go beyond an embedded five I think our readers would be better served by a separate draft article in table format that we work on until it is near complete because it is lot of work and I'm not sure who will do it.  Tom94022 (talk) 06:24, 31 May 2021 (UTC)

Missing disk drives - 7303 and 3344
The article is missing information on the 7303 and 3344 drives.

The 7303 is problematical because of the scarcity of documentation, as discussed in. I'm not sure what, if anything, should go into the article.

The 3344 came out at about the same time as the 3340 and 3350. All of the 3344 models are B units and require a 3340-A2 head of string; for that reason perhaps they should be in the 3340 section rather than a section of their own. 05:03, 31 May 2021 (UTC) Shmuel (Seymour J.) Metz Username:Chatul (talk)
 * I doubt if either is controversial, so why don't you go ahead and add them? unsigned 18:11 31 May 2021 User:Tom94022
 * What I know about them is limited to the information in an early Stretch manual and in the 3340/3344 manual. If you want I can add information based on those, but it won't have the level of detail present for some other devices. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:07, 1 June 2021 (UTC)
 * I would go ahead with the 3444 as a sub-section to the 3340 much like the 3333 and the flavors of 2314. It was a 3350 but I don't know if there is an RS for that.
 * I'd completely forgotten about the 7303 issue, thanks for reminding me. I now found an RS (not online) which allowing for ECC gives the 353 the identical capacity as the 7303 so it is more likely they are same with different type numbers.  I've also pinged an IBM alumni group to see if they can further clarify the situation.  Why don't you hold off on the 7303 and when I gather some more information I will post it as appropriate.  Tom94022 (talk) 22:27, 1 June 2021 (UTC)
 * How about I rename the section to Stretch disk drive and then list both numbers in the section along with common characteristics? Tom94022 (talk) 20:46, 2 June 2021 (UTC)
 * I'd make it Stretch disk drives, reference the 353, 354, 7303 and 7612, and mention that none of the sources give the relation between the 353 and the 7303. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:12, 2 June 2021 (UTC)
 * Stretch disk file using the code name that it developed under at IBM SJ as the section heading and only covering the "353 Disk Storage" and "7303 Disk Storage" might make sense. Tom94022 (talk) 20:56, 3 June 2021 (UTC)
 * Singular if the 353 and 7303 are the same, otherwise plural. Either way the text should mention what they attach to, the 354 and 7612. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:49, 4 June 2021 (UTC)
 * No, the 3344 was not a 3350; both the track size and the capacity of a volume are less.
 * Yes, since it attaches to a 3340A2 that determines the track size as a 3340 track and that is why the track size and capacity are lower. But I am pretty sure that under the skins it is the same as a 3350. Not sure I can find an RS for it but that is my recollection from working on them. Tom94022 (talk) 18:22, 3 June 2021 (UTC)
 * I've split the 3340 section into a 3340 subsection and a 3344 subsection; it's missing a lot of detail on the 3344. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:34, 3 June 2021 (UTC)
 * No, the 3344 was not a 3350; both the track size and the capacity of a volume are less.
 * Yes, since it attaches to a 3340A2 that determines the track size as a 3340 track and that is why the track size and capacity are lower. But I am pretty sure that under the skins it is the same as a 3350. Not sure I can find an RS for it but that is my recollection from working on them. Tom94022 (talk) 18:22, 3 June 2021 (UTC)
 * I've split the 3340 section into a 3340 subsection and a 3344 subsection; it's missing a lot of detail on the 3344. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:34, 3 June 2021 (UTC)

Missing disk drives - 7303

 * One possibility is that IBM split the 7303 into two boxes, a 354 controller and a 353 drive. The cited page for the 7303 mentions the same 7612 disk exchange but doesn't mention a controller between the exchange and the 7303. Maybe your contacts can confirm or refute that guess. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:12, 2 June 2021 (UTC)
 * Definitely a possibility in that it is consistent with the language in DISC FILE APPLICATIONS but that might not be enuf to make our conclusion not OR. Tom94022 (talk) 20:56, 3 June 2021 (UTC)
 * The 7030 Reference manual makes it clear that disk storage units connect to it . Other documents identify the only units to attach to the disk synchronizer are the 7303 and the 354 with a 353 and that as far as storage parameters go, the 353 and 7303 are identical. I think this gets us as far as the 7303 is equivalent to a 354 with attached 353.  Comment? Tom94022 (talk) 23:47, 5 June 2021 (UTC)

The 1963 7030 Physical Planning Manual shows one 354 adjacent to to the 7612 and a remote 353 (sheets 14, 15 & 30/60). It does not mention the 7303. We know the 7612 can attach up to 32 disk storage units. Apparently the first one is a 353 and the remainder are 7303s. Since the 353 cannot connect to the 7612 further supports the conclusion that a 7303 was a 354 + 353 much like the 2414 DASF was a 2314 SCU plus 2x 2313 plus a 2312. Agree? It is certainly research but I don't think it quite rises to OR - comment? Tom94022 (talk) 00:19, 9 June 2021 (UTC)
 * I'd say mention that both 354/353 and 7303 attach to a 7612, mention the identical characteristics and include a hatnote that we don't know the connection between the 7303 and the 354/353.
 * Please correct 7020 in your citation. id, section and section-url would also be nice. I'd do it myself but changing someone else's talk text is frowned upon here. You can get a URL (subject to browser) to a specific page by appending #page=foo. The value of foo should be the PDF page number, which might not match the printed page number. E.g., something like this. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:44, 9 June 2021 (UTC)


 * Check out this BYU 7303 in action! Historically this was likely the disk storage shipped to Mitre.  It is pretty clearly a 353 if you compare the 353 manuals to this video.  The mystery continues albeit now with hardware included.  Tom94022 (talk) 17:03, 31 August 2021 (UTC)

Multiple requesting
The discussion of multiple exposure devices in Talk:Direct-access storage device has been intermixed with discussion of other issues, so I believe that it would lend clarity to move it to a separate section. The IBM 2305 Fixed Head Storage Module and IBM 2835 Storage Control introduced a new feature: MULTIPLE REQUESTING The multiple requesting function provides the capability for record request queuing within the 2835/2305 facility. This queuing is accomplished by allowing multiple set sector commands to be issued to a single disk module. The function is implemented by associating up to eight logical (system) device addresses with a single physical module. This permits the channel to issue a set sector command to one logical device, disconnect on channel end status, and then issue a set sector command to another logical device. The arguments transferred by the set sector command are stored in the control unit. Whenever the control unit is not executing a command and is not otherwise busy, it monitors the angular position counters in the attached disk modules. When a· counter compares equal with one of the stored arguments for that module, the control unit raises request-in and, when polled, presents device end status for the appropriate logical device. To properly complete a chain when the channel reconnects, the control unit must store the arguments of set file mask and seek commands issued previously in the same chain. If mUltiple requests are pending against a module, the proper head may no longer be selected when the channel reconnects to complete the chain. If this is the case, the control unit ensures that the proper head is reselected prior to raising request-in. this required that the 2835/2305 be connected to the new 2880 block multiplexor channel. Each of the logical addresses is known as an exposure.

In 1982, IBM reintroduced the concept with the 3880-11 and 3880-13 ; the later models 21 and 23 also supported multiple requesting.

With the announcement of Parallel Access Volumes (PAV), multiple requesting entered the mainstream.

A Commons file used on this page or its Wikidata item has been nominated for deletion
The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion: Participate in the deletion discussion at the. —Community Tech bot (talk) 01:23, 7 August 2021 (UTC)
 * IBM 350 RAMAC.jpg
 * Discussion Closed - image retained

Winchester technology
I think that Winchester technology is not adequately described. The huge advantage of Winchester technology is that the heads and the platters are all in a sealed container. The article (currently) says Winchester technology allowed the head to land and take off from the disk media as the disk spun up and down but that is far from saying that they were all contained in a safe package, protected from the outside. Sam Tomato (talk) 00:48, 14 September 2021 (UTC)
 * Before Winchester, disks packs were demountable. On power up, or when mounting a pack, various steps are done to make sure that the pack is clean enough (dust removed), and the the heads enter the pack and I/O operations begin. Early on, similar to tape, the idea of a permanently mounted pack doesn't seem to have been important.  (Other than for NASA, I don't know of tape drives with permanently mounted tape.)  It might be that there is one with removable head-disk assembly that is sealed, but otherwise allows a connection to the actuator. In any case, permanently mounted disks ended up common, and so a non-removable pack made sense. Once you do that, having a sealed HDA, is possible, and the ability to land the heads on the disk, unlike earlier drives, also makes sense.  So, the ability to land on the disk surface was a major advance, and that allowed for the sealed system with permanently mounted disk.  (Anyone remember the ZIP drive?) Gah4 (talk) 06:42, 14 September 2021 (UTC)
 * Before Winchester there were drives other than disk pack drives where the media was not removable ("demountable"}, including but not limited to the first disk drive. The first Winchester medium, the 3348 Data Module, was removeable and not sealed as disk drives are today. It was marginally better sealed than cartridges and disk packs;  As it loaded into the drive a roll top door opened to allow the actuator to connect to the head stack.  An advantage but not so huge.  The head remaining with the disk was the huge advantage, it was enabled by the low load and lubrication that allowed the head to take off and land on the disk and thereby remain associated with the disk and not have to deal with the problems associated with interchanging.  The 3350 then first used Winchester technology in a "fixed" disk drive.  With a few exceptions it isn't until today's helium filled HDDs that we truly have a "sealed"  HDA.  Tom94022 (talk) 07:14, 14 September 2021 (UTC)
 * Before Winchester there were drives other than disk pack drives where the media was not removable ("demountable"}, including but not limited to the first disk drive. The first Winchester medium, the 3348 Data Module, was removeable and not sealed as disk drives are today. It was marginally better sealed than cartridges and disk packs;  As it loaded into the drive a roll top door opened to allow the actuator to connect to the head stack.  An advantage but not so huge.  The head remaining with the disk was the huge advantage, it was enabled by the low load and lubrication that allowed the head to take off and land on the disk and thereby remain associated with the disk and not have to deal with the problems associated with interchanging.  The 3350 then first used Winchester technology in a "fixed" disk drive.  With a few exceptions it isn't until today's helium filled HDDs that we truly have a "sealed"  HDA.  Tom94022 (talk) 07:14, 14 September 2021 (UTC)