Talk:IBM drum storage

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: moved. (closed by non-admin page mover) ~ Aseleste (t, e | c, l) 05:08, 21 May 2021 (UTC)

---

IBM 7320 → IBM drum storage – This article is a stub that is not likely to be enlarged. There are two other IBM drum storage devices the IBM 2301 and IBM 2303 currently inappropriately listed in the History_of_IBM_magnetic_disk_drives article (they are not magnetic disk drives). It makes sense to rename and expand this article to include all IBM drums. Tom94022 (talk) 17:04, 2 May 2021 (UTC)—Relisting. User:Ceyockey (talk to me) 00:36, 14 May 2021 (UTC)

• See ongoing discussion at Talk:History_of_IBM_magnetic_disk_drives#Requested_move_2_May_2021 Tom94022 (talk) 17:10, 2 May 2021 (UTC)
• oppose, contingent on approval for Talk:History_of_IBM_magnetic_disk_drives#Requested_move_2_May_2021. If that is voted down then any new IBM drums article should also include older drum drives, e.g., 731, 732, 733, 734 and possibly the internal drums on the 305 and 650. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:30, 3 May 2021 (UTC)
• Support – and I opposed the alternative that Chatul mentions above. The disk/drum separation will be better for readers than moving more toward IBM's odd terminology. The disk article can still mention the drums and link here. Dicklyon (talk) 03:17, 9 May 2021 (UTC)
• Support. In view of the small number of IBM drum devices, it's sensible to have one article on them all, with suitable redirects of course. Andrewa (talk) 04:39, 21 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.

Post-closure

@Tom94022: You may want to move the content from History of IBM magnetic disk drives. ~ Aseleste (t, e | c, l) 05:12, 21 May 2021 (UTC)

Type of channel?

@John Sauter: You removed the reference to the selector channel with the comment The IBM 2841 is also supported on a multiplexor channel--see page 6 of A26-5988-0. However, I was unable to find any reference to the type of channel at http://bitsavers.org/pdf/ibm/2841/A26-5988-0_2841_2311_2321_7320_Descr.pdf#page=9, or in the index.

It's certainly possible that a selector subchannel of a multiplexer channel is supported, but if so I'd like to see the text supporting that capability and whether it was supported for all attached DASD. 17:10, 23 May 2021 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

Sorry, it is on page 8 rather than page 6. In the description of the fields in the I/O instructions, bits 21-23 are the channel address, where 000 is the multiplexer channel. Bit 24 is the "shared channel indicator" with this text: "1 indicates a multiplex channel or sub-channel. On a selector channel, this bit is included in the control unit address." Further down the page is a pointer to bit 24 with the text "Always 1 for 2841 on Multiplex Channel." The wording is unclear, but at least it implies that the IBM 2841 can be placed on a multiplexor channel, perhaps with some addressing restrictions. Note that the models 30, 40 and 50 do not have selector subchannels on their multiplexor channel—that was a feature of the IBM 2870, which could only be used on the larger models.

The multiplexor channel was certainly not supported for all attached DASD. The IBM 2301 requires an IBM 2860 selector channel. If you mean all attached DASD on an IBM 2841, I have found no text documenting any device-specific limitations. John Sauter (talk) 19:09, 23 May 2021 (UTC)

Interesting dialog and I haven't had the time to research, but I suspect data rate issues might cause a lot of overruns with a 2841 on a byte multiplexor channel. It would work but slowly? Tom94022 (talk) 19:57, 23 May 2021 (UTC)

Perhaps say selector channel or multiplexor channel in burst mode?

I was referring to DASD on the 2841; the 2820 is a different story. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:05, 23 May 2021 (UTC)

It seems like it varies by device and system. AFAICT the S/360 M30 has a burst mode data rate limitation of 200k/sec which might work but according to the S/360 M40 Functional Characteristics Manual p65/115 the 2314 and 2302 can only attach to the selector channel. So maybe "appropriate channel" or "supporting channel" might be most accurate. FWIW I haven't looked at any other ByteMux channels. 19:48, 24 May 2021 (UTC)

Rough bytes

@Peter Flass: Not sure how you calculated the "roughly" number of bytes of the various drums. Traditionally we have simply multiplied the word length by the number of bits and divided by 8 as for example in the 350 Disk Storage. This table shows the traditional calculation along with the numbers u posted

Model	Words	bits/word	Bytes	"Roughly" (per edit)
731	2048	36	9,216	12 kilobytes
732	60000	6	45,000	59 kilobytes
733	8192	36	36,864	48 kilobytes

Please explain your methodology and why it would be preferred over the mathematical approach used after a long discussion for the 350. BTW as I recall for the 350 the alternative was that a 1 byte means one character and that was 6 bits on the 350; that argument would make the 732 60,000 not 59k. Tom94022 (talk) 18:44, 26 June 2021 (UTC)

@Tom94022 60,000/1024. I used the computer guy’s “K” 1024 instead of the marketdroid’s 1000. Otherwise, as you mention, I said one byte=one character, and divided, again, by 1024. I’m not wedded to this, so if you think dividing by 1000 would be better, that’s fine. I just thought that giving capacities consistently in KB or MB would be clearer. Maybe just giving capacities in characters… Peter Flass (talk) 23:19, 26 June 2021 (UTC)

Well, I'm a computer guy, and I consider misusing the SI prefixes to be an abomination. While IBM has been guilty of this for main memory, it has never misused the SI prefixes for auxiliary memory, at least not on the System/360 or its descendants, nor anything older than the S/360. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:56, 27 June 2021 (UTC)

I agree the misuse of SI prefixes by some system types to be an abomination. Tom94022 (talk) 05:47, 27 June 2021 (UTC)

It appears that the column labelled bytes rough bytes is the capacity in six-bit bytes, natural for a 36-bit word and a six bit character, and the column labelled rough bytes bytes is the capacity in octets. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:56, 27 June 2021 (UTC)

Unless I screwed up Excel the column labeled 'bytes" is exactly the word length in bits * number of words / 8 bits Tom94022 (talk) 05:47, 27 June 2021 (UTC)

Sory, transposition, corrected above. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:44, 27 June 2021 (UTC)

Storage is almost always given using SI prefixes correctly, I'm going to replace the capacity with number of bytes, no prefixes. Today byte == 8 bits and with no prefixes, that is pretty clear. Tom94022 (talk) 05:47, 27 June 2021 (UTC)

The heading rough bytes is unclear; if you're going to use those numbers, six-bit bytes would be clearer. Is there a word sextet in the literature? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:44, 27 June 2021 (UTC)

Sorry I was referring to the ""roughly xx kilobytes" language used in the prior article edit so I changed the column caption of the table in this talk to try to make that clear. One of the less common meanings of "sextet" is indeed a six bit byte but I don't think for several reasons that we should go there. Tom94022 (talk) 23:00, 27 June 2021 (UTC)