Talk:Count key data/Archive 1

The table of CCW opcodes in Count key data#Initial CKD implementation, IBM S/360 DASD Channel Commands, has a footnote {{refn|Derived from [https://archive.org/details/bitsavers_ibm360refeystem360ReferenceData_662124 IBM System/360 Reference Data (Green) Card]}} that does not show the edition number. Further, it appears^[1] to link to GX20-1703-9, which only includes the 2311, 2321 and 2314. Could you provide a link to the edition you took the table from, preferably one that doesn't require registration?

Note: the S/370 equivalent, System/370 Reference Summary (PDF), Eighth Edition, IBM, February 1989, GX20-1850-7, {{cite book}}: Cite has empty unknown parameter: |sectionurl= (help) drops everything older than the 2305 and adds newer devices through the 9335.Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:24, 4 December 2015 (UTC)

I don't see anything ambiguoous, whats not in the referenced green card should be in the referenced SCU manuals. Tom94022 (talk) 00:46, 6 December 2015 (UTC)

What's ambiguous is the unqualified term green card; there are multiple editions, with substantial differences. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:55, 6 December 2015 (UTC)

OK, I put in an IBM doc number. Tom94022 (talk) 07:05, 7 December 2015 (UTC)

What is more interesting is the 7320 column. Its not in my original spreadsheet and I have no idea how it got into the table. Any idea or comment? I'm going to research it and might remove it. Tom94022 (talk) 07:05, 7 December 2015 (UTC)

Now I see that u added the 7320 here - do you have a reliable source? If so, please add it as with the other DASD. Tom94022 (talk) 07:13, 7 December 2015 (UTC)

In its SCU description manuals IBM has several different categories for its CKD CCWs, of which Control, Search, Read, Write and Sense seems to be the most common. In these DMs IBM does not subordinate or indent Search commands with respect to Write commands nor should this article. Here for example is the table of contents from the 3830-1 Manual

CHANNEL COMMANDS . . . . . . . . . . . . . . . . . . . 15

Control Commands . . . . . . . . . . . . . . . . . . . 15

Search Commands . . . . . . . . . . . . . . . . .. . . 15

Read Commands . . . . . . . . . . . . . . . . . .. . . 15

Write Commands . . . . . . . . . . . . . . . . . . . . 15

Formatting Write Commands . . . . . . . . . . . . . . 15

Update Write Commands . . . . . . . . . . . . . . . . 16

Sense/Test 1/0 Commands

Note Sense is a peer to Write and the others in this manual as it is in every other manual I’ve looked at. IBM states, "On all Search operations, the Channel operates in the Write mode while the storage unit operates in the Read mode" or equivalent in all the DMs I’ve looked at. The fact that the two low order bits of Search command codes are /01 as are the Write command codes is not sufficient to subordinate Search commands to Write Commands in their presentation in this article. If the article discussed the allocation of the two low order bits of the command codes across all of the CCW categories it would then be appropriate to note that Search commands are defined by the two low order bits of /01 which is generically assigned to Write commands but indentation is not justified. FWIW I think adding discussion of the low order bits is beyond the scope of this article so I leave that to another editor. Tom94022 (talk) 01:42, 6 December 2015 (UTC)

From IBM System/360 Principles of Operation, A22-6821-0 through z/Architecture Principles of Operation, SA22-7832-09, IBM has consistently broken down CCW opcodes as:

More information CODE, COMMAND ...

CODE	COMMAND
X X X X 0000	Invalid
MMMM 0100	Sense
x x x x 1000	Transfer in channel
MMMM 1100	Read hackward
MMMMMMO1	Write
MMMMMM10	Read
MMMMMM11	Control

Close

Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:29, 6 December 2015 (UTC)

First, even on the low end channel-attached devices were the norm. Typically there would be at most one integrated adapter beyond that for the console.

Second, despite the claim in the imbedded figure, IBM did not start the new packaging strategy with the 3830 Model 2 (not 3380 model 2); the earlier 2314 B series had a 2319-B1 as head of string with the first 3 drives and a 2319-B2 for each additional 3 drives, and the IFA had a 2319-A1 as head of string. Also, note that IBM didn't settle on "A" for head of string and "B" for additional drives until the 3340.

Finally, if a document came from bitsavers, it is best to give the URL at bitsavers rather than at a mirror, especially one like Historical Narrative of the 1970s, US v IBM, Exhibit 14971, p.1051 that requires registration. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:04, 4 January 2016 (UTC)

To the extent u have improvements I request u just make them in the article (e.g., "Model" vs "model", URL, beginning of A-Unit terminology, etc) rather than raising them in talk. It would save us both time.

U are incorrect regarding the 2319-A1 and -B1 as A-Units, u might try Googling "IBM New Attachment Strategy" After which if u still think they are A-Units as the term came to be defined after the 3330 it is probably worth discussing this in a separate section of this talk Tom94022 (talk) 20:44, 4 January 2016 (UTC)

"To the extent u have improvements I request u just make them in the article ". When I do that you revert them.

" It would save us both time." No, it saves time to discuss them first so that you won't reve4rt them.

"U are incorrect regarding the 2319-A1 and -B1 as A-Units," See

"INTRODUCTION", IBM System/360 Component Descriptions - 2841 Storage Control Unit, 2302 Disk Storage, Models 3 and 4, 2311 Disk Storage Drive, 2321 Data Cell Drive, Model 1, 7320 Drum Storage (PDF) (First ed.), IBM, A26-5988-0, The 2319-B1 attaches to a 2314-B1; the 2319-B2 attaches to a 2319-B1 or another 2319-B2. and "INTEGRATED FILE ADAPTER", IBM System/370 Model 135 Functional Characteristics (PDF) (First ed.), IBM, March 1971, pp. 33–34, GA33-3005-1, the 2319 Disk Storage Model Al (containing three disk storage modules), plus either one of the following devices in the IBM 2314 Direct Access Storage Facility - A Series: 2312 Disk Storage Model Al (containing one disk storage module) 2318 Disk Storage Model Al (containing two disk storage modules). Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:51, 5 January 2016 (UTC)

I do not revert most of your changes, I try to improve them; sometimes I do revert parts of some of your changes. Regardless, see WP:BRD - u have the order wrong. In your case even when I improve, as a courtesy to you, I usually open a talk section.

The discussion of what is an A-Unit is worth its own section as follows. Tom94022 (talk) 19:50, 5 January 2016 (UTC)

Count Key and Data appear in the IBM System/360 Component Description for the DASD devices (A265988-6, October 1968) and I am pretty sure they appear in the announcement edition. The manual describes the DASD track format as a home address field and records comprising a Count field and optional Key and Data Fields. I therefore fail to understand why it this article states the architecture was at first unnamed. Perhaps if we called it a data organization or format for recording data, or something other than architecture? Tom94022 (talk) 20:56, 6 August 2015 (UTC)

That manual is not "the IBM System/360 Component Description for the DASD devices"; it is a manual for specific DASD devices.

I don't see any reference to "count, key, data device" or the like, only to commands with "count, key, data" in their names or descriptions. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:00, 6 August 2015 (UTC)

That manual is for all the DASD devices at the time of the 360 announcement, it says, "All direct access storage devices associated with the 2841 use the same track format" and then goes on to define the records in terms of Count key and data. This article is about "Count, key data" a track format or architecture - not about CKD devices. "CKD device" is a bit of an oxymoron since as u well know the format is in the control unit or controller and not the device. Tom94022 (talk) 01:05, 7 August 2015 (UTC)

For one, there is no need to name something when there is only one. When FBA disks came out, they had to name CKD to distinguish it. More specifically, when was the CKD acronym first used? Gah4 (talk) 02:23, 7 August 2015 (UTC)

Origin of the terms "Count key data"
This section should have been entitled to match the title of the article.

CKD probably came into general usage in the late 1970s or early 1980s to distinguish the track format and associated channel command from those of the then newly announced FBA (Fixed Block Architecture) subsystems. Both acronyms appear in August 1983 in the IBM Service For Consultants - Software. Note FBA was a part of IBM's Future System starting in 1971 and mostly killed by 1975, but FS did partially emerge in 1980 as the S/38 so FBA/CKD probably goes into the 1970s. But the article is not entitled CKD! The track format disclosed for the S/360 DASD at announcement in 1964 has variable length records comprising Count, Key and Data fields. That should be sufficient to date the emergence of "Count, key,data" as terms of computing art. Maybe we should change the lede to such a statement. Tom94022 (talk) 21:35, 7 August 2015 (UTC)

Here is how IBM defines the terms:

It seems to me that we should use a paraphrased version IBM's above definition of Count key data in the article along with a 1964 introduction. Tom94022 (talk) 23:07, 7 August 2015 (UTC)

I was specifically asking about the acronym, but others were asking more generally. I suspect for a long time no-one thought of doing it any other way, so no distinction was needed. So, there are no CKD references before 1994? Gah4 (talk) 23:58, 7 August 2015 (UTC)

A quick search as noted above found both FBA and CKD in a 1983 IBM publication. My guess is the acronym first appeared in the 1970s. Tom94022 (talk) 00:43, 8 August 2015 (UTC)

"CKD" appears in IBM Patent 4,223,390 filed February 2, 1976. It probably appeared in IBM TDB's in the 70s. Tom94022 (talk) 01:00, 8 August 2015 (UTC)

"CKD" appears 30 times in the 6^th edition (Nov 1976) of the Reference Manual for IBM 3830 Storage Control Model 1 and IBM 3330 Disk Storage. Most instances are not indicated as a change from the 5^th edition so it existed therein and possibly existed in the 4^th edition. It did not exist in the April 1971 3^rd edition. This is interesting, but is the coining of the acronym particularly relevant to this article title? Tom94022 (talk) 06:56, 8 August 2015 (UTC)

Maybe or maybe not. The idea was that something isn't really named until it has an acronym. Or the other way, something is really named once it has an acronym. When did it go from three words that happen to go together to an actual name? I suggest when it had an acronym. Gah4 (talk) 07:59, 8 August 2015 (UTC)

Why is an acronym a necessary condition? "Direct access storage devices" were introduce by IBM in 1964 without the acroynm DASD (it is not in the 2841 manual)! The three words were concatenated in some of the very first CCWs such as Write Count, Key and Data which was later abreviated Write CKD. Perhaps we shoud just ignore the date of usage of the acronym issue. What IBM said in its glossary definition above applies to the first instance of Count key data. The title of this article, "Count key data" are the names of the three fields of an IBM variable lenght record and have been so since 1964. Tom94022 (talk) 19:09, 8 August 2015 (UTC)

Yes, it isn't a necessary condition. But it isn't so obvious when the concatenation of the names of the fields turns into a name in itself. As I noted earlier, if there is only one choice you don't need to name it. Gah4 (talk) 23:37, 8 August 2015 (UTC)

First, the relevant question is when IBM started referring to the DASD architecture as "Count, Key, Data", not when they abbreviated it to CKD. To the best of my knowledge that was the announcement of an alternate architecture, FBA.

Second, FBA did not die with the demise of FS; it is still supported by z/VSE and Z/OS, to say nothing of the new support in z/OS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:28, 10 August 2015 (UTC)

I suggested considering the CKD acronym to help track down when the name appeared. That is, the transition from the names of three fields to an actual name. There might have been use of CKD as an abbreviation for the field names earlier, but the acronym for the name should have come after, though maybe not long after, the name. Gah4 (talk) 00:20, 12 August 2015 (UTC)

The reorganization of the History section lost the description of surface defect skipping added with the 3340 and 3350, an alternative to assigning alternate tracks, and of Read multiple count key data.

When IBM introduced the 3340, it offered the Read Multiple Count Key Data command^[1], later available for the older 3330 and all subsequent CKD DASD. The 3340 also introduced the concept of Surface Defect Skipping^[1]. Also, the 3340, 3344 and 3350 were the first IBM disks to have sealed head-disk assemblies.

1. [1]

   Reference Manual for IBM 3830 Storage Control Model 2 (PDF), Sixth Edition, IBM, April 1977, GA26-1617-5

Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:03, 2 September 2015 (UTC)

1. I doubt if defect skipping (or ECC for that matter) is relevant to this article.
2. Without further research I'm not sure if the Read Multiple CKD CCW is sufficiently important to justify inclusion; perhaps it is just one of the several CCWs not covered but subsumed under Other Extensions. If u think its significant, why don't you just go ahead and add it either into Other Extensions, another section or even its own section? Tom94022 (talk) 19:59, 2 September 2015 (UTC)

ECC is tranparrent to the programmer, but skip displacement affects the CCW repertoire.

With all due respect to the be bold admonition, if it's a choice between discussing the material first or having to reinstate it after an arbitrary deletion, I'd rather discuss it first. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:22, 9 September 2015 (UTC)

https://en.wikipedia.org/w/index.php?title=Talk:Count_key_data&action=edit&section=18#

1. We don't cover many of the CCWs in this article, so I am not sure why Read Multiple CKS makes the list, particularly since the un-referenced assertion is that it was used mainly for backup. Can anyone provide a reference? I left it in anyhow but someone please explain why this one over the many left out.
2. All IBM disk drives prior to the 2311 were "sealed" and "non-removable" The 3340 had a door that opened to the world which IBM called sealed but it wasn't. The 3350/3334 were back to the past. All of this is interesting but hardly belongs in this article since it has nothing to do with CKD other than coincidence.
3. Please provide a reference to how "skip displacement affects the CCW repertoire." To the best of my knowledge it is totally transparent to the channel program. More so the ECC which at least in the early implementations required retry effecting performance but not execution. Tom94022 (talk) 21:07, 13 September 2015 (UTC)

1. We don't cover CCW opcodes in vacua, but we do cover new features.
2. From IBM 3340 direct access storage facility, "The disks, the disk spindle and bearings, the carriage and the head-arm assemblies were incorporated into a removable sealed cartridge called the IBM 3348 Data Module."
3. Sorry, it's not the CCW repertoire but the HA format and the sense data. See IBM (May 1980). IBM 3880 Storage Control Description (PDF). Fourth Edition. pp. 4–39, 4–40, 9–6, 10–7. GA26-1661-3. I never mentioned the ECC. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:24, 17 September 2015 (UTC)

1. We do not nor should not cover each and every new CCW and I question whether Read Multiple CKD is significant enough to be included? Why is it any more significant than say Set Paging Parameters and Discard Block also among the several new or enhanced CCWs not covered?
2. As I said IBM called it "sealed," but the 3348 has a roll top door that was opened to the environment during load and unload so it's hard to call it sealed in the same sense as the later HDAs were factory sealed. Funny thing is I can't find a single photo of the door, every one is from the other side. On the other hand, why weren't at least some of the IBM pre-2311 HDDs or other vendor's fixed media disk drives "sealed". But more importantly, what does this have to do with this article? If any place it belongs in History_of_IBM_magnetic_disk_drives#IBM_3340 or Hard disk drive
3. We do not nor should not cover each and every detail of the many CCWs and I question whether defect skipping is relevant to an article about count key data any more so than ECC and the many other technical details of IBM DASD and its controls. The first 3340 Director, the 3830-2 indeed does mention "defect skipping" 6 times in 99 pages but it also mentions ECC 16 times. Both effect the track format so why one and not the other in this article? More interestingly the 3340 manual says, "Data module capacity is not changed by defect skipping and the user is unaware of defects." So why put it in this article, perhaps Hard_disk_drive#Error_rates_and_handling. I suppose u could greatly expand Section 1 Overview to go into all of the variations of the track format including not only defect skipping, but ECC, gap sizes, etc. but I think that would be overkill. Tom94022 (talk) 00:12, 18 September 2015 (UTC)

The article is about count key data, an IBM track format and a set of associated channel command words and I suggest we produce a better article when we keep to the important parts of the subject. Tom94022 (talk) 00:12, 18 September 2015 (UTC)

1. As I wrote, we do cover new features in Count key data even though we don't describe every associated CCW. However, I believe that it would be better to move all of the historical data into a History section.
2. How is ECC relevant? What makes skip defect relevant is that it is visible to the programmer. See Reference Manual for IBM 3830 Storage Control Model 2 (PDF), Sixth Edition, IBM, April 1977, GA26-1617-5 in addition to the reference that I already provided. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:59, 20 September 2015 (UTC)

Is Defect Skipping really visible? All the programmer really can't do anything about it other than read HA before writing HA so as to not destroy the information. ECC is just as "visible" in that the programmer (or system) takes it into account as part of the track capacity calcuations. Tom94022 (talk) 23:19, 20 September 2015 (UTC)

Read Multiple CKD is not in GA26-1617-3, the March 1974 3830-2 Ref Manual but that version does include the 3340 so Read Multiple CKD was not introduced with the 3340 but was added sometime later and when added it likely supported all attached DASD, not just the 3340. So unless there is other evidence most of this section in wrong. Furthermore, the cited -5 version (April 1977) does not include Read Multiple CKD among the many Director features listed in the manual; its just one of many CCWs not covered in any detail in the article so I again ask why a separate section; at most it should be in the Others section as an example just like Unconditional Reserve. BTW, my guess is that it was introduced with the 3350 not the 3340 and applied to all DASD at the time of its introduction. But that doesn't make it worth having its own section. So unless there is some new evidence I suggest we delete the section. Tom94022 (talk) 07:33, 21 September 2015 (UTC)

That's an earlier edition than the one that I cited; it's possible that Ream Multiple CKD was inadvertently omitted. Reference Manual for IBM 3830 Storage Control Model 2 (PDF), Sixth Edition, IBM, April 1977, p. 44, GA26-1617-5 does list the command as supported for the 3340.

Director? IBM didn't use that term until the 3880. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:25, 21 September 2015 (UTC)

Your reference shows Read Multiple CKD support on 3330, 3340, 3344 and 3350 so there is no justification for the statement "When IBM introduced the 3340, it offered the Read Multiple Count Key Data command, ..." While it is highly unlikely that the command was omitted from the -3 version that still doesn't justify introduction with the 3340; it could just have easily been introduced with the 3333 on the first 3830-2. BTW, I still think it likely support of the 3344/3350 by the 3830-2 was the point of introduction. Regardless, its all speculation and doesn't belong in Wikipedia.

IBM used the term director with the 3830-2. When they split the storage contol unit it to two pieces they named them Director and Controller respectively and the interface between was the DCI (Director Controller Interface).

I've now compiled and will shortly publish a list of 29 features/facilities that IBM used to describe new and old features of the various Storage Control Units/Storage Directors. Read Multiple CKD is not cited as such in any of the reference manuals so why should we feature it in this article? Tom94022 (talk) 00:22, 22 September 2015 (UTC)

While a buffer is required for both ECKD and speed matching and in the case of the 3880 I guess it was the same buffer feature. Regardless it is a non-sequitor to conjoin them without evidence. The evidence is that the SMB was offered in the 3380 without the ECKD CCWs (see 4th edition of manual) BTW, a larger buffer could also be used for a cache, SMB and ECKD, as I suspect was done in the caching models. Tom94022 (talk) 20:29, 6 August 2015 (UTC)

Do you have a link for the fourth edition. My evidence is that the ninth eclearly states that the SMB is a prerequisite for the DEFINE EXTENT and LOCATE commands.

Actually, I don't see how the SMB could wok without DEFINE EXTENT. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:42, 6 August 2015 (UTC)

I located the fourth edition at https://ia801003.us.archive.org/11/items/bitsavers_ibm38xx388orageControlDescriptionMay80_10500973/GA26-1661-3_IBM_3880_Storage_Control_Description_May80.pdf, and it contains the text Five additional commands, Locate Record, Define Extent, Write Update Data, Write Update Key and Data, and Write CKD Next Track, are used to support attachment of the 3380 through the speed matching buffer feature. Information'related to these commands and to the operation of the 3375 and the 3380 using the CKD command set will be provided in a later edition of this manual.

is that enough evidence for you? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:58, 6 August 2015 (UTC)

No it is not. As u quoted, the manual does not provide information operating the 3380 with the CKD command set (this includes ECKD since it seems IBM considers them CKD commands). Normal CKD commands do require the SMB in a 3380 operating on slow channels, which means one use of the buffer is used for speed matching and IBM apparently so named it. Slower DASD without ECKD do not require a buffer for speed matching and the SMB is not supported for them (Table on p. 1-3 and elsewhere) but do require a buffer for ECKD which in this case happens to be named the SMB but does not do any speed matching. I don't dispute a buffer is necessary for ECKD, and the buffer feature used in the 3880 was unfortunately named the SMB I think you improperly conjoin speed matching with ECKD. Tom94022 (talk) 00:59, 7 August 2015 (UTC)

Furthermore, the next generation 3990 SCU does not have a SMB; it doesn't even have an explicit buffer! Yet it supports synchronous parallel channel operation (traditional CKD) for 3390 up to 122 meters and nonsynchronous operation (ECKD) beyond [source: IBM 3990 Storage Control Introduction]. A buffer can have many uses, matching high speed drives to slower channels is just one but it is still a synchronous channel, albeit with lots of overruns. Nonsychronous operation also requires a buffer and it is unfortunate that IBM chose to name the optional buffer in the 3880 as the SMB but that is not what the buffer is doing for ECKD - it is buffering at least a full track to perform multiple CCW type operations in the CU freeing the channel. Speed matching only operates during the data transfer portion of one CCW, overrunning when the channel can't keep up. but the channel reamins committed. BTW, speed matching is inherent in nonsynchronous operation since at least a full track is buffered so trannsfers to/from the channel can take place at any speed. In other words, as I see it, speed matching is one of several funtions of the buffer required for ECKD so it is a mis-statement to conjoin them. Tom94022 (talk) 23:14, 8 August 2015 (UTC)

Would a discussion of service-in^[1] for a block multiplexing controller be TMI here? In IBM System/360 architecture#Input/Output?

Note: this manual does not explicitly mention the block multiplexor channel but reading between the lines ... Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:27, 9 September 2015 (UTC)

Yes IMO it would be TMI. May I suggest generic channel material belongs in IBM System/360 architecture#Input/Output and not in this article which is about DASD CKD CCWs, a subset of IBM System/360 architecture#Input/Output. Tom94022 (talk) 16:55, 15 September 2015 (UTC)

I want to expand the information in Count key data, and am not sure that the present organization is appropriate. I propose changing Count key data#Overview to Overview and History, adding a CKD Details section and changing Count key data#Extended count key data to ECKD details. Does that sound reasonable? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:14, 3 August 2015 (UTC)

Sounds reasonable. If you are going to do a major rewrite, then maybe u should get into the reasoning behind enhancing synchronous DASD (traditional CKD) with nonsychrnonous DASD (Extended CKD). There were cached control units with CKD. A cache is a necessary condition for ECKD but the real purpose of ECKD was to eliminate the tradtioinal sychronization between the channel, control unit and device during the exectution of a channel program thereby allowing longer physical distances, smaller gaps and in some cases higher performance (mainly at longer distances and with smaller gaps) but in most existing installations lower performance. See "Introduction to Nonsynchronous Direct Access Storage Sybsystems, GC26-4519. Tom94022 (talk) 19:14, 3 August 2015 (UTC)

I've started restructuring. If you have any announcement dates, please revise the text in Count key data #History to reference them. Thanks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:48, 5 August 2015 (UTC)

Are u putting in too much detail when u count the number of disk drives, particularly since the distinction between CKD and ECKD is a control unit issue not a drive issue and some control units supported both. In particular, didn't the 3880 start as a CKD SCU but then in a later model support both? Also, the distinction between the Selector Channel and the BMux Channel is not particular relevant to this article since both supported CKD. The issue of disconnecting is an interesting issue but is it particularly relevant to this article? Tom94022 (talk) 20:08, 5 August 2015 (UTC)

Keep in mind that the number of drives is in the History section, where it is appropriate.

The 2305 introduced Set Secord and Multile Requesting, which require a block multiplexor channel for their documented operation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:15, 6 August 2015 (UTC)

Looking a bit further into this, u should note that IBM does not make the same distinction u make between CKD and ECKD at least when u look at the 3880 manual - ECKD does not appear in the manual and it's required CCWs are just listed as CKD CCWs. ECKD is not even listed as a feature. Consider the RPS CCWs, they were not in the original CKD command set, but added later (with 3830 in 1970) but they are listed as a feature in the 2880 manual unlike ECKD. Here is the list of 2880 features from the manual (Chapter 5 TOC) :

The 3880 started out as a controller for CKD with an optional Speed Matching Buffer (SMB), but that was the origin of ECKD. I need to move thye relevant text from Overview to History.

The same applies to the term CKD; the architecgure came first, the name came later.

The list of features includes things that have nothing to do with the 2880, e.g., record overflow. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:15, 6 August 2015 (UTC)

• Multitrack
• Record Overflow
• Rotational Position Sensing
• Channel Program
• Command Retry
• Channel Switching
• Channel Selection Switch
• Remote Switching
• Statistical Usage and/or Error Recording Error Detection and Logging
• Block Multiplexing
• Speed Matching Buffer for 3375
• Speed Matching Buffer for 3380
• I/O Operation for Speed Matching Buffer

I think only RPS has CKD Article implications; the rest might appear in an IBM channel article. My 2 cents :-) Tom94022 (talk) 21:19, 5 August 2015 (UTC)

Multiple Requesting also belongs in the article. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:15, 6 August 2015 (UTC)

At this point I disagree with your proposed organization - ECKD is a subset of CKD and just one of several enhancements to CKD over its many years; it does not deserve a separate section. There should be one history section, perhaps with separate sub sections for major enhancements such as RPS, ECKS, perhaps others. The detail sections belong in the history section. Tom94022 (talk) 21:04, 6 August 2015 (UTC)

*Requires subsystem comprising Channel, Control Unit and device

====== Initial Impementation ======

====== Disconnected command chaining, command retry ====== ====== RPS ====== ====== ECKD ======

====== Other CCWs ======

• Paging/Caching
• Dianostic

Comments? I'm going to start implementing immediately. Tom94022 (talk) 23:23, 13 August 2015 (UTC)

This turns out to be a major reconstruction which will take some time. I've moved the prototye to a Sandbox and would appreciate help and comments there. Tom94022 (talk) 20:31, 17 August 2015 (UTC)

Define Extent? :-) May I suggest we define the extent of this article to comport with the IBM glossary definition of "Count key data;" namely track format and associated CCWs. The definition above is from the 3990 manual circa 1990 but it appears the same definition exists today in several IBM glossaries. If so the article would:

• have more emphasis on the CCWs; particularly the significant enhancements from the 40 or so in the original release thru to the at least 72 supporting the 3390. RPS and ECKD are two, there maybe more
• have less emphasis on hardware. This is not an article about IBM channels, just the CKD track format and CCWs. Hardware might be mentioned, as for example, Command Chaining and Command Retry, but details should be in an IBM channel article. With regard to the drive statistics, what number was released with each system is not particularly relevant, they all supported CKD but only two supported ECKD. Likewise which device initially supported a CKD enhancement in only relevant for its date of support.

I've started making such changes. Comments? Tom94022 (talk) 20:59, 10 August 2015 (UTC)

Please provide links or quotes for the IBM definitions of CKD and ECKD. I believe that it would be useful to include them in the overview. Also, you referred to them as "above" but I don't see them there.

I'm planning on adding sample CCW chains for CKD and ECKD, but am not sure whether to provide one each or more.

If someone as the announcements a timeline for the various devices and features would be nice. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:54, 11 August 2015 (UTC)

I just noticed that you deleted some of the history. I can see rewording things, but new facilities like multiple allegiance are important and belong in the history section. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:03, 12 August 2015 (UTC)

I don't have any problem with your adding in Multiple Allegience, but would appreciate your doing so in accordance with the newly proposed organization below. BTW, I have to think about it, but MA might just be a part of a section called Multiple Pathing or maybe not :-) Tom94022 (talk) 23:26, 13 August 2015 (UTC)

Multiple Allegience is just another name for Dynamic Path Selection . Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:06, 19 August 2015 (UTC)

I cannot find the use of the term "multiple allegiance" in any 3880 or 3990 SCU documentation. I do find this definition of MA and as near as I can tell this does not happen in any CKD subsystem. I am covering Dynamic Pathing in my reconstruction, but it won't have MA as defined by IBM in the reconstruction. Tom94022 (talk) 01:39, 20 August 2015 (UTC)

Are u sure about Multiple Allegience being introduced with the 3880? I've searched without success both the 3380 and 3390 manuals for descriptive material. What I did find is Dynamic Path Selection introduced with the 3880 for the 3380 only. As near as I can tell MA postdates physical CKD devices (i.e. not in 3990/3390). Also MA may apply to other than DASD (not certain). If either is true then perhaps its discussion belongs in the Channel I/O article rather than here. Tom94022 (talk) 19:43, 17 August 2015 (UTC)

Multiple Allegience is a control unit/device facility, not a channel Facility. It definitely doesn't belong in Channel I/O, any more than RESERVE and RELEASE do. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:06, 19 August 2015 (UTC)

I guess we disagree about Reserve/Release since it allows sharing across channels. AS I understand it MA is an implicit sharing so I think it also belongs in such a section. What is the first control unit/device subsystem that supported MA? Tom94022 (talk) 01:39, 20 August 2015 (UTC)

Talk:Count key data#Initial CKD lists the 2303 ^[1] but not the 7320 ^[2]; the 7320 came first. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:19, 2 September 2015 (UTC)

True but a detail that I chose to overlook. If u think it needs to be added go ahead, but I would suggest in be done as a note to the 2303 rather than as an additional device consistent with the 2841 manual dropping the 7320. Tom94022 (talk) 19:45, 2 September 2015 (UTC)

If the intent was that it be a description of the original S/360 DASD options, then the 2303 doesn't belong there, since it was not in the original lineup at all. If the intent was that it cover all S/360 DASD then it needs to be expanded and reworded. Which, if either, did you have in mind? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:30, 9 September 2015 (UTC)

The following table summarizes the "features" asserted by IBM in the referemce manuals for its several DASD CKD Storage Control Units/Storage Directors. It is offered as a guide for what might be included in this article.

Notes

1. In the first reference manuals the only "feature" was the optional two channel switch. In later manuals IBM separately described standard and optional features. In the 3390 manual the term "facilities" appears to have been used for what otherwise one would call features.
2. CCW means this feature is prinicipally implemented via CCWs with little or no specialized hardware
3. HDW means this feature is prinicipally implemented in hardware with little or CCW visibility
4. X means this feature explitily called out in a reference manual
5. * means this feature known to exist in Control Unit/Director but not found explicitly as a feature in a manual
6. ? means uncertain as to existance mainly due to lack of reference manuals.

Other editors please feel free to edit the table, particularly to fill in the question marks.

FWIW, I don't think everything above needs be coverred in this article, after all, the manuals used to generate this list amount to hundreds of pages and some of the "features" have nothing to do with CKD, e.g., Usage Meter. However, I do question the inclusion in this article of much not explicitedly categorized by IBM as a feature for these CKD DASD SCUs/Directors Tom94022 (talk) 18:13, 25 September 2015 (UTC)

1. IMHO we should either not mention history at all or should give a full picture of the CKD history. Note that at least one of the CCWs not explicitly defined as part of a facility forms the nucleus of an entire manual for z Architecture.
2. Some of the features depend on the device rather than the controller, e.g., Write Special Home Address Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:00, 29 September 2015 (UTC)

1. The word history does not appear in the article so I am not sure what your point is.
2. I don't think any feature is solely dependent upon the device, that is upom a B box, but but even if it was so what? Tom94022 (talk) 00:32, 30 September 2015 (UTC)

All of Count key data#Initial CKD implementation through Count key data#Beyond System/370 deal with history; how is it relevant that they don't use the word? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:35, 30 September 2015 (UTC)

I still don't understand your point about history, there are s/370's running today and as noted in Count key data#Beyond System/37056 0f th 83 DASD CKD CCWs are emulated on today's IBM mainframes. Sounds pretty current to me. If u think a feature is important and not covered why not just add it instead of these somewhat cryptic comments? Or if u think it might be controversial, then propose it here and it can be discussed. Tom94022 (talk) 22:22, 1 October 2015 (UTC)

History is a sequence of events, often presented with background and causes. The sections that I listed gave a history of CKD, and as such I believe that they belong in a history section. I also believe that there is a need for a more in depth description of various features, unrelated to when and how they appeared, that describes how to use them. It is in that second section that I believe there is a need for sample channel programs.

I don't know of any S/370 running today outside of a museum.

I have no idea what you would consider controversial. Given that, I'd just as soon discuss all proposed changes before investing time in them. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:51, 7 October 2015 (UTC)

I still don't understand what u mean or are proposing with regard to CKD "history." Please point to "The sections that I listed"; maybe that will help. FWIW, in the earliest draft rewrites, what are now sections 3 thru 9 were subsections of a "History" section but that made the article look unbalanced (no other subsections) so I promoted them; except for Section 9 they are in chronological order. Most of them have introduction dates embedded so in a sense they already are a "sequence of events" just not explicitedly identified as such. If you have no idea what might be controversial then why don't u just go ahead and edit the article. If you want to do a major rewrite, then I suggest u do it in a sandbox (as I did) and give us editors time to review and suggest changes. Tom94022 (talk) 17:04, 10 October 2015 (UTC)

"I still don't understand what u mean or are proposing with regard to CKD "history."

I'm proposing to put the history back under the heading History and to reinstate the Technical details section.

"Please point to "The sections that I listed";"

All of Count key data#Initial CKD implementation through Count key data#Beyond System/370

"If you have no idea what might be controversial then why don't u just go ahead and edit the article."

Because I don't want to spend time writing text that someone else will summarily delete, so I'd rather discuss it first, as I've already explained.

I don't want to do a major rewrite, but I do want to add technical details to a new section. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:20, 13 October 2015 (UTC)

I've started on a Technical details section in User:Chatul/Sandbox/Count key data. I don't plan to describe every CCW, but rather to describe related groups. In particular, I don't plan on describing the commands that are only for CE use. If anyone has free time I'd appreciate some wordsmithing, but I will eventually flesh it out. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:02, 16 October 2015 (UTC)

Now I understand.

FWIW, when I started into this article I accepted the distinction between "Basic CCW commands" and "ECKD Commands" but the more I researched the more it became clear that IBM represented ECKD as just a subset of CKD, perhaps more extensive than RPS but subset none-the-less. The article will benefit from sample channel programs in each of the subsections (that is Initial CKD Implementation through Beyond System/370, inclusive) but I think adding a new "Technical details" section with subsections more or less corresponding to the already existing sections would be redundant and/or POV. Why don't u just add sample channel programs within the existing subsections and if u think more technical details are needed, add them there also? Why do the "technical details" have to be in separate parts of the article from what u call "history"? Bottom line, the separation of this article into separate "CKD" and "ECKD" sections seems to be a distinction without substance for this article. Tom94022 (talk) 05:33, 18 October 2015 (UTC)

1. The distinction between basic CKD and ECKD is clear; ECKD uses DEFINE Extent and Locate. That's consistent with IBM usage.
2. The existing sections you referred to deal with history, for which presenting in chronological order makes sense. It makes no sensed to split up technical details of related commands just because they were introduced on different dates. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:01, 20 October 2015 (UTC)

1. The same distinction can be made about each enhancement to CKD, e.g. RPS uses a new command and channel features. There is no justification for splitting ECKD technical details out separately over all other enhancement's technical details. The term "basic CKD" is an artificial distinction approaching POV.
2. The existing sections deal with features of CKD, they just happen to be in chronological order. I'm not sure what technical details need to be spit up to put them into the current structure. Care to give an exmmple? Tom94022 (talk) 22:16, 20 October 2015 (UTC)

Those sections don't "just happen": to be in chronological order; they are a redacted version of the original History section. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:47, 25 October 2015 (UTC)

Redacted? The new sections are substantially larger than the original History section and contain material not present therein. One or two errors have been removed and there has been some rearrangement, but other than that there doesn't seem to be anything "redacted". But if u think something is missing, please add it. Tom94022 (talk) 07:30, 26 October 2015 (UTC)

What I want to add are the headings History, Technical Details and Sample channel programs. Can I do so without your deleting them? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:50, 30 October 2015 (UTC)

You are suggesting an organization that in the end would look like this

1 Overview

2 IBM DASD I/O

3. History

3.1 Initial CKD implementation

3.2 Rotational Position Sensing

3.3 Defect Skipping

3.4 Extended CKD

3.5 Caching

4. Technical Details

4.1 Initial CKD implementation

4.2 Rotational Position Sensing

4.3 Defect Skipping

4.4 Extended CKD

4.5 Caching

5. Sample channel programs

5.1 Initial CKD implementation

5.2 Rotational Position Sensing

5.3 Defect Skipping

5.4 Extended CKD

5.5 Caching

6: etc It seems to me that it is more informative to put technical details and/or sample channel programs under the specific features rather than the way you propose. Whereas the current structure readily allows the information to be added to current sections as appropriate, as for example:

1 Overview

2 IBM DASD I/O

3. Initial CKD Implementation

3.1 Technical details (if appropriate)

3.2 Sample channel program (if appropriate)

4. Rotational position sensing

4.1 Technical details (if appropriate)

etc

etc

It suggest that this latter organization puts like things together and thereby improves the article. So yes I will probably delete any three "new" first level sections, "History", "Technical details" and "Sample channel programs" in favor of putting such information within the appropriate existing feature sections. Tom94022 (talk) 02:05, 2 November 2015 (UTC)

You claim "You are suggesting an organization that in the end would look like this", despite the facts that I have repeatedly corrected you and that the text in User:Chatul/Sandbox/Count key data#Technical details is not organized that way, e.g., Sense I/O and Sense I/O Type are grouped together. I want a section on history, in chronological order and a section on technical details organized functionally, not chronologically. Further, I see no reason for Count key data#IBM DASD I/O to be a top level section rather than under Count key data#Overview.

1. Overview
   1. IBM DASD I/O
2. . History
   1. Initial CKD implementation
   2. Later S/360 DASD
      1. Rotational Position Sensing
   3. 3830
   4. 3830-2
      1. Surface Defect Skipping
      2. Multitrack
      3. Sense I/O Identification
   5. 3880-1, 2, 3 and 4
      1. Extended CKD
   6. 3880-11
   7. 3880-13
   8. 3990
      1. Caching
      2. Remote Copy
3. Technical Details
   1. S/360 I/O
   2. Basic CCW Commands
      1. Sense Commands
      2. Set File Mask Command
      3. Seek Commands
      4. Search Commands
      5. Shared DASD Commands
   3. ECKD Commands
   4. Sample Channel Programs

This needs to be fleshed out, but it's the direction that I was going in my sandbox. As part of that I plan to separate RESERVE and RELEASE from the other Sense commands. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:33, 4 November 2015 (UTC)

As I said before, your distinction between "basic CKD" and "ECKD" is a distinction without support in the IBM documentation. ECKD is just a subset of CKD.

Although u use different names and groupings in the subsections of your "History" section and your "Technical details" section, they are in fact highly parallel which again I think should be together. Examples of yr proposed subsections that are highly correlated and IMO should be in one section or subsection:

• "Initial CKD implementation" in History (yr 2.1) and "Basic CCW Commands" in Technical Details (yr 3.2)
• "Later S/360 DASD" in History (yr 2.2.1) and "RPS" which should be in Technical Details but is not present in your outline. I suspect u consider this just another "basic CCW Dommand" (yr 3.2 and/or 3.2.3) which is POV but not supported in any IBM documentation I've found.
• "3830-2" in History (yr 3.4) and "Defect skipping" which should be in Technical Details but is again omitted and really doesn't fit except maybe in 3.2.1).  ::*"IBM DASD I/O" (yr 1.1) vs. "S/360/ I/O" (yr 3.1)
• U may recall I initially removed Defect skipping from the article as not particularly relevant to CKD but then added it back in when it became apparent there were significant CKD invocations much later. Which BTW makes the current organization not exactly historical and points out a problem with your proposed organization.
• 3880-11" and "3880-13" in history (2.6 and 2.7) and "Caching" (yr 2.8.1) as a subsection of "3390" also in History with nothing in "Technical details". This is of course historically inaccurate. Shouldn't there be Technical details on Caching? Again since caching was enhanced over time a single section on this feature of CKD makes more sense than trying to organize it in a purely historical sequence.

Shouldn't each feature have its own set of sample programs? Why do u subsume all under "Technical Details?"

Why separate Reserve and Release from other sense commands; they were in the original CKD CCW set and enhanced once.

Your proposed "History" section is an incomplete list of some Storage Control Units and no integrated attachments. Some of these Storage Control Units introduced new CKD features but some didn't. Listing of features as disclosed by IBM is a more meaningful. The introductory SCU is already included in most if not all feature sections. It think the feature is far more important as a section heading than a particular SCU Model

This endless dialog seems to be driven by your desire to distinguish "basic CKD" from ECKD. Why don't u just try and add Technical Details and Example Channel Programs to the ECKD section of the existing article? Tom94022 (talk) 07:10, 5 November 2015 (UTC)

Don't take this as agreement with the proposed structure, but why leave out Read, Write and Control Commands from 3.2, "Basic CCW Commands?" In the current article they are coverred in Initial CKD implementation. Why have two sub-sections on the same topic?

I suppose if the history of the hardware is important we could have a hardware history section listing the models of SCUs and introduction dates but this might ignore integrated attachments and possibly overlook features introduced as enhancements to an existing model. That's more or less what IBM tried to do on their summary cards separately for S/360 and S/370. It's a fairly big project to consolidate and I'm not sure it is worthwhile.

I see your point about the "Overview" section, but rather than subsuming IBM CKD DASD I/O I changed its name to "CKD Track Format" to be consistent with the lede. I supose there could be one Overview Section with two subsections, one on the track format and one on the I/O that implements the commands for that format.

Again may I suggest if we want to move forward why son't you just add Technical details and an Example channel program to the ECKD section. I'm doing it in other sections within the existing structure Tom94022 (talk) 18:01, 5 November 2015 (UTC)

There is material missing from the sandbox because it is a sandbox; I already said that it need to be fleshed out, and that applies equally well to the outline I presented.

IBM does in fact use the term "ECKD mode"

I don't accept your claimed parallels between history and technical details, and several items in the list have nothing to do with claimed parallels. In particular,

1. "Initial CKD implementation" does not include, e.g., Sense I/O ID.
2. "IBM DASD I/O" is information specific to DASD; "S/360/ I/O" is intended to provide general S/360 architecture prior to going into details specific to DASD.

In general, I did not include in the outline new interfaces that did not affect DASD programming because historically you have deleted such material. If you agree that it belongs in history then I will be glad to add it. It does not belong in technical details.

The SMB of the 3880 introduced a buffer that wa only used for the life of a channel program; that's quite different from a cache that retains data across channel programs.

I think that is is long past time to request mediation. The primary disagreements are

1. Whether to confine historical data to a section labeled History.
2. Whether presenting technical features in the sequence of their announcement makes sense.
3. Whether to distinguish basic CKD from ECKD in the structure. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:36, 6 November 2015 (UTC)

The usage of the term "ECKD mode" suggests to me that ECKD is a mode of CKD, that is just another feature, aka, asynchronous operation. It is the same IBM CKD channel that can interoperate in either a synchronous or an asynchronous mode.

I think we agree that hardware features that have little or no CCW implications, e.g., usage meter, remote swithch, do not belong in the article, see Count_key_data#CKD_Features_Per_IBM.

The 3380-13 certainly cached as did the -23. Arguably the paging of the -11/21 is a form of caching.

What I find strangely inconsistent is the insistence on separate sections for some features, in particular ECKD, but are willing to combine them all in one for others, e.g. RPS. Rather than deal with hypothecticals, why don't u go ahead and an flesh out any two of your "History" and "Technical details" subsections in your sandbox and then I will show u how I think they can be combined in the existing structure. The obvious pair is yr 2.5/2.5.1 paired with 3.3..

Go ahead and request mediation if u must; I think the answers to yr questions are pretty obvious:

1. There is no explicitly historical data in the current structure
2. They can be any any order although seems to make sense to place the initial set of technical features first and anythng with dependancies in that order.
3. The is no basis for inventing a "basic CKD" category.

In my view we are dealing with a two sided matrix, hardware models versus features. Either can be in chronological order but there are onhy one set of details for each feature. Your favorite ECKD was a feature on about 13 model and submodel Directors/SCU; to me it makes a lot more sense to have a single section on ECKD and only mention the introductory Director rather than listing 13 models in a history section with minimal techbnical details and then having a separate Technical details section on the feature. Organizing the article by features avoids duplication and deals better with the situation where a feature is enhanced over time. But in the end it seems to come down to your insistance that the one feature ECKD is somehow different than all the other features added to CKD over time. That position is simply not supported in IBM documentation I can find. Tom94022 (talk) 23:44, 6 November 2015 (UTC)

"History" is now completely covered in the section IBM's CKD DASD subsystems with its links to History of IBM CKD Controllers. It might be improved by, for example adding in something along the lines of the table in Count_key_data#CKD_Features_Per_IBM interlinked with appropriate sections in this article but that's for future editors.

Sections four thru eight are enhancements to the initial CKD implementation and already have some technical details; they can be improved with additional technical details and maybe even sample channel programs but there is no reason to subsume them all under a "Technical details" super section. They are more or less in chronological order but what else, alphabetical? Both yr History and Technical details are so ordered

I really don't understand what really distinguishes information that would go in "History" from information that would go in "Technical details." Again I suggest u complete a proposed ECKD pair, that is, the proposed 2.5/2.5.1 paired with 3.3? Tom94022 (talk) 18:39, 7 November 2015 (UTC)

Repeating n untruth dos not make it true. My Technical Details section is not and never has been in chronological order, nor should it be. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:16, 17 November 2015 (UTC)

Hmmm - Basic didn't come before ECKD; I sure thought they did. Again, I really don't understand what distinguishes information that would go in "History" from information that would go in "Technical details." I do suggest u complete a proposed ECKD pair, that is, the proposed 2.5/2.5.1 paired with 3.3? as an illustration of what is the different information. I won't be a waste of your time and it might help Tom94022 (talk) 07:39, 17 November 2015 (UTC)

"Hmmm - Basic didn't come before ECKD"; please explain what you're trying to say.

"Again, I really don't understand what distinguishes information that would go in "History" from information that would go in "Technical details."" Yet again, history is events in chronological order and is not intended to be a guide to the use of any particular technology; technical details are organized functionally.

"I do suggest u complete a proposed ECKD pair, that is, the proposed 2.5/2.5.1 paired with 3.3? as an illustration of what is the different information."

Are you referring to 5. 3880-1, 2, 3 / 4 1. Extended CKD paired with 3. Technical Details / 3. ECKD Commands? They serve different purposes. 2.5.1 should only have enough detail to put the history in context. 3.3 should have a more extensive discussion of ECKD programming, including things that didn't exist on the 3880, e.g., CFW, DFW. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:52, 19 November 2015 (UTC)

This new article, History of IBM CKD Controllers lists in chronological order all IBM CKD controllers. Some introduced new CKD features, some improved existing features, some were cost reduced integrations and some were just repackaging. The features of each controller are described in each controller manual, summarized for the s/370 contollers in IBM System/370 Reference Summary GX20-1850-7 and in this article. It would make no sense to add features to this new article. We are dealing with two sides of a matrix, models on one side and features on the other side. At the intersection there are technical details. This article does not need sections for both sides of the matrix. Tom94022 (talk) 22:53, 6 November 2015 (UTC)

I suppose in the interest of completeness someone could put IBM Controller Features into the new article "History of IBM CKD Controllers" At this point I have other things to do. Tom94022 (talk) 18:21, 7 November 2015 (UTC)

1. I don't see the justification for a separate article.

2. The list is incomplete.

3 All of Count key data#Initial CKD implementation through Count key data#Beyond System/370 belong in the history. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:28, 19 November 2015 (UTC)

1. Not that it has to be justified, but it is certianly consistent with the way CKD DASD are treated; that is, a separate article

2. If the list is incomplete why don't u just add to it instead of leaving this somewhat criptic comment? FWIW there is a reliable IBM source for the System/370 part of the list and I am pretty sure there are no missing s/360 SCUs

3. I am still waiting to see what belongs to tecnnical details as opposed to history Tom94022 (talk) 07:16, 20 November 2015 (UTC)

2. Off the top of my head the list is missing he more recent 3990 models. Since you stated that it was complete, ...

3. How many times do I have to answer the same question? Technical details should cover the programming of CKD DASD in a fashion organized by function rather than by date and in more detail than is appropriate for history. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:29, 24 November 2015 (UTC)

2. I added the 3990-6, any more? If u have any it would be appreciated if you would be less criptic.

3. Many I again point out that the current organization is by function as well as time and ask that u give an example using ECKD? Tom94022 (talk) 20:04, 25 November 2015 (UTC)

2. I know that there's a 3990-9; I don't have a complete list.

3. The current organization is not by function, e.g., Count key data#Initial CKD implementation lumps together unrelated facilities. In fact, the very title Initial CKD implementation suggests that it is intended to be historical. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:31, 25 November 2015 (UTC)

The IBM S/360 DASD Channel Commands table in Count key data #Initial CKD implementation is confusing. Status Modifier is a CSW bit, not a CCW opcode, so what do the "Set Status Modifier" and "No Status Modifier" row labels refer to, how can there be CCW opcodes associate with them and why does "Set Status Modifier" occur twice? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:13, 19 November 2015 (UTC)

The entries relate to Continue Scan CCWs; apparently some text was ommitted in converting the IBM card's pdf table into a Wiki table. Thanks for spotting this. Since u apparently are an IBM channel programing expert perhaps u can make the corrections directly? Otherwise I will reserch and correct in a bit. Tom94022 (talk) 02:16, 20 November 2015 (UTC)

The table has now been fixed to agree with the IBM reference card. This table like the reference sometimes needs to concatenate the first and second columns to get to the proper name of a CCW, as in Read Home Address and Write Home Address. So the three commands of concern are "Continue Scan, Set Status Modifier" /35, Continue Scan, Set Status Modifier" /75 and Continue Scan, No Status Modifier" /75. If anyone wants to understand the technical details of these three commands I suggest they consult one of the IBM reference manuals. To make it clearer than the IBM card We might consider completely filling in column 2 and replacing column 1 with a column spanned row for each command category but that is a bit of work I'm not ready to undertake. Tom94022 (talk) 06:48, 22 November 2015 (UTC)

The IBM reference card is just a summary, and is sometimes confusing. The definitive information is in the reference manuals. I could not find CCW commands called "Set Status Modifier" or "No Status Modifier" in GA26-3599-6 or A26-5988-7. It is clear that the author was thinking of the CSW unit status bit Status Modifier, but the text is out of place and confusing. If you want to say something about the SM bit, make it a footnote called out by both Search and Scan, with an explanation that SM is set if th search matches. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:48, 24 November 2015 (UTC)

Try Figure 37. Continue Scan Commands in GA26-5988. IBM's RMs sometimes use "Status Modivier" and sometimes "Compare" for these three Continue Scan CCWs /35. /75 & /55 and their MT equivalents. I have no preference for either of IBM's representations; do what u will. BTW, I looked without success in the RMs for an explanation of the differences between the two "Continue Scan, Set Compare" CCWs /35 & /75 (aka "Continue Scan, Set SM") so please feel free to clarify if you can. Tom94022 (talk) 20:44, 25 November 2015 (UTC)

There are several points of confusion. First, those commands are documented in Record Overflow rather than in Search Commands or File Scan. Second, as you noted, IBM changed the name between the 2841 and the 2844. Finally, it is not clear from the reference card that the names are all Continue .... I propose adding footnotes with page numbers in the references and removing (See Note 1) from the Command Class column.

BTW, it would be helpful if you included the edition number when citing an IBM publication; Figure 37 exists in GA26-5988-7 but not in A26-5988-0. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:56, 25 November 2015 (UTC)

I suggest we use just the terminology of GA26-5988-7 which is also in the 1971 2314/2844 RM, that is, GA26-3599-6, see its fig 44. I believe that is how the article is now written. Note 1 is now split and it appears both are relevant. I suggest the difference in terminology is not notable. As near as I can figure out the Continue Scan commands are invoked by the IOS when a record overflow occurs during a searvh. that might be worth a note if we can find a RS. Tom94022 (talk) 07:47, 26 November 2015 (UTC)

Do you have a link to GA22-3599-7? GA26-3599-6 uses the terminology "Continue Scan, No Compare", "Continue Scan and "Continue Scan, Set Compare". 21:59, 29 November 2015 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

I don't think there is a 2314 SRL GA22-3599-7. I was referring to the 2841 SRL GA26-5988-7 which uses both variants for these commands; in its Appendix C it uses the "Compare" variant for two of the three CCWs. The 2314 SRL uses only the "Compare" variant for all three CCWs so I think we should just stick with it in this article. I have looked for but cannot find any description of the use of these three CCWs. Tom94022 (talk) 22:03, 30 November 2015 (UTC)

It's documented, sort of. See Appendix B of GA26-5988-7 And Processing Overflow Records in GA26-3599-6.

The table is still confusing. What I propose is to use rowspan= to eliminate some of the horizontal lines in the Class column and to add footnotes on appropriate for requiring File Scan and Record Overflow features rather than relying on a catchall Optional flag. At the same time I'll correct some minor errors and omissions. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:53, 1 December 2015 (UTC)

I've created User:Chatul/Sandbox/Count key data/notes to describe my plans for User:Chatul/Sandbox/Count key data. The outline is still incomplete; feel free to add mor topics and more reference. I'm moving all of the notes and references to refs= keywords on {{Reflist}} templates, with manuals in order by form number, for ease of maintainability. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:20, 16 November 2015 (UTC)

I see u are continuing to edit these sandbox pages but so far without participation from any other editor other than my one comment. Before u put too much additional effort into this may I suggest we find a way to resolve our fundamental dispute. The fundamental dispute as I see it, is that there is no reliable source that separates CKD CCWs into " Basic CCW Commands" and "ECKD Commands" as u do in your sandbox. IBM treats all CKD commands as one set and IMO the article should do so too. I have a number of other objections to your sandbox but I suspect they can we worked out. There are only a few editors who have made more than 3 edits to this article; perhaps we can ask them for opinions before u get too much further along in the sandbox. Perhaps some sort of structured debate? The editors are Dsimic, Peterh5322, Ccalvin, Jerome Charles Potts & Ringbang. Tom94022 (talk) 02:10, 14 December 2015 (UTC)

Issues under dispute include:

1. Whether to confine historical data to a section labeled History.
   1. I Added a History section on 5 August 2015; and gradually expanded it.
   2. User:Tom94022 rewrote most of the History text and removed the History heading
   3. I want to reinstate the History section and move the technical information into a new Technical Details section
   4. There's a separate issue as to whether the history of the controllers should be in a separate article
2. Whether presenting technical features in the sequence of their announcement makes sense.
3. Whether to distinguish CKD from ECKD in the structure.
4. Whether the term head of string is appropriate for 2319A1, 2319-B1 and 3333.

Please see these for context:

• Talk:Count key data
• User talk:Chatul/Sandbox/Count key data#Alternative Construction
• User talk:Chatul/Sandbox/Count key data#Mediation issues
• History of IBM CKD Controllers
• User:Chatul/Sandbox/Count key data/notes
• User:Chatul/Sandbox/Count key data

User:Tom94022 refused mediation: Wikipedia:Requests for mediation/Count key data Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:23, 12 January 2016 (UTC)

Extracted from above

and

by: Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:51, 5 January 2016 (UTC)

The 1971 370/135 manual cited above does not make the 2319-A1 an "A-unit" as the term came to be defined. The designation was introduced with the 3340-A2 circa 1974 and applied to all mainframe DASD thereafter, including later on a C-Unit. The 2319-A1 connects only to the 370/135 or the S370/145 IFAs and neither IFA connects any defined "A-Units" as IBM designated such DASD (i.e. 3340-A2 and thereafter).

A prefix of "A" is not sufficient to make a unit an "A-Unit" else as cited above the 2312 Disk Storage Model Al (containing one disk storage module) 2318 Disk Storage Model Al (containing two disk storage modules) would also be A-Units. As IBM now designates DASD they should be B1 and B4 respectively. Likewise if the first DASD unit attached to anything is an "A-Unit" then the 2319-B1 above should be designated 2319-A1 or A3 but it isn't.

IBM's New Attachment Strategy is the genisys of the director, A-Unit & B-Unit packaging and its first embodiment was the 3830-2, 3333 and 3330. Thus the 3333 and the 3333-11 are A-Units even though not so designated by a prefic "A" in the suffix to a DASD model number. The interface between the director and an A-Unit is designated by IBM as the DCI (Director-Controller Interface) or the CTL-I (Controller-Interface). This is not the interface between and IFA and a 2319-A1.

We must be very careful in applying current terms such as A=Unit to past products. The current meaning of A-Unit does not apply to either the 2319-A1 or 2319-B1 even though they were the first physical unit attached to a storage control. If so, many old DASD are a A-Units (e.g. 2312 in a 2314 DASF) and the term looses its current meaning. The term A-Unit can be applied to the 3333s since they intermix with 3340-A2s and 3350-A2s on many storage controls.

It might be argued that the 2319-A1 was a precursor to the New Attachment Strategy, but the evidence shows otherwise. Tom94022 (talk) 19:50, 5 January 2016 (UTC)

Please stop the red herrings. If I wanted to claim that the "A" in the model number was relevant then I would have said so. I'm prepared to defend what I write, but not claims that you attribute to me without foundation.

The issue in contention is not wherther the 2319-A1 and 2319-B1 are "A-units", but whether they are heads of string. IBM's use of the term "A-unit" was just a change in nomenclature, not the introduction of a new concept. As to "The interface between the director and an A-Unit is designated by IBM as the DCI (Director-Controller Interface) or the CTL-I (Controller-Interface).", there is no "the interface"; there are different interface for different devices.

We can be careul about the term "A-unit" by not using it, and instead using the neutral term "head of sting". IAC, I am not the one using the term "A-unit". Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:11, 6 January 2016 (UTC)

IBM's terminology:

• "head of string. The unit in a DASD string that contains controller functions. Also called the A-unit. See also device adapter."
• "string. A series of connected DASD units sharing the same A-unit (or head of string)."
• "string address. The 1-bit address used by the storage control to direct commands to the correct 3380 AJ4/AK4 or 3390 DASD string on the CTL-I. See also controller address."
• "2-path string. A series of physically connected DASD units in which the head of string unit provides two data transfer paths that can operate simultaneously."
• "control interface (CTL-I). The hardware connection between the storage control function and the DASD controller function.

taken fromIBM 3390 Glossary

IBM uses "head of string" interchangeably with "A-unit" so your distinction doesn't have much merit.

There is one interface for A-units! Since 3333s, and A-units of the 3340, 3350, 3380 and 3390 families can be intermixed on one set of cables to one director it is one real interface, called CTL-I (ConTroLler-Interface) as defined above (it's the same in the 3880 manual); if you search a bit you may also find the same interface also called the DCI (that's my recollection of the term used in 3333 and 3340-A maintenance literature). I also recall the CTL-I interface used parallel channel cables. For this reason the 3333s are A-units or as u would prefer "heads of strings"

The 2319A cannot attach to the CTL-I, nor does it have a string address nor can it attach with other strings and finally it cannot support 2-path string (aka string switch). For any of these reasons it does not have a "controller" in the sense it is currently defined and therefore it is not an "head of string" (aka "A-unit") as IBM defines it. Calling it an A-unit creates unnecessary confusion with the far more capable and consistently connected units.

In addition, I can find no contemporaneous IBM usage of the phrase "head of string" or even "string" in conjunction with any 2319. This DASD concept and terminology was introduced with the 3830-2 and it is discordant to retroactively apply it.

It actually confuses things by using head of string since in the ordinary usage of language one could call the 2312-1 the head of string for a 2314-1 DASF, the 2313-A1 head of string for a 2314-A1 DASF and the 2319-B1 head of string for a 2314 B DASF, none of which have any controller function so by definition are not A-units.

So we should be careful and use the less likely to be confused term: A-unit. Tom94022 (talk) 08:38, 8 January 2016 (UTC)

The 2841, 2820, 2314-1 and 2314-A1 didn't attach strings; the 2319-B1 was a head of string.

You couldn't, in general, mix device types in a string, although certin combinations were allowed, e.g., a 3340 and a 3344.

As to the interface, IBM was constantly changing it, both for higher speeds and to add features, e.g., string switch. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:07, 8 January 2016 (UTC)

You are incorrect and/or inconsistent on all three points above.

1. What is your definition of string? There is no evidence of any controller in the 2310-B1; it's just like the 2312-1 on a 2314 DASF; the first in an other wise un-ordered series of drives.
2. Again it all depends upon what you mean by a string. With regard to strings headed by an A-unit your statement is true but if u insist the 2319s are A-units then it is false
3. I think string switch was in from the beginning, but regardless such an enhancement is no more of a change than ECKD was to the BMux. Furthermore, there is no evidence that the CTL-I inherent speed was ever changed, yes it handled faster DASD but that says nothing about its inherent speed. Furthermore, even if it did, such an enhancement is again nothing more than the faster BMux channel. The CTL-I interface did not change much, probably the only real enhancement was 4-paths to drives. The evidence is that 3333s thru 3380s could attach and intermix on various configurations of 3880s. The fact that IBM may have improved it over time is irrelevant. Tom94022 (talk) 22:59, 8 January 2016 (UTC)

Neither incorrect nor inconsistent. A string is the set of devices supported by a device controller.

Well we are now close. There is no evidence the 2319-B1 has any device controller so perhaps u will now admit it is not an A-unit.

Any device controller, I don't think so? If you read the definitions above, it is not any controller but only a controller that embodies the CTL-I interface. The 2319A did not have such an interface therefore it is not an A-unit as IBM came to define the term. To say so, is time inconsistent application of the IBM term, sort of like a musuem putting the head of one Roman emperor on the statue of an earlier Greek god. Tom94022 (talk) 20:06, 10 January 2016 (UTC)

You need to read the reference manuals; you are confusing storage controllers with storage directors. A 3880 can support different types of strings, but not on the same director. There is a section of the manual that lists, for each director on each models, what types of string are permitted on that director. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:06, 10 January 2016 (UTC)

I did read:

Through use of diskettes, each storage director can be initialized to attach the following types of disk storage devices:

• IBM 3340 and 3344

• IBM 3330, 3333, and 3350

• IBM 3370

• IBM 3375

• IBM 3380.

IBM 3880 Storage Control Models 1, 2, 3 and 4 Description Manual (PDF) (Tenth ed.), IBM, September 1987, pp. 1–2, GA26-1661-9,

1. As shown by the intermix of 3330 and 3350 any 3380 storage control can support different types of strings on each of its directors.
2. The abiltiy to convert from one to another thru use of a diskette shows that any director can attach any type of A-unit. The manual further makes no distinction about the CTL-I interface between any director and any connected A-unit with bits 3 and 4 of addressing used for controller seclection of all A-unit types. Tom94022 (talk) 20:06, 10 January 2016 (UTC)

Having gone thru this research it occurs to me that a discussion of A-units and B-units belongs in IBM System/360 and other IBM mainframe HDDs or perhaps in the separate article Hard disk drive interface. In a certain sense an -A1 unit is not unlike a SCSI or IDE drive. Your thoughts? Tom94022 (talk) 22:59, 8 January 2016 (UTC)

Hardly research: you missed IBM 3880 Storage Control Models 1, 2, 3 and 4 Description Manual (PDF) (Tenth ed.), IBM, September 1987, pp. 1–2, 1–3, GA26-1661-9, as I suggested.

I read the cite long before u suggested I do, and my quote above is from one of the two pages you suggested. So what is it you don't understand? Tom94022 (talk) 00:26, 13 January 2016 (UTC)

As to the 2319, the 2314 and IFA documentation is quite explicit about what attaches to what; the device/controller table in notes comes straight out of the various IBM manuals. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:40, 12 January 2016 (UTC)

What attaches to what and in what order is not sufficient to designate an A-unit or a string as IBM defines them. Read the definitions above! Any attempt to retroactively apply IBMs 1980s terminology to a 1970 product is not supported by any evidence cited so far. Tom94022 (talk) 00:26, 13 January 2016 (UTC)

I have a searchable set of more that 50 IBM DASD documents (including all cited in these articles) that has the earliest usage of "string" in the context of DASD architecture as occurring with respect to the 3830-2 in the early 1970s (added to ref manual in 1974). It was added in the context of "string switch" and more than 8 drive attachment to control units. U can get an idea if you do this Google search: string site:http://bitsavers.trailing-edge.com/pdf/ibm/dasd/.

One of the hits Introduction to IBM DASDs abd Organization Methods, Dec 1975, covers 2314 and beyond. It uses the term 55 times never in conjunction with 2319 or 2314. A section on "String switching" within "Concepts of DASD switching," in particular the discussion beginning on page 3-18 and fig 3 makes it clear the head of a string can have a switch and more than one string can be connected to a control unit. The specific heads of strings identified are the 3340-A2 and the 3333s. The specific control units identified are the 3830-2 and 3830-3.

Many years later IBM defined "head of string" and "A-unit" (see above definitions) consistent with the usages disclosed in Introduction to IBM DASDs and Organization Methods, Dec 1975, All mainframe DASD after the 3333-1 are used in this same manner.

There is no evidence that IBM ever used these terms with respect to 2319s. The 2319s contain no switch and the first units of any collection of DASD cannot attach to more than one storage control. To now apply the defined IBM terms "head of string." "A-unit" or "string" to 2319 units is WP:POV but more importantly obscures a key distinction in IBM DASD art, that is the concept of a string which can be switched. The 2319s were just another package of 2314s with no architectural implications!

On the other hand, string switch allowed alternate paths beyond the existing channel switching. It led to dynamic pathing. All CKD DASD beginning with the 3333 did so and usage of these terms to so describe them is supported by the evidence. The 2319s had none of this and therefore to so describe them is to muddy the water. Tom94022 (talk) 20:54, 15 January 2016 (UTC)

"string", IBM Terminology, A group of auxiliary storage devices connected in a series on the system. The order and location in which each device is connected to the system determines the physical address of the device.

The 2844 could be considered to be the first example of string switching, well before IBM coined the term.Channel switching was around even earlier. The manual that you cite uses the term string in a fashion consistent with the 2314.

Please give links to bitsavers rather than to its mirrors.

BTW, if you really have copies of all cited manuals, please contribute scans of the 3350 and ISC manuals to bitsavers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:06, 15 January 2016 (UTC)

Nothing above is either responsive to or contradicts the statement that 2319s are not "heads of strings" or "A-units" as IBM defined them, to elaborate:

1. The 2016 IBM definition of "string" is not particularly relevant to CKD strings all of which are now withdrawn but if it was then the 2319s were not part of strings since their addresses were determined by plugs and/or jumper settings. Actually this definitions seems to fit current HDD usage in IBM RAID subsystems and it really doesn't apply to historical CKD storage (or even FBA). This demonstrates the care that must be used when applying terms retroactively.
2. The 2844 was channel switched and provided 2-paths to each device; there was no string switching.

Tom94022 (talk) 08:05, 16 January 2016 (UTC)

Count key data#Programming has an incorrect description of device addressing. The device address on the IBM System/360 is a four bit channel number and an 8-bit unit number on the channel; there is no separation of the unit number into control unit digit and device digit. In fact, a control unit could have as many as 256 units and some control units attached only a single device. What is true is that a control unit reserves a block of unit numbers that is a power of two, but that power can be anywhere from 1 to 256.

Modern IBM mainframes allow two hexadecimal digits for channels. is also incorrect; modern IBM mainframes allow more than 256 channels (and more than 256 devices pre channel.) Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:25, 7 March 2016 (UTC)

If you think it is incorrect why don't u just change the material with an appropriate reference so your corrrection can be verified? You have this habit of posting unsupported corrrections in a talk page which makes work for other editors. Please stop doing it and just make supported corrections. Tom94022 (talk) 01:49, 8 March 2016 (UTC)

You have this habit of asking questions that I have already answered multiple times. Your propensity for capricious and arbitrary reverts makes work for other editors and means I spend less time if I discuss issues first. I will continued posting errata before making the changes until such time as you make it unnecessary. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:48, 8 March 2016 (UTC)

You are making more work for yourself since in the talk page u usually do not identify any correction but merely point to a purported error without a clue as to how it might be corrected. My answer in all such cases will be the same - why not do it yourself? At which point u will do what u should have done in the first place making both our talk page activity pretty useless. Be that as it may, do what u must, but please leave out the ad hominem attacks. Tom94022 (talk) 07:36, 9 March 2016 (UTC)

There you go again. IT IS YOUR INAPPROPRIATE REVERTS THAT MAKE IT NECESSARY TO DISCUSS CHANGES FIRST. As to ad hominem, PKB. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:56, 10 March 2016 (UTC)

Yelling (ALL CAPS) is not consistent with Wikipedia etiqutte. Furthermore, you have nothing to yell about since I rarely inappropriately revert; you may disagree my edits and call them reverts but that doesn't make them inappropriate. Be that as it may, your recent edit to this article is incorrect - you confuse MIF ID, CHIP ID and PCH ID - I don't have time to fix it right now so maybe you will. Tom94022 (talk) 23:35, 10 March 2016 (UTC)

I've clarified the relation of subchannel, CHPID and PCHID. Personally I think it's TMI, but TTBOMK it is now correct. The limits of six channel subsystems and 320 channels are for the z13 and will probably increase as IBM announces new processors. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:55, 11 March 2016 (UTC)

I agree it is TMI but it is more accurate than before, maybe I will try to simplify. The point that seems to have been lost is that there was a S360/370 architecture addressing limitation of 16 physical channels (even though most such systems could accomodate that number) so what is the same physical limitation if any in z architecture? Its obviously greater than 6 x 320! Tom94022 (talk) 19:05, 11 March 2016 (UTC)

IBM originally specified an I/O address for S/360 as 12 bits, but later expanded it to 16, with a maximum of 256 channels; however, I know of no processor that could physically attach more than 14. The architectural limit for S/370 is 256 channels per channel set; again, I know of no processor that could physically attach that many.

Physical limits have nothing to do with architectural limits. The physical limit of a z13 is 320 channels, not 6*320. The architectural limit is 64Ki. The limit of 256 channels per channel subsystem is architectural, not just physical. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:33, 14 March 2016 (UTC)

Thanks for the info, we are getting closer. According to the last S/350 POO I can find, "The channel-address field provides for identifying up to 256 channels, out of which only channels 0-6 may be installed; channel-addresses 7 and up are considered invalid." (GA22-6921-8, November 1970, p. 88) This means 3 channel valid bits on S/360 not 4 or 8; are there references for 4/8 address bits and up to 14 physical channels on a S/360? Also FWIW, "Devices sharing a control unit (i.e., magnetic tape drives or disk access mechanisms) are assigned addresses within sets of contiguous numbers. The size of such a set is equal to the maximum number of devices that can share the control unit, or 16, whichever is smaller." (ibid, p. 89) Tom94022 (talk) 18:11, 15 March 2016 (UTC)

FWIW the IBM archives say the S/360 M195 can have one Blk and up to six Selector channels. Tom94022 (talk) 16:36, 16 March 2016 (UTC)

U might also take a look at section 9.2 of Development of 360/370 Architecture - A Plain Man's View for a different view of S/370. Tom94022 (talk) 16:45, 16 March 2016 (UTC)

• The Functional Specifications for both the 360/67 and the 360/195 give a limit of 14 channels.
• Despite the claim in http://www.leeandmelindavarian.com/Melinda/gribbin.pdf, IDA was a relatively minor change to channel architecture, while the change from 370 mode to XA mode was massive.
• IBM did eventually add 4-digit device numbers to MVS. JCL and operator commands used a leading slash to distinguish 4-digit device numbers from 4-digit generic device names.

Is there any reason that we need to give more detail than

CKD DASD are addressed like other Input/Output devices; for System/360 and System/370 mode this is directly, throughu channels and the associated control units<ref name="360Prins" /><ref name="370Prins" /><ref name="370ePrins" /> (SCU or Storage Control Unit), initially using three hexadecimal digits, one for channel and two for control unit and Device. Modern IBM mainframes use an arbitrary subchannel number whose definition includes the actual channels, control unit and device, supporting more than 256 channels and more than 256 devices/channel.

possibly with a comment giving the details as TMI? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:43, 16 March 2016 (UTC)

I suggest mixing hexadecimal units and decimal units in the same paragraph is confusing to some readers and likely bad style. Also comparing an addressing limitation for S/360 S/370 with a greater than for modern mainframes maybe OK but wouldn't it be better to compare apples to apples? Are you sure about >256 devices/channel unless u mean >256 devices/virtual channel. I guess the question is should this paragraph be phrased to reflect the physical channel, be it parallel, FICON or ESCON, or should it reflect the OS view of an I/0? Tom94022 (talk) 17:09, 18 March 2016 (UTC)

I was suggesting replacing the entire paragraph with the suggested wording. I'd prefer to use bits across the board. I was comparing apples to apples; the logical channels map one-to-one to virtual channels, so the limits are the same (The device id for parallel (old) channels is the 8 bit device address; for ESCON channels, a four-bit control-unit address and an eight-bit device address; for FICON channels, an eight-bit control-unit-image ID and an eight-bit device address.)

The OS view is mostly the subchannel number, with 2¹⁶ subchannels per subchannel set, although it is the device number that is used for operator communication. The OS only uses the CHPID when altering or displaying the status of a logical channel, and only uses the PCHID when defining or loading a new IOCDS.

For the record, the MVS change to support more than 256 subchannels came with the DFSMS version associated with MVS/ESA System Product Version 5 Release 1 (MVS/ESA SP V5R1). Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:41, 20 March 2016 (UTC)

I corrected your last edit; a S/360 channel could address 256 devices but not 256 controllers. Each controller took up a block of addresses corresponding to its maximum addressing capability and impedance limits put a very low cap on the number of controllers.

On modern system the limit of 2¹⁶ subchannel numbers is per channel subsystem subset, so for a z13 you have to multiply by six.

Is the fact that the original S/360 architecture (before 67 and 195) was limited to 7 channels TMI? Is the fact that you can have hundreds of channels on a modern system TMI? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:46, 23 March 2016 (UTC)

You can't get 4096 DASD on a S/360 due to impedance limits on the channel. The basic limit is 8, but long cable runs can reduce that. Even on a 360/195 you can't have more than 112 (14*8) controllers, SCU or not. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:36, 24 March 2016 (UTC)

Sort of true, but so what? The paragraph is about addressing and not physical limits. FWIW, I think the basic limit is 10 SCUs on a channel driven by driver/receiver requirements but other constraints such as resistance might give a lower number in specific instances. Maybe we should talk in terms of limitations but that's a large topic and it gets even more confusing since I beleive the PCMs put up to 16 drives on a conventional SCU while IBM never TTBOMK went above 8. So is the limit 80/channel determined by the artificial IBM constraint or the 160/channel of PCM practice? TMI IMO Tom94022 (talk) 07:09, 25 March 2016 (UTC)

We;;. for one thing there is no such thing as a controller address on a parallel (old) channel. The addressing limit is 256 devices. Were it possible to attach 128 2820 controllers to a single parallel channel the architecture would allow addressing them. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:51, 25 March 2016 (UTC)

My recollection is the limitation is in the SCU, DASD SCUs won't allow more than 16 device address; since this is a DASD article the limitation does exist, so unless you recall differently I will reinstate the change. I'm reasonably confident of this limitation but I could be wrong. If you truly have a different recollection about SCU imposed limitation, please state so here and I won't revert but instead research it. Tom94022 (talk) 08:21, 26 March 2016 (UTC)

Please read the manuals that you downloaded from bitsavers; the 3830-2 and later DASD controllers supported more than 16 devices. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:24, 30 March 2016 (UTC)

Good point - the A-Units only attached 8 devices - the Controller took one bit from the drive field and one bit from the Director field so the CAW became SSSCCDDD instead of SSSSDDDD. Thats too much information for this article so I accept yr edit. BTW, u could have left out Please read the manuals that you downloaded from bitsavers;; it adds no value and happens to be wrong - most of the manuals I have are from my personal collection. Tom94022 (talk) 07:13, 31 March 2016 (UTC)

It doesn't matter whether the manuals are from bitsavers or your personal collection; they do no good if you rely on your recollection instead of consulting them. An A-unit could control up to 32 device addresses. From GC26-4573-03:

The 3390 string includes four controllers, labeled Device Adapters on the operator panel, and four to 32 uniquely addressable devices (in multiples of four).

The CAW does not contain the S/360 device address, and the device address is neither SSSCCDDD nor SSSSDDDD; it is an undifferentiated 8 bits. Different controllers will reserve address blocks of different sizes, e.g., the 2820 only reserves two addresses. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:49, 31 March 2016 (UTC)

It doesn't matter whether the manuals are from bitsavers or your personal collection; they do no good if you rely on your recollection instead of consulting them. - more wasted time and text. Actually it does save time to work from memory particularly on a talk page.

I believe your cite supports my analysis, the 3390 "32 device addresses" are in fact 4 controller addresses (2 bits) times 8 drive addresses (3 bits).

No, each of the four device controllers connects to all of the drives. From GC26-4573-03:

Each controller in the string has an internal path to each device in the string, as shown in Figure 4.

Read up on DLSE. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:04, 1 April 2016 (UTC)

Sorry about the CAW error, obviously I meant the address portion of I/O instructions. This is not about address reservation but about address masking in the subsystem. This is really about where the FE puts the jumpers that establish the physical address corresponding to the bits of the I?O instruction. In summary as I recall:

• On conventional type storage controls the parallel channel limited connection to 10 units even though 16 could be addressed, and the storage control masked the upper 4 address bits leaving 4 bits for the DASD, but IBM only allowed up to 8 units (3 bits) to attach. Thus a channel with only conventional type controls could address 256 DASD as SSSSDDDD and attach up to 80 IBM DASD and perhaps as many as 160 PCM DASD.

No, A22-6843-3 states

System Configuration
Number of Units: In the general system configuration, as many as eight control units can be directly connected to a single channel I/O interface.

Controllers could not be addressed on a parallel channel, only devices, and the masking to determine which addresses fell into range was controller dependent. From A22-6843-3

3. Control units designed to accommodate more than 16 devices may be assigned nonsequential sets of addresses. Each set consists of 16 addresses, or the number required to make the total number of assigned addresses equal to the maximum number of devices attachable to the control unit, whichever is smaller.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:04, 1 April 2016 (UTC)

• On director type storage controls the parallel channel again limited connection to 10 units but the director masked the upper 3 bits, while the A-Units masked the next two bits, leaving 3 bits for the DASD. Thus a channel with only director type controls could address 256 DASD as SSSCCDDD and attach 256 DASD

Probably TMI for the article but an interesting discussion. Tom94022 (talk) 23:43, 31 March 2016 (UTC)

The paragraph as currently written is inconsistent since it starts with addressing DASD by Channel, SCU and Device but then drops the SCU in the specifics. It also doesn't mention head of string address at all which I beleive is unique to DASD and maybe one tape subsystem. This arrises from one's perspective on the I/O address; at the I/O instruction level (looking down the DASD structure) as the article currently is written it is undifferentiated 16 bits but when u look at it up from the DASD perspective differentiation takes place at different levels in the structure which should be reflected in the article. For example, I seem to recall that the early DASD had only three bits available on the plugs, 8-F was not available.

We probably need to say something like:

Of the 16 I/O instruction address bits available for devices, in a DASD subsystem three to five of the lower bits are assigned in the DASD, one to four bits of the high order bits are assigned in the storage control, and in string configurations two of the middle bits are assigned in the string controller.

This maybe TMI, perhaps sometihing shorter, like:

Specific bits of the I/O instruction's address bits in a DASD subsystem are assinged internally at the storage control, string controller and DASD and has ranged from CCCCDDDD to CSSDDDDD (Control unit, String controller and DASD).

Comment? Tom94022 (talk) 17:46, 9 April 2016 (UTC)

I just read the opening paragraph, which contains:

Italic textIt is a self-defining format with each data record represented by a Count Area that identifies the record and provides the number of bytes in an optional Key Area and an optional Data AreaItalic text

IBM Literature exclusively refers to the writeable unit on a disk or tape device as a block.

--Jhlister (talk) 02:20, 3 May 2017 (UTC)

Except for unblocked, where record is equal to block. On the other hand, the descriptor block on a track is referred to as R0, and in addressing MBBCCHHR and TTR, the R stands for record and not block, even though it is a block and not a record. Though TTR in the case of DSORG=DA only works for RECFM=F, unblocked, so it is a record. Gah4 (talk) 02:39, 3 May 2017 (UTC)

The manual^[1] for the 2314 is not dead; it has just moved. I was going to update the URL to http://www.bitsavers.org/pdf/ibm/dasd/2314/A26-3599-4_2314_Sep69.pdf and remove the url-status, but I saw that bitsavers also has a more recent^[2] edition. Should I just correct and update the existing reference to reflect the new URL, or should I replace the entire {{cite}} with the more recent edition? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:12, 17 September 2019 (UTC)

:The current version of the 2841 ref manual is already in the article - the earlier version is used to reference the 7320 as a DASD which was removed from the series at some point. So I would update to the new location of the older version. Tom94022 (talk) 19:48, 17 September 2019 (UTC)Tom94022 (talk) 21:30, 17 September 2019 (UTC)

Went with latests version, example in article is Example 3 in ref. Tom94022 (talk) 21:47, 17 September 2019 (UTC)

See Talk:Execute_Channel_Program#Duplicate_info for discussion. Peter Flass (talk) 16:19, 6 December 2019 (UTC)

The article says: Because blocks are normally not split between tracks. Not normally, unless the device has the track overflow feature. One of the complications in getting Hercules to run MVS 3.8j was that it needs track overflow to work. It might be that it is needed for the catalog or TOC. But yes, that was for earlier devices, I believe the 3330 being the more recent one. Gah4 (talk) 23:47, 6 March 2024 (UTC)

CKD records are never split between tracks, but the access methods may write a logical block as multiple physical blocks on a device supporting track overflow. MVS does not use track overflow for a VTOC or CVOL, so if there is a dependency I would assume that it is in the VSAM catalog or in the paging datasets. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:04, 7 March 2024 (UTC)

Oh, yes, VSAM catalog is the one. The result, in the end, is that the Hercules CKD files are compatible with those of IBM's AWS disks, except for track overflow. Gah4 (talk) 07:52, 8 March 2024 (UTC)

There is a disconnect in the vocabulary of IBM hardware manuals versus software manuals. The hardware manuals for CKD DASD use the term record while the software manuals use the term block or physical record. I believe that the lead should mention this. @Tom94022: Also, edit special:permalink/1212325573 changed or a copy of the highest key in the block, for "blocked" records) to the garbled or a copy of the first n bytes in of the first data when the record has several "blocks" data concatenated in one data field, which does not conform to either hardware or software nomenclature. I suggest or a copy of the highest key in the record, for blocked logical^[a] records) -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:29, 7 March 2024 (UTC)

I am not sure what substantive relevant distinction you are making - I am not aware of any reference manual for any CKD device that uses the term "block" to refer to "record." Ditto at the channel command reference manual level. Yes, at some level (e.g. to_IBM_Direct-Access_Storage_Devices_and_Organization_Methods_Dec75.pdf) IBM does distinguish between logical record and physical record with the "block" sometimes the same as "physical record" but I think that is a level of complexity we don't need here. IBM doesn't uses "record" not "physical record" in the relevant reference manuals I think that is best what we consistently use in this article. If someone wants to add a note someplace in the article that CKD record is sometimes referred to as "physical record" or "block" that should be more than enough. Tom94022 (talk) 22:05, 7 March 2024 (UTC)

Exactly what I wrote; the hardware and software nomenclature differ.

The quoted text in the cited edit broke consistency, even within a single sentence, and used nomenclature that is OR; since you removed it in permalink/1212432070, it is no longer an issue. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:33, 8 March 2024 (UTC)