Jump to content

User talk:Chatul/Sandbox/Count key data

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Standalone Seek

[edit]

My recollection is that the IOS in S/360 added a standalone seek before implementing any channel program to a device so as to enable seek overlap. This was because on a selector channel the control unit was busy for the duration of chained seek. The BMUX channel eliminated the need for this but I seemed to recall it was continued for a long time thereafter for compatibility sake. You may want to add this to your ezample channel programs or it maybe too much detailed history for the article. Tom94022 (talk) 23:56, 6 November 2015 (UTC)[reply]

Yes, there is a stand-alone seek, but the seek is repeated in the prefix that IOS constructs. The best place to discuss it is probably in he section on seek commands. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:20, 24 November 2015 (UTC)[reply]

Alternative Construction

[edit]

Thanks for posting all the references in yr sandboxes. I have appropriated many for my recent edits. You might note that I restructured Count_key_data#IBM.27s_CKD_DASD_subsystems along the lines of this sandbox

Please take a look at User:Tom94022/Sandbox2; it is the current Count key data article restructured to comport with this sandboxes structure expect for the history which remains a separate article, History of IBM CKD Controllers. I really don't see the need for such restructuring but if it helps so be it. On the other hand, I could easily add a short history section linked to the longer article

History of IBM CKD Controllers now covers all of this sandbox's section 2 History. FWIW i suggest the focus in this section should be on the SCUs and not the devices. The devices are already well covered in the History of IBM magnetic disk drives. May I suggest u edit in the History of IBM CKD Controllers rather than here? Whether it is then merged with the parent is another issue but that shouldn't prevent us from editing the same article.

This still leaves open the issue of ECKD as distinct from CKD. I really don't get your point but it would very much help me understand if you would complete subsections 2.8.5 Extended CKD and 3.5 ECKD Commands of this sandbox.

We really should find a way to work together since there aren't too many of us editors knowledgable about CKD

I watch this page so u can answer here Tom94022 (talk) 19:29, 4 January 2016 (UTC)[reply]

Its not along the lines of my sandbox, because I have everything from Initial CKD implementation through Beyond System/370 under History.
Both History of IBM CKD Controllers and History of IBM magnetic disk drives; have gaps.
Please take a look at the current version of User:Chatul/Sandbox/Count key data/notes; I'd appreciate it if you could spot the problem with {{efn|name=mt}}.
I meant to post an update to User:Chatul/Sandbox/Count key data but ran out of time; I'll do it tomorrow. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:53, 3 January 2016 (UTC)[reply]
{{efn}} problem is due to not escaping "=" with double braces.
To elaborate on history articles, the DASD that are not disks are missing, e.g., 2301, 2303, 2321, 3850, 7320.
With regard to a separate history article, it would be easier to justify if it covered both FBA and [E]CKD.
With regard to CKD vs ECKD, one of the manuals that you cited, Storage Subsystem Library Introduction to Nonsynchronous Direct Access Storage Subsystems (First ed.), IBM, January 1990, GC26-4519-00, clearly identifies synchronous with CKD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:07, 4 January 2016 (UTC)[reply]
Addressing yr issues one at a time:
  1. As near as I can tell the two current articles have everything that is in the one proposed article. For example, Initial CKD implementation is explicity in the CKD article and implicit in sections 1.1 thru 1.4 of the history article. Whereas Beyond System/370 is explicit in the CKD article but as currently written not to relevant to the history artilce since it has no hadware content. Hardware history beyond s/370 would go into RAID These two examples illustrate why two articles make sense; the CKD article focuses on features as they ultimately existed while the history article focuses on the evolution of the CKD hardware.
  2. Please identify any "gaps" in History of IBM CKD Controllers. Of course History of IBM magnetic disk drives will only inlude DASD that are magnetic disk drives. The "missing" DASD are all coverred in the current two CKD articles but perhaps we should add a few words to Direct-access storage device
  3. I thought about changing the history article to "History of IBM mainfram storage controls" and picking up FBA.. Perhaps we could go as far as "History of IBM storage controls" following the structure of History of IBM magnetic disk drives. We can always do that later but I think we have enough work to finish on CKD
  4. Sure some CCWs are associated with asynchronous operatioon in the storage subsysterm and some with synchronous operation and many with both. But that applies equally to rps and non-rps, dynamic and static pathing and other features of CKD. My concern is not about a section on those CCWs required for asynchronous operation, although I would rather identify the section as "Asynchonous operation" rather than "ECKD" since the former is likely to be more understandable to a reader. My concern is lumping all the other features into one "Basic CCWs) an aglomeration not supported in the literature and apparently POV.
  5. It really would help me if you would complete subsections 2.8.5 Extended CKD and 3.5 ECKD Commands of this sandbox.
Tom94022 (talk) 19:29, 4 January 2016 (UTC)[reply]
1. The basic problem is organization; those sections have a mix of history and technology that makes it confusing for both. I want a history section with only who did what when information, a detailed technical information section and a brief summary of the technical information in overview. I'm undecided as to whether the history should precede or follow the technical details, but they definitely shouldn't be mixed.
2. 2321 details
3. "History of IBM storage controls" works for me, but then it should go back to the 7631. That still leaves the issue of the non-disk DASD.
4. It's not that there are new CCWs, it's that some of the old CCWs are not permitted with ECKD and that IBM documents CKD and ECKD as separate command sets.
5. It's a question of priorities; I've still got a lot of work to do on other sections, and we still haven't got a consensus on organization. It doesn't help that I misplaced a thumb drive containing some of my updates :-(
I'm considering mixing the CKD and ECKD commands, with notes on how their behavior differs. If I do that, I'll also note what is different in paging mode on the 3880-11 and -21.
It would help if you could flesh out the overview and the tables in User:Chatul/Sandbox/Count key data/notes, including announcement dates, but wait for my next update. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:07, 4 January 2016 (UTC)[reply]
2. The 2321 is in Sectioon 1.2; it is now linked from there to its article.
4. IBM dose not document ECKD as a separate command set. ECKD CCWs are a subset of CKD CCWS in every SCU manual I've looked at. CKD and FBA are the only tow command sets documented separately. Sure some commands cannot run in a chain with the five ECKD CCWs, but that applies to many other CCWs so its a distinction without substance.
5. What you have prioritized is what is alreaty posted in the two articles so depending upon future editors opinions and/or arbitration only one will survive, the current two or this sandbox. I really don't understand the sandbox's distinction betwee "History" and "Technical Details." There are no complete pairs of sections in the sandbox to help my understanding. So completing one woud be useful regardless of the final outcome and might actually help me understand and perhaps accept the distinction. I request subsections 2.8.5 Extended CKD and 3.5 ECKD Commands because they deal with the two issues we cannot seem to agree upon. Tom94022 (talk) 07:10, 5 January 2016 (UTC)[reply]
"The 2321 is in Sectioon 1.2; it is now linked from there to its article." No, the totality of the text there is "IBM 2321 Data Cell, 1 access mechanism per device"
The point is that there is essentially no information on the 2321 in your section 1.2, so it is not a viable replacemen for the text in my sandbox. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:18, 7 January 2016 (UTC)[reply]
  • IMO such detail is left to the History of IBM magnetic disk drives article, does it really matter what are the specific characteristics for this article? But if you want to go ahead and add all that detail go ahead. BTW, I think their is far too much emphasis and detail on DASD in the sandbox, the emphasis should be on storage controls as in the history article and the DASD detail in other articles Tom94022 (talk) 01:02, 10 January 2016 (UTC)[reply]
" IBM dose not document ECKD as a separate command set". See "3.0 Chapter 3. Nonsynchronous DASD Operations", Introduction to Nonsynchronous Direct Access Storage Subsystems, Storage Subsystem Library (First ed.), IBM, January 1990, GC26-4519-00. {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help)
  • There is not a single CCW in the cite. EVERY SCU description manual I have ever seen lists the 5 ECKD CCW in one list along with the all other CCWs. And the ECKD CCWs are useless without what you call "Basic CCW Commands" so even the section title makes little sense. It really should be "Nonsynchronous operation".Tom94022 (talk) 20:27, 5 January 2016 (UTC)[reply]
The issue is not where IBM puts CCW definitions, it is how IBM defines ECKD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:18, 7 January 2016 (UTC)[reply]
  • IBM defines 5 CCWs as the ECKD CCWs as a part of all CKD CCWs; the ECKD CCWs are useless without some of the earlier CKDs, so I think your section is better entitled "Nonsynchronous operation" and I strongly object to your then lumping technical details of all of the other features into one "Basic" section. Other features, e.g. multiple paths, as much deserve technical detail as nonsychronous operation. Tom94022 (talk) 01:02, 10 January 2016 (UTC)[reply]
"What you have prioritized is what is alreaty posted in the two articles so depending upon future editors opinions and/or arbitration only one will survive," Correct, and I obviously will work on the one that I believe should survive.
  • Well if your sandbox is the survior the two sections I've asked u to complete will survive so there is no less reason for you not to work on them. If you do complete them I might agree with you about the structure but at the very lease incorporate some of all of your material into the current sections. So there is no loss in honoring my request and you might benefit greatly. On the other hand, the duplicative work u are corrently doing may not survive. Tom94022 (talk) 20:27, 5 January 2016 (UTC)[reply]
" I really don't understand the sandbox's distinction betwee "History" and "Technical Details." History is what happened when; technical details is how does it work. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:20, 5 January 2016 (UTC)[reply]
  • I read what u say but don't understand how it will work in practice. We have a five dimensional matrix, commands, features, storage controls, devices and time. How we display this in a linear medium is a challenge and I simply don't understand how it would work in your outline. I think all dimensions are sufficiently and accurately coverred in the current tow articles; I have tried to accomodate your suggestions about them. IMO the current sandbox has nothing complete which is why I contiunue to ask u to do the two articles requested. What do you have to loose?
In practice there will be a history section describing what the various products addd or removed and there will be a technical detail section describing the various operations and modes without consideration for when they were introduced.
Look, the sandbox is a long way from being postable. If and when u replace the current two articles I will revert and then we will be in a talk, hopefully with some other particpands. I'd like to find a way to avoid this and save a whole bunch of effort. My request for you to complete the two articles is a step in this direction. Any ideas? Tom94022 (talk) 20:27, 5 January 2016 (UTC)[reply]
There is enough in the sandbox to allow others to judge the issues in dispute. I would prefer formal mediation before I do too much work. You that you want to avoid it, but so far you have not shown good faith and I see no to avoid a formal dispute resolution process. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:18, 7 January 2016 (UTC)[reply]

Mediation issues

[edit]

I believe I previously proposed mediation as a way to resolve any issues, but don't recall any response to my suggestion. Regardless, as a gf effort here are the issues I think need mediation, in order of priority:

  1. What content, if any, of Section 3 Technical details of this sandbox can be incorporated into the existing sections of the existing articles Count key data or History of IBM CKD Controllers.
  2. How should ECKD be presented in any Count key data articles?
  3. How should the IBM term of art "A-unit" and/or its synoynm "head of string" be used in any Count key data article?
  4. How much CKD DASD detail should be included in any Count key data articles?

I doubt if mediation is possible until there is agreement on issues to be mediated so I suggest we talk it out first to see if we can define the issues rather than preemptorily going to the Mediation Committee . Tom94022 (talk) 18:33, 10 January 2016 (UTC)[reply]

BTW, from what I understand about mediation we shouldn't request it until we have asked for help from Computer hardware task force and/or Third Opinion page. In either case we should come up with a neutral statement of issues. Tom94022 (talk) 20:25, 10 January 2016 (UTC)[reply]

Given our inability to communicate with each other, defining the issues in a fashion acceptable to both of us would already require mediation. We obviously don't agree on what constituter a neutral statement of the issues. If you accept mediation you can raise the definition of the issues as one of the topics to be mediated. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:30, 11 January 2016 (UTC)[reply]
The mediation rules are quite clear that we need to try other avenues first and at least one of them requires a neutral statement of the issues. Do u think the statements 2, 3 and 4 above are biased?
Which gets to issue 1. Please look again at User:Tom94022/Sandbox2 an alternative construction. I have revised it to comport with your structure. It now has a complete "History" section and a "Technical details" section, the latter being empty because I can't figure out what would go in there that isn't already in. So I will go thru what u have in this sandbox's Technical details section to add what u do have and see where that takes me. I'm probably not going to get to this for a while. Tom94022 (talk) 06:24, 12 January 2016 (UTC)[reply]
Your statements 2, 3 and 4 are not biased as additions to the issues I listed, but statements 1-4 are definitely biased as 'replacements for the issues I listed.
User:Tom94022/Sandbox2 an alternative construction is a dead link. Did you mean an alternative construction? You have not revised it to comport with my structure, because you don't have, e.g., Initial CKD feature set, under History. As I've repeatedly stated, my structure has a chronological summary of enhancements under History, with the information that you have under Features split among Overview, History and Technical details.
As an example, Overview might discuss command retry and History should definitely mention it in connection with the 2835/2305, but probably only Technical details should explain that it is requested via the combination of Status Modifier and Unit Check. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:07, 12 January 2016 (UTC)[reply]
Retrieved from "https://wiki.riteme.site/w/index.php?title=User_talk:Chatul/Sandbox/Count_key_data&oldid=699511379"