User talk:Chatul

From Wikipedia the free encyclopedia
Here are some tasks awaiting attention:


WikiProject Software to do list[edit]



IOCS[edit]

There was no point in e-mailing me stuff about IOCS - it just goes into a black hole. But do, please, post the information at Input/Output Control System (IBM). — RHaworth (talk · contribs) 01:01, 19 May 2010 (UTC)[reply]

Welcome[edit]

Hello, Chatul, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Our intro page provides helpful information for new users - please check it out! If you need help, visit Wikipedia:Questions, ask me on my talk page, or place {{helpme}} on this page and someone will show up shortly to answer your questions. Happy editing! Captain n00dle\Talk 09:33, 1 June 2010 (UTC)[reply]


Your message at Requests for feedback

You can find live help on Wikipedia's
help chat
Hello, Chatul. I have replied to your request for feedback.
Best regards, Captain n00dle\Talk 09:34, 1 June 2010 (UTC).[reply]
I replied to your request again. Regards, Captain n00dle\Talk 11:40, 1 June 2010 (UTC)[reply]
感情真的有第三者介入了嗎？我的先生他是否真心外遇了？ 2404:0:803E:9B97:C198:4B74:FD47:B05A (talk) 13:35, 14 April 2023 (UTC)[reply]

Tagging for verifiability in new articles[edit]

{{helpme}} If I write an article based on personal experience but no longer have copies of the relevant references, is it appropriate to tag parts of the text as a means of soliciting feedback from those having copies of the references? If it is appropriate, which of {{citation needed}}, {{cn}}, {{fact}} or {{verification needed}} should I use for the purpose.

Note that I'm not talking about cases where the facts are questionable, but simply cases where I need to add unavailable (to me) references for purposes of verifiability. Shmuel (Seymour J.) Metz (talk) 21:26, 1 June 2010 (UTC)[reply]

The first three are the same, and those would be better than the last. If you know or can find online some details of a reference, though (as in publisher, author, date, etc.), that can still be cited. —fetch·comms 21:37, 1 June 2010 (UTC)[reply]
The case I'm talking about is where I used to have copies of the relevant documents but no longer have a record of the titles or order numbers. In some cases I've been able to locate manuals with bitsaver and google, but not in all.
Does {{fact}} go before or after the text that needs a reference? Thanks. Shmuel (Seymour J.) Metz (talk) 21:49, 1 June 2010 (UTC)[reply]
After usually a sentence.[citation needed] mono 17:37, 2 June 2010 (UTC)[reply]

Are private communications legitimate as citations for verifiability[edit]

{{helpme}} Is it legitimate to cite private communications from the author of a program as verification of facts concerning that program? Shmuel (Seymour J.) Metz (talk) 17:11, 2 June 2010 (UTC)[reply]

No, because anything you cite has to be relatively easy for someone else to verify (and published by a reliable source). Killiondude (talk) 17:38, 2 June 2010 (UTC)[reply]

Input/Output Control System move[edit]

Hi there, I have moved the page to Input/Output Control System as I couldn't see anyone rejecting the request. It just needs the categories checked over and any other cleaning up, then you can remove the template up the top. Wongm (talk) 13:27, 6 June 2010 (UTC)[reply]

FEED[edit]

I've replied, in Wikipedia talk:Requests for feedback#Clarification of leadin for feedback requests.  Chzz  ►  03:19, 8 June 2010 (UTC)[reply]

...and again. Please don't be offended; I'm just saying...please edit it yourself. If you don't know how, that's another issue, just ask for help.

Signature[edit]

Re. your signature, [[User:Chatul|Shmuel (Seymour J.) Metz]]

Would you mind changing that a little; it is confusing when a sig does not include the actual username somewhere; While not an absolute requirement, it is common practice for a signature to resemble to some degree the user name it represents (WP:SIGEDITORIMPERSONATE).

If you'd rather have a different username, you could request a change of name in WP:CHU. Thanks,  Chzz  ►  19:48, 8 June 2010 (UTC)[reply]

Is this better? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:13, 9 June 2010 (UTC)[reply]

Dispute tag on Drum memory[edit]

Hi

I see that you may be a newcomer to wikipedia.

Yes.

It is normally best to insert the material, if you know it, be bold rather than tag the article in the way you have. Wiki editors may often respond in a negative way if they perceive "Although I know the info I am asking someone else to do the work" :¬)

When I add a {{disputed}} tag, I also add an item to my personal todo list and start looking for references. Meanwhile the original editor has a chance to revise the text his way if he wishes. Even if I wind up making the change, other may know of relevant references that I've missed, or may point out facts that I was unaware of. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:29, 18 June 2010 (UTC)[reply]

thanks Chaosdruid (talk) 11:00, 18 June 2010 (UTC)[reply]

PS I would remove any personal info, especially your name, as this has been known to cause problems for ppl in the past

Removal of IBM 2361[edit]

Why did you remove the references to the IBM 2361 Core Storage device from the article on the IBM System/360? Do you dispute the reality of the device? I have added a section to the talk page of the IBM System/360 page to discuss this edit, please respond there. John Sauter (talk) 20:21, 20 June 2010 (UTC)[reply]

What is the dispute in the History of the floppy disk article[edit]

See http://en.wikipedia.org/w/index.php?title=History_of_the_floppy_disk&action=historysubmit&diff=369454727&oldid=369453094 Please put something on the Talk:History of the floppy disk page. Tom94022 (talk) 00:02, 22 June 2010 (UTC)[reply]

I was in the process of doing so. The dispute is in the changes that you reverted, dealing with the loading of microcode. If you want I can provide references in the article talk page. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:12, 22 June 2010 (UTC)[reply]

Modern Variable Block Size HDDs[edit]

I repeat my request that you name one HDD currently for sale that supports variable block sizes. Until you have some evidence, you really should not change my statement about "Modern HDD" to "Most modern ..." Tom94022 (talk) 02:31, 30 June 2010 (UTC)[reply]

Why do you assume that I have no evidence? IBM's flagship operating system doesn't support anything but CKD and ECKD, despite requests from customers. Google for DS8000 for one example. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:49, 30 June 2010 (UTC)[reply]
Because I have repeatedly asked for evidence and you have not responded. There are only five HDD manufacturers in the world and none of them offer variable block length devices. The hardware supporting IBM's flagship operating system comes from these five manufacturers and the subsystems emulate CKD and ECKD on fixed block devices. So unless you know of something different there is no evidence. Tom94022 (talk) 15:59, 30 June 2010 (UTC)[reply]
Evidence of what? I've provided you with citations and quotes from them. Further, you keep switching the terms of debate. When there is a dispute as to what information is presented to the host, then statements about the underlying hardware are irrelevant. When there are disputes about the underlying hardware, then statements about the host interface are irrelevant. When there are disputes about both, then context is paramount. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:56, 1 July 2010 (UTC)[reply]
OK I get your point. I changed the language to "HDDs ... appear at their interfaces as a contiguous ..." This should end this discussion. Tom94022 (talk) 16:19, 1 July 2010 (UTC)[reply]

Last CKD HDD[edit]

Do you have any evidence to support your assertion that "The last IBM HDD to directly support variable block size was the IBM 3350?" I have provided you evidence that the 3380 and the 3390 supported native CKD. I also speak from personal experience with the 3380 and just had lunch with one of the principal engineers on the 9345 who also was of the opinion that the 9345, 3390 et al were native CKD DASD. Please produce some evidence to support your assertion and then we can discuss this. Tom94022 (talk) 02:36, 30 June 2010 (UTC)[reply]

Yes, the fact that IBM customer have been asking IBM for decades to provide MVS support for the native formats and the fact that the space calculations for the 3375 and later disks involved rounding off to fixed length cell sizes IBM (November 1977). OS/VS2 System Programming Library: Data Management Release 3.8. Fourth Edition. p. 124. GC26-3830-3. If bit 3, byte 1 of word 4 is one, this byte contains the modulo factor for a modulo device. {{cite book}}: Unknown parameter |separator= ignored (help)
A more recent version is IBM (2007). z/OS V1R8.0-V1R9.0 DFSMSdfp Advanced Services. SC26-7400-07. {{cite book}}: Unknown parameter |separator= ignored (help), but it lacks mention of the older devices.
You provided no evidence that the 3380 and 3390 provided native CKD support. The primary issue is the underlying hardware, not the appearance presented to the host.
And the hardware manuals all say they are CKD machines, e.g., IBM 3390 Direct Access Storage Introduction, GC26-4573-03, May 1995, Chapter 2, "All 3390 models store data using the count-key-data record format." This is a hardware manual not the SRL manuals u quote. Tom94022 (talk) 15:55, 30 June 2010 (UTC)[reply]
No, it is not a hardware manual, and no, it does not say anything about the underlying hardware; it is describing what is visible at the channel interface. And BTW, it is part of the SRL. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:23, 30 June 2010 (UTC)[reply]
Since the article is about HDDs and not about subsystems, the presentation at the channel level is not particularly germane to the article. Tom94022 (talk) 05:55, 1 July 2010 (UTC)[reply]
Then it shouldn't be making statements about the host. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:44, 1 July 2010 (UTC)[reply]
Your personal experience was on a different device. A PCM 3380 is not a 3380. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:56, 30 June 2010 (UTC)[reply]
A PCM 3380 must support the identical track formatting +/- 0 bits or it is not Plug Compatible. You must have used PCM DASD in your vast experience. Tom94022 (talk) 15:55, 30 June 2010 (UTC)[reply]
PCM DASD must present an identical appearance at the channel interface; what happens under the covers need not be identical. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:23, 30 June 2010 (UTC)[reply]
At the time of the 3830 it was not possible to design a PCM 3380 compatible at the A-Box (the lowest level of attachment) and not have identical track formatting +/- 0 bits because as you well know channel operations were synchronous to the disk. Any deviation, sometimes as little as one bit time could cause unpredictable results and I have personal experience debugging and fixing such underlying bugs. With non-synchronous channels the degree of commonality was less severe but they came much later than the 3380. Tom94022 (talk) 05:55, 1 July 2010 (UTC)[reply]
Actually, I don't know; the channel does not connect to the head of string, but to the control unit. I don't know the internal logic of the 3880. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:44, 1 July 2010 (UTC)[reply]
And I presume u don't know the internal logic of the controller in the A-Box. The article is about HDDs; in IBMs terms that is a B Box.
Furthermore, according to IBM:
IBM (January 1990). Introduction to Nonsynchronous Direct Access Storage Subsystems. GC26-4519-0. Since he introduction of System/360 in 1964, nearly all IBM large and intermediate system Direct Access Storage devices have use a CKD track format. ... CKD devices and their storage controls operate synchronously with the system channel. Channel data transfer for each search, read or write command occurs as the target data field passes the read/write head on the device.
This is long after the 3380 shipment and well after the 3390 first shipment. Again note the distinction between the device and the control unit. This article is about devices. Tom94022 (talk) 17:19, 1 July 2010 (UTC)[reply]
As usual, the Devil is in the details. Look for the definition of synchronous in the glossary of the manual you quoted from. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:59, 1 July 2010 (UTC)[reply]
Since you have the manual please read Chapter 2, I think you will find that the glossary is the definition of what is synchronous and the chapter describes how it was achieved in CKD devices such as the 3380 and 3390. I can tell you from experience it was no different beginning with the 2311. Tom94022 (talk) 18:22, 1 July 2010 (UTC)[reply]
Additional citation IBM (September 2008). Device Support Facilities R17 (ICKDSF R17) Guide and Reference. Thirty-fifth Edition. GC35-0033-35. When you emulate a CKD device on the 9313, 9332, or 9335, you can use the same commands and parameters that you use when not emulating a CKD device. {{cite book}}: Unknown parameter |separator= ignored (help)
The fact that the blocks written to a device have a modulo size of either 32 or 34 bytes does not make the device a fixed block device. On one track there can be records with different physical block sizes, modulo 32 (or 34) of 32, 64, 128, ... in any combination of up to the track capacity, and the track can then be rewritten into any other combination. This is in marked contrast to the current structure where every block on the drive is the same size. If you want to make the distinction between CKD with and without modulo block limitations that is a very fine point but I think u go way to far when you say a CKD device with modulo block size restrictions is neither a CKD device nor a variable block size device. And the distinction is way TMI. Tom94022 (talk) 15:55, 30 June 2010 (UTC)[reply]
Did you bother to read the citation I provided? The quotation used the wording emulate a CKD device .
Sorry if I confused you by placing this comment here but I thought it was pretty obvious that this comment was directed to your first cite since only your first cite mentions the modulo phenomena. Now will you respond to my point about the existence of modularity in the size of the key and data fields of the later subsystems does not make them fixed block nor does it make them not CKD? Especially given the fact that the IBM documents say they are CKD? Tom94022 (talk) 05:55, 1 July 2010 (UTC)[reply]
There are no imposed blocks sizes in CKD. So whether there is a palette of imposed block sizes or only a single imposed block size, it's not CKD.
Actually either there are or there are not - see my bulleted comment below and you can't have it both ways. It appears to me that this is a distinction without substance that only you are making. All the IBM device documents clearly say the 3380 and 3390 were CKD devices.
There's more than one IBM document concerned with a given device. An introduction is not a reference manual, much less a low level hardware manual. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:44, 1 July 2010 (UTC)[reply]
Actually according to the 3390 document it is the lowest level document short of the maintenance documents and a part of the Storage Subsystem Library. Tom94022 (talk) 17:19, 1 July 2010 (UTC)[reply]
There is no the 3390 document; the document that you cited, GC26-4573-03, is not a low level manual at all. Now, if you referred to a CE manual as the 3390 document, I might consider that reasonable. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:59, 1 July 2010 (UTC)[reply]
There is nothing lower than GC26-4573-03 other than the CE manuals. There is no reference manual for the 3390 Tom94022 (talk) 20:18, 1 July 2010 (UTC)[reply]
BTW, it is not clear to me that this modularity limitation is required by the device controller and it is certainly not required by the drive which presents a totally available track to the controller! It may very well be a system imposed constraint perhaps coming from paging limitations. That is the device may be able to write a 1 byte data field but the system never issues that command. One place to look for an answer to this is the maintenance manuals for the A-Boxes where such detail would be exposed. Perhaps there might be some explanation back in the time when it was first implemented, probably circa 3380, but as a PCM subsystems designer I can recall no discussion which makes me think it was a system imposed constraint. One other point, although the space calculation is modularized I am pretty sure there is nothing that stops the channel programmer from formatting a track with 12 byte data fields, which further suggests a system limitation and not a device limitation. FWIW, the hardware will pad handle the distinction between a one byte logical record and a 32 byte physical record by padding and/or truncating again further suggesting a system limitation. Tom94022 (talk) 15:55, 30 June 2010 (UTC)[reply]
I'm trying to find someone that still has the CE manuals for old DASD, but not everyone is a pack rat like I am. And even I got rid of some dead trees that I now wish I had kept. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:23, 30 June 2010 (UTC)[reply]
  • I am looking at the IBM 3390 Storage Control Reference manual, GC32-0099-04, 5th Edition , Sept 1991. In the section on Format write commands I find no modulo constraints on the size of the Key or Data fields, any number is permitted from 0 to field max. So at this level there is no difference from any earlier CKD device!
The difference is in the calculation of track capacity, not in the data transfered from the host for a single record. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:59, 1 July 2010 (UTC)[reply]
I think we agree that from the host CCW perspective there is no difference between a 3350 and a 3380 other than those coming from geometry and performance, they both are CKD devices!
Well, there are some new CCW opcodes, but those are for other things. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 1 July 2010 (UTC)[reply]
  • What is different about the 3380/3390 than the 3350 is that the formula for determining track capacity (p.82) is now modulo but that doesn't change much at all! In every CKD device from the beginning, the written data and key fields were always larger than the KL or DL specified in the CCW and/or Count field, so contrary to your statement above, CKD did impose a block size from the very beginning! In the 3380/3390 they are just a little bit larger and little bit variable due to the rounding up. For example, the overhead of a Data Field on a 3380 is 1309/hex bytes (Sense bytes 23+24) while the modulo factor is 02/hex bytes (sense byte 22) - this is nothing, 2 parts in 1309 maximum! And as best I can tell it is not visible at the host interface, it only affects the number of records that can fit on a track and by only a very small amount. IBM's literature says the 3380 and 3390 are CKD devices; what is it about this additional modulo calculation that causes you to find a distinction? Tom94022 (talk) 17:19, 1 July 2010 (UTC)[reply]
I'm not sure what statement you're responding to, but it's not the statement I wrote. Adding fixed padding is not the same as imposing a specific block size. On the 3350 and earlier the size of the padding depended only on whether KL was zero and whether DL was 0; on the 3375 and later the size of the padding depended on the exact value of KL and DL.
Your statement was "There are no imposed block sizes in CKD." At the physical level there are indeed imposed block sizes in all CKD machines!
Added overhead is different from an imposed block size. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 1 July 2010 (UTC)[reply]
There is no imposed size of the key or data fields of the 3380 or 3390 just like any CKD drive; the physical block is larger than the user length of the fields and the calculations have changed over time. FWIW, the physical block length calculations for the data field are:
  • 2314: constant + int(1.043*DL)
  • 3330 - 3350: constant + DL
  • 3380 - 3390: constant + DL + DL mod 32
Just because the physical blocks are now oriented to any 32nd byte (3380) as opposed to any byte (3330) or not oriented to any byte (2314) doesn't change the behavior of the drive. Tom94022 (talk) 23:33, 2 July 2010 (UTC)[reply]

The forumlae differ but there is a minimum physical block size for each field, for example the 2311 minimum physical data field was 109 bytes (CL=0) and the physical block sized increased byte for byte as the CL increased. In a modulo CKD machine the physical block size increases from a minimum but it is not linear because it is a function of the modulo calculation. A different formula doesn't make it not a CKD machine, nor does in not make it a variable block size machine.

You haven't read IBM's literature; you've only read the manuals that were easy to come by. The relevant manuals are the CE manuals or design documents, which neither of us has copies of.
I have read the published IBM literature that I happen to have in my files and that which I have found on the web, all of which says the 3380 and 3390 were CKD machines. You have not produced one document that says otherwise. You apparently conclude from the modulo calculation that they are not CKD drives - if they are not CKD drives what are they? Do you think they are fixed blocks like the current drives, with blocks of 32 (or 34 bytes), each separated by some padding and including some form of block ID? Tom94022 (talk) 20:18, 1 July 2010 (UTC)[reply]
The material that you found on the web is the nontechnical stuff.
You seem to assume the worst. I did not conclude from the modulo calculation that they are not CKD drives; rather, I presented that as evidence of what I already knew from other sources; people who actually worked with the drive developers. Unfortunately, my best sources threw out a lot of the documentation that I would otherwise have asked them to contribute to bitsavers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 1 July 2010 (UTC)[reply]
OK, sorry about the assume - I should have said, you know from personal contacts that they are not CKD drives and you think that their modular nature proves that. I disagree with your proof for reasons stated hereinabove. What you or I know from personal contacts does not constitute a reliable source for the purposes of Wikipedia articles and so far you have not produced any such material to support an assertion that the 3350 was the last CKD drive. Whether the material I read was technical or not, I have identified IBM published a reliable sources that state the 3380 and the 3390 were CKD drives. I happen to live near and know many of the IBM San Jose developers of these drives and they do not agree with you as to your conclusion based upon the modulo nature of these two drives, but likewise I cannot cite them as reliable sources. Again I ask, if they are not CKD drives what are they? Tom94022 (talk) 23:33, 2 July 2010 (UTC)[reply]
Where do you believe that modulo factor comes from if not from a hardware imposed cell structure? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:59, 1 July 2010 (UTC)[reply]
That is a good question. I suspect it comes from data encoding and/or error correction requirements that require the physical block to have a modularity; however there is no requirement that adjacent blocks be the same size. I like your use of the term cell, a block must consist of an integer number of cells but there is no requirement that the blocks be of any size. Blocks can be count key or data blocks comporting to IBM CKD architecture. This is in contrast to today's machines where the blocks are fixed in size and the CKD is overlayed upon them. Tom94022 (talk) 20:18, 1 July 2010 (UTC)[reply]
Actually, cell is IBM's term rather than mine. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 1 July 2010 (UTC)[reply]
  • May I suggest a CKD drive is one where the physical gaps on the medium are sized to support Synchronous Operation (using the IBM definition u cited)? Tom94022 (talk) 23:33, 2 July 2010 (UTC)[reply]
The physical gaps, if any, are not part of the CKD architecture. Each CKD device had it's own unique characteristics. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:22, 5 July 2010 (UTC)[reply]
Actually the gaps are critical to successful native CKD operation since there must be sufficient space between fields (i.e., time) for the channel to turnaround and issue the correct next command. As an example, this simple command chain will overrun if the gap between the count and data fields is too small or the channel too slow:
Search ID Equal
TIC
Write Data
With channel retry there will not be an error but it will run very slow compared to a properly functioning subsystem because it will miss revolutions.
I may have worded that improperly. The existence of gaps is certainly necessary for native CKD, but the sizes of the are constrained by factors outside of the architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:26, 8 July 2010 (UTC)[reply]
You might take a look at [10] and [11] which I happen to think are correct but unfortunately are not primary sources. It is correct that the 3350 was the last IBM drive that was not cached in the Storage Director, but neither were the 3380 nor the 3390 until 1991. As part of the 1991 ESCON introduction IBM announced caching as the 3880-2x and 3990-3 Storage Directors. This occurred well after the 3380 (June 1980)and 3390 (Nov 1989) were first introduced. Prior to caching they were native CKD drives; caching didn't change them, but it was necessary for the subsystem to support ECKD which in turn was necessary for ESCON which because of the long cable lengths (speed of light) could no longer support synchronous operation of the drives - the gaps could be zero but the information could not travel the distance and back and still give the channel enuf time to respond. Synchronous subsystems were replaced by non-synchronous subsystems but the DASD didn't change to FBA until RAMAC. On short channels the running CKD commands a 3380 or 3390 DASD appeared to the system and performed as any other CKD DASD.
Well, http://www.answers.com/topic/kd-4 claims Count-key-data (CKD) was built into IBM hardware through the 3330 and then implemented in microcode through the 3390 and 9340 series.
As for http://www.answers.com/topic/count-key-data, it's just a copy of the Wiki article, which I plan to correct and expand as soon as I get a reading on the proper level of detail
Buffering of CKD on S/370 came in with the Speed Matching Buffer (SMB) on the 3880; the formal cache support came in on the 3880-11 and 3880-13. The 3880-2x models simply enhanced the facilities added by the 3880-1x. Those devices did do caching for a 3350 and did attach to bus&tag channel.
Of course, you could legitimately claim the old Airlines buffer as the progenitor, although it was a one of a kind product: IBM. IBM 2314/2844 Multiplex Storage Control Feature-Airlines Buffer. A26-5714. {{cite book}}: Unknown parameter |separator= ignored (help) Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:26, 8 July 2010 (UTC)[reply]
So i think we agree that the use of a buffer does not change a native CKD device into something else. Tom94022 (talk) 21:00, 9 July 2010 (UTC)[reply]
Structurally the track layout of a native CKD drive is very different than that of a FBA drive emulating CKD. In a native CKD drive the key and data fields are contiguous and exactly equal to the KL and DL specified in the count field while the gaps between vary by small amounts but always are just sufficiently long to allow the worst case channel turnaround - in the 3380 and 3390 the gaps round up modulo a small number, in the 2314 the gaps were extended by a percentage of the KL or DL, so what. In an FBA drive the gaps and information fields are all the same length, the latter usually 512 bytes; an FBA drive emulating a CKD drive fits the key and data fields into one or more of these 512 byte blocks which may not be contiguous internally nor between fields. I suspect the count fields are compacted and not contiguous or perhaps they are prefixed to the key and data fields (interesting design trade off). As a consequence the subsystem using FBA drives to emulate CKD cannot perform synchronous to the drive and its performance suffers substantially with regard to a native CKD drive executing the same CKD commands (all other performance parameters held equal). Tom94022 (talk) 18:07, 5 July 2010 (UTC)[reply]
  • Perhaps you can state what you think are the characteristics of a native CKD drive or subsystem? Tom94022 (talk) 18:07, 5 July 2010 (UTC)[reply]
Basically a bit-oriented recording systems and electronics to generate the proper gaps. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:26, 8 July 2010 (UTC)[reply]
I'm not sure what u mean by a "bit-oriented recording system" since I would characterize all as byte oriented, but from the 2311 thru the 3390 the all used the electronics to generate the proper gaps. Tom94022 (talk) 21:00, 9 July 2010 (UTC)[reply]
  • Please take a look at Figure 3 of US Patent Number 5,446,853 (try [12] if the link doesn't work). While this is an STK patent I am pretty sure the track format disclosed is the IBM 3380 or very close thereto (the spec discloses the 3380 as "typical" and the modularity is 32). Remember, based upon my experience in those days to be plug compatible on a synchronous CKD subsystem you had to have the track format identical to the byte +/- 0 bits otherwise you ran into overrun or truncation problems. What this shows is that the blocks start and end on 32 byte boundaries, the fields within the blocks are not so constrained (e.g. the HA Block starts at segment 0 but the HA Field starts at segment 15.75, etc.) It further shows that the data and key field length are precisely that specified in the CCW. Finally it states, "This format is the standard count key data format well known in the field of data storage systems." (Col 7, 49-50) If this is how the IBM 3380 operates (and I believe that to be true) then it seems to me this it is a synchronous CKD subsystem. So far I have been unable to find any IBM patent with such disclosure nor have I been able to find any CE manuals so this maybe the best we can do. Tom94022 (talk) 17:18, 13 July 2010 (UTC)[reply]
The diagram seems to support my claim that it's FBA under the covers, but the text reads like it was written by a lawyer and I spotted enough errors that I wouldn't cite it. I found a CE handbook on the web, but it doesn't have enough detail.
IBMs Definition of FBA disk drive

fixed-block architecture disk device (FBA disk device)
A disk device that stores data in blocks of fixed size. These blocks are addressed by block number relative to the beginning of the file.
(emphasis added)

IBM z/OS CICS

The diagram shows the device's addressable blocks include the variable length key and data fields and the count field, and that the addressing is by record (BBCCHHR) and not relative to the beginning of the file. Therefore according to IBM the device in the patent is not an FBA device. The unaddressable cells (or segments) like all the other unaddressable control, recovery and gap information is not relevant to the type of device. What matters is the device's addressable blocks. Furthermore:
IBMs Definition of CKD disk drive

Count-Key-Data
Count-Key-Data (CKD) is a DASD data storage architecture in which the data is stored in variable-length records. Each record contains a count field, usually followed by a key field, followed by the actual data of the record. The count field contains the cylinder number, head number, record number, and the length of the data. The key field contains the record’s key (search argument).

IBMs z/VM Software Information Center

The patent's diagram shows the device's track format has the CKD fields which makes it a CKD device according to the IBM definition. Note that the same device could be formatted into a FBA device by for example just making all the record's KL=0 and DL=any number but that would be a terrible waste of space since the gaps would be far larger than required. One might to that expeditiously but most (all) OEMs took the IBM removable CKD media and reformatted it into a FBA architecture with smaller gaps and thereby achieving higher capacity. Tom94022 (talk) 21:31, 16 July 2010 (UTC)[reply]
The timing issues are different depending on whether you are talking channel-to-controller, controller to string controller or string controller to drive. The gaps must be large enough to present SM to the channel and for the channel to process the next+1 CCW. Whether that is done by large gaps between sectors or by skipping sectors is unimortant to the channel, although it might have performance ramifications. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:34, 15 July 2010 (UTC)[reply]
The timing issues are indeed different but more importantly they are cumulative and the two biggest constraints are the speed of light (how far away the disk is from the host) and the decision making time at the host channel interface - the further away one goes the less time the channel has. The reason CKD gaps are so much larger than FBA gaps is to give the host/channel sufficient time so as to avoid overruns. That's why the BMUX cable length was limited on high performing DASD. The ESCON distances left no time for the channel necessitating an architecture change. Tom94022 (talk) 21:31, 16 July 2010 (UTC)[reply]


Margin reset Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:29, 22 July 2010 (UTC)[reply]

Of course a simulated CKD device will include the data from the count, key and data.

IBM's fixed Block Architecture is actually more complicated than what you describe. Blocks are addressed from the beginning of the disk, but there is a channel command called Define Extent that specifies what blocks are relevant to the current operation. It's possible that LOCATE uses relative block addresses, but if so they would be relative to whatever Define Extent had specified, regardless of what any particular file might be using.

If you don't like using FBA as generic, call it sectored: the fact remains that the track layout is fixed blocks rather than variable, and that the fields are package into those blocks: IBM (June 1989). Storage Subsystem Library IBM 3390 Direct Access Storage Reference Summary (PDF). First Edition. GX26-4577-0. 3390 Mode Each 3390 Mode track is divided into 1720 user data cells (with IBM standard R0) or 1749 user data cells (without IBM standard R0 record). A record can occupy from 20 to 1749 of these cells. The number of cells (Space) occupied by a record is a function of the Key Length (KL) and Data Length (DL) as specified in the count area of the record.

It doesn't matter that IBM uses the nomenclature cell, and it doesn't matter whether the cell sizes are determinned by holes in the disk, low level formatting at the factory or by the formatting of the DSF command INSTALL; what matters is that you wind up with a track layout of fixed sized sectors and that each of the areas of a CKD record is mapped into a string of those sectors. CKD device is not the same as native CKD device.

  • Nomenclature doesn't matter but it sure can confuse. What does matter is that in an FBA device there is a gap between each fixed block otherwise the block cannot be updated in place - accordingly, the blocks and gaps are fixed in place on the track of a FBA drive! The "cells" of the 3380 and 3390 have no such gaps - they are contiguous! An examination of a track will find the physically recorded count, key and data fields are exactly equal to the lengths specified, not modulo the cell length (as in an emulating device) and the key and data fields stop at any arbitrary location on the track. The gaps and fields (after R0) move about on the track as a function of the number of records and each record's KL and DL. That is why the 3380 and 3390 can support Synchronous operation whereas I know of no subsystem with FBA drives supports Synchronous CKD operation - do you? The reason of course, is that Synchronous operations requires relatively speaking very large gaps between the CKD fields in order to support the channel turnaround. One could map the CKD fields into FBA blocks and map the CKD required gaps as empty FBA blocks but that means u need a lot of wasted space to accommodate the shortest fields; for example, using the 3390 with a KL<23 and a DL=1 yields 57 records per track but supporting the records by mapping would require a gross track capacity of about {[((3 gap blocks/field +1 data block/field)*3 CKD fields/record]*57 records/track + 8 HA RO fields/track}*512 bytes/field = 354,304 bytes/track or a utilization of 1254/354,304 = 0.3%. This then maps to a 3390 full track R1 length of 56,664 bytes giving a best case utilization of such a machine at 16% - I suspect this is why no one supports Synchronous CKD on FBA subsystems. IMO, any drive incorporated in a subsystem that supports Synchrouous CKD is a native CKD drive - its the gaps ;-). Tom94022 (talk) 20:07, 22 July 2010 (UTC)[reply]
What is your evidence that the cells of a 3375. 3380 or 3390 are contiguous?
There is not enough unformatted track capacity to allow for any gaps between the cells on any of these products. One can estimate the unformatted track capacity from the data rate and rotational period and then add up the capacity used by the various fields. If there were a gap between each cell it would show up as a substantial difference in the unformatted track capacity and the user available capacity (including gaps and control information). This is because the gaps between cells need to allow space for read to write and write to read transitions along with at least a minimum of some control and checking information. The gap for example on the 3310 is 21 bytes for a 512 byte sector. Reducing the data field length doesn't really change the gap length, perhaps some of the control and checking info can be somewhat reduced.
So, for example on the 3375:
Estimated unformatted track capacity = 20.2 msec * 1.859 MByte/sec =
37,536 unformatted bytes per track (rounded to nearest 32)
1,173 unformatted cells per track
Byte consumption by CKD format =
36,000 available for user data in IBM CKD format (RO and HA)
+ 448 allowance for RO
+ 224 allowance for HA
---------------
36,672 bytes used by format
The difference of 864 bytes is less than one byte per cell and most of it is consumed by defect skipping so there is simply no space on the track for gaps between cells.
I could do a similar calculation for the 3380 and 3390 but I am sure the results would be the same. If you don't believe it, why don't you do the calculations, the format data are here and the drive latency and data rate info are readily available.
BTW, contiguous cells are what is shown in the STK patent which I believe to be the 3380 format.
Tom94022 (talk) 18:56, 28 July 2010 (UTC)[reply]
As for writing in place, that capability exists for CKD as well.
Of course it does, but writing in place doesn't exist for the cells of the 3375 et al. Tom94022 (talk) 18:56, 28 July 2010 (UTC)[reply]
How did you examine the track? If you were using CKD commands, then the results you describe would be necessary regardless of how the data were actually recorded. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:34, 27 July 2010 (UTC)[reply]
If we had the CE documents we might find an actual track layout, but in its absence the best I can do is the calculations above. Tom94022 (talk) 18:56, 28 July 2010 (UTC)[reply]

BTW, those sectors have nothing to do with the sectors refered to in Set Sector.

As a side note, the CKD architecture does not provide for direct addressing of blocks, other than HA and R0; you have to either do a search or chain from a previous I/O that has established orientation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:29, 22 July 2010 (UTC)[reply]

  • More supporting evidence:

"When data is stored on the DASD's included in Group 1 in Table 2, the data records are stored in count-data format or count-kev-data format.
…
Table 2, Group 1: 3330 thru 3380 inclusive of 3375.
Table 2, Group 2: 3310 and 3370
…
When data is stored on the DASD's included in Group 2 in Table 2, the data records are not stored in variable- size blocks with a variable number of gaps (depending on the number of records per block, and blocks per track). Instead the recording surfaces of the disks are preformatted to accept equal-length blocks. Each block ran hold 512 bytes of user data. The maximum capacity or the DASD is not dependent on whether the records have keys, the number of records that can be fit on one track, and so on. In fact, the user need not be aware of the number of bytes per track, tracks per cylinder, or cylindcrs per DASD. Only the maximum number of blocks is of concern to the user."

Marilyn J. Bohl, "Introduction to IBM Direct Access Storage Devices and Information Processing," J. Int. CMG Conference, 1984

Of course this was published before the 3390, but since it and both the 3375 and 3380 use a cellular structure to build CKD track formats, that means the 3390, like all the others in Group 1 are native CKD drives.Tom94022 (talk) 16:29, 23 July 2010 (UTC)[reply]
More to the point, it's a secondary, non-technical source. The manual that I quoted from is an official IBM document. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:34, 27 July 2010 (UTC)[reply]
Actually IBM's Ms. Bohl's says the same thing in Introduction to IBM Direct Access Storage Devices, SR20-4378-00, SRA an IBM Subsidiary, (c) 1981, which, to your point, is a an official IBM document which in the preface states, "This text replaces the existing publication, Introduction to IBM Direct-Access Storage Devices and Organization Methods (IBM Order No. GC20-1649). The intent of the author, SRA, and IBM is that the text be updated, as appropriate, to maintain its currency and coverage." Tom94022 (talk) 16:13, 28 July 2010 (UTC)[reply]
IBM instructional texts and Redbooks are secondary sources. Instructional texts for computers are generally error prone. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:19, 29 July 2010 (UTC)[reply]
    • After a lot of asking, I found out from a reliable IBM source that the cellular nature of these last native CKD drives is related to a two level error correcting coding architecture (see e.g. US 4,706,250) which has nothing to do with FBA and in fact may be applied to either FBA or CKD track architecture. The 3380 implementation is described in Section 10.12, "Multiburst Correction In Magnetic Disk Storage," Magnetic Storage Handbook, Second Edition, (c)1996 which discloses the cells as contiguous and without the inter-cell gaps that are necessary for FBA. This original research on my part merely confirms what the many IBM publications states and rebuts the assumption that the cellular nature of these last CKD drives makes them FBA drives under the skin. Therefore, I believe it is consistent with Wikipedia policy that the 3390-3 be identified as the last native CKD drive citing the Introduction to Nonsynchronous DASD manual as a reference. I will also summarize this long dialog in an appropriate article, perhaps the CKD one. Comments? Tom94022 (talk) 21:57, 5 August 2010 (UTC)[reply]
I've asked a couple of people who worked with the developers to read it and comment. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:39, 6 August 2010 (UTC)[reply]

Recent edit to HDD article[edit]

You might want to join the dialog at the HDD page see: what Alexdi has done. Tom94022 (talk) 21:11, 2 July 2010 (UTC)[reply]

Thanks. Does he think that No technology exists untill Bill Gates invents it.?
I added a comment; I'm not sure whether it would be appropriate to throw in references to the use of disks on various mainframe operating systems, or whether that would be TMI. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:02, 2 July 2010 (UTC)[reply]

IBM System/360 I/O channel description[edit]

I plan to add explanations of the channel programs for CKD and ECKD to Count Key Data; those explanations will depend on some details of IBM's channel architecture that are currently not present in either Channel I/O or IBM System/360. I've considered three options:

  1. Add the material to Channel I/O
  2. Add the material to IBM System/360
  3. Include the material in the update to Count Key Data

Were I to be writing a complete description of the channel architecture, I would rule out the third option. However, I have reservations to adding what amounts to a stub to one of the eixting articles. I'm soliciting advice as to which route is the most consistent with Wiki policy. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:58, 9 July 2010 (UTC)[reply]

I'm no expert in that specific area, and I haven't bothered to do more than skim over it, but...it seems to me like you should add the stuff that is generic to Count Key Data to that article, and the stuff that is specific to e.g. IBM System/360 to that article. As the latter uses the former, then a simple sentence in the latter saying so, with a wikilink to the former, should cover that.
Do you feel that I should do it there even if the material specific to the channel architecture is woefully incomplete? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:30, 9 July 2010 (UTC)[reply]
If I've got that totally wrong, then I'm sorry; I suggest you're more likely to get an expert if you asked on Wikipedia talk:WikiProject Computing - or, you could try and explain a bit more about it here, and I might be able to help more. I'm leaving the helpme above 'live', because it's possible another helper might know the area better than I.  Chzz  ►  17:11, 9 July 2010 (UTC)[reply]
I'll try to explain without getting into TMI. An I/O operation on the S/360 presents a chain of channel command words to the channel, one at a time. The channel presents status flags at the completion of the operation. Only about half of those flags are relevant to the text that I want to write for CKD and ECKD. I planned to omit explanations of the flags that I did not intend to refer to, and to omit several other details that, while important, don't relate to CKD. So the basic question is whether it is appropriate to put the text into an article where the reader would legitimately expect more complete material? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:30, 9 July 2010 (UTC)[reply]
  • I think they are separable which means yr item 1 or a separate article. I would either add it to I/O Channel which would benefit from a section on the S/360 channel or build a second article on S/360 & 370 I/O Channel with a link therefrom. CKD and ECKD are more about DASD implementation on the IBM I/O Channel and could be linked from a generic S/360 & 370 I/O Channel article or section. Just my 2 cents. Tom94022 (talk) 20:54, 9 July 2010 (UTC)[reply]
I agree that the B&T, ESCON and FICON channels are notable; if I were planning to do a complete description then I would put it in either a separate Bus and tag channel article, Channel I/O or IBM System/360 , with wikilinks among the articles. My problem is that I've already taken on too many editing tasks to be able to do the topic justice; I only plan to write enough to make the CKD and ECKD narrative intelligible. I believe that I'll need to explain CE, DE, UC, UE and SM flags, but not, e.g., protection key checking. So would it be proper to add a section to one of those articles that I don't expect to complete any time soon? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:52, 9 July 2010 (UTC)[reply]

Speedy deletion nomination of OS/VS2[edit]

A tag has been placed on OS/VS2 requesting that it be speedily deleted from Wikipedia. This has been done under section A1 of the criteria for speedy deletion, because it is a very short article providing little or no context to the reader. Please see Wikipedia:Stub for our minimum information standards for short articles. Also please note that articles must be on notable subjects and should provide references to reliable sources that verify their content. You may wish to consider using a Wizard to help you create articles - see the Article Wizard.

If you think that this notice was placed here in error, you may contest the deletion by adding {{hangon}} to the top of the page that has been nominated for deletion (just below the existing speedy deletion or "db" tag - if no such tag exists then the page is no longer a speedy delete candidate and adding a hangon tag is unnecessary), coupled with adding a note on the talk page explaining your position, but be aware that once tagged for speedy deletion, if the page meets the criterion, it may be deleted without delay. Please do not remove the speedy deletion tag yourself, but don't hesitate to add information to the page that would render it more in conformance with Wikipedia's policies and guidelines. Lastly, please note that if the page does get deleted, you can contact one of these admins to request that they userfy the page or have a copy emailed to you. Coolug (talk) 21:57, 26 July 2010 (UTC)[reply]

ORVYL and WILBUR article updates[edit]

Thanks for your corrections and additions to the ORVYL and WYLBUR article. I noticed you added "There are also proprietary versions." I saw something called WYLBUR, Inc., but that was from an article published in CACM back in 1973. A simple Google search didn't turn up anything that looked like proprietary versions. Do you know if proprietary versions are still available? Is there a URL or a citation we could use in the article? Jeff Ogden (talk) 19:13, 15 August 2010 (UTC)[reply]

I believe that there were proprietary versions from all of
There was also something called INTERACT, which I believe was a rebranded Wylbur.
I can provide you with the home page for SuperWylbur™ but I have no information about OBS. I've got a friend who can probably provide some history on the various versions, and I've got manuals for HIH Wylbur and SuperWylbur™. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:33, 16 August 2010 (UTC)[reply]

360/65 (and /67) on Microcode[edit]

The section on microcoded S/360's doesn't mention the /65; it - and, presumably, the /67 - were, I think, microprogrammed. Any idea what the details were? (I think it had a 32-bit integer data path; what did it have for floating point? Guy Harris (talk) 22:40, 24 August 2010 (UTC)[reply]

The 2065 and 2067 were definitely horizontally microcoded. I just checked my book shelves and I don't have the CE manuals for the 2065 and 2067, although I do have them for the 2040, 3145, 3155 and 3165. I'm not sure whether the data path was 32 bits or 64 bits.
My recollection is that both general registers and floating point registers in the 2065 are in local storage. I don't recall what hardware is available to the microcode for use in floating point arithmetic.
You might ask in IBM-MAIN; there are still some old-timers left.

For IBM-MAIN subscribe / signoff / archive access instructions, send email to listserv@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:11, 25 August 2010 (UTC)[reply]

Speedy deletion of OS/VS2 (SVS)/to do[edit]

A tag has been placed on OS/VS2 (SVS)/to do, requesting that it be speedily deleted from Wikipedia. This has been done under the criteria for speedy deletion, because it is a redirect to an article talk page, file description page, file talk page, MediaWiki page, MediaWiki talk page, category talk page, portal talk page, template talk page, help talk, user page, user talk or special page from the main/article space.

If you can fix the redirect to point to a mainspace page, please do so and remove the speedy deletion tag. However, please do not remove the speedy deletion tag unless you are fixing the redirect. If you think the redirect should be retained as is for some reason, you can request that administrators wait a while before deleting it. To do this, affix the template {{hangon}} to the page and state your reasoning on the article's talk page. Feel free to leave a note on my talk page if you have any questions about this. DASHBot (talk) 00:01, 31 August 2010 (UTC)[reply]

Recovering lost OS/VS2 (SVS) todo list[edit]

{{adminhelp}} I originally wrote OS/VS2 (SVS) in userspace, and when I realized that the move to mainspace did not automatically move the todo list, I mad a manual move request, inadvertently moving it to OS/VS2 (SVS)/todo instead of Talk:OS/VS2 (SVS)/todo. When I noticed my typo I made a second manual move request.

This morning I saw that Talk:OS/VS2 (SVS)/todo had been marked at midnight for speedy deletion, with an explanation that it was a redirect page. I need help in locating or restoring the actual todo list so that I can move it to Talk:OS/VS2 (SVS)/todo. Thanks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:14, 31 August 2010 (UTC)[reply]

working on it... JohnCD (talk) 15:32, 31 August 2010 (UTC)[reply]
 Done - it's back at Talk:OS/VS2 (SVS)/to do. JohnCD (talk) 15:37, 31 August 2010 (UTC)[reply]
Hello, Chatul. You have new messages at Rjanag's talk page.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.


IBM[edit]

Thanks for letting me know about this!

What are the other "IBM platforms" available? What source explains all of the platforms available? This can help form a disambiguation page. WhisperToMe (talk) 16:25, 13 September 2010 (UTC)[reply]

That depends on how far back you want to go. In general, IBM has the following current platforms, most of which have Wiki articles; the names may have changed:

  • Architectures
    • z/Architecture

You may want to limit the disambiguation to the above. For older stuff, look at

But watch out for errors in nomenclature

There's a lot of stuff at http://bitsavers.org/pdf/ibm on the older platforms.

Note that IBM sold off its PC business, although it still sells Intel servers under the xSeries (System x) name. There may be some that I've overlooked. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:48, 13 September 2010 (UTC)[reply]

Why not archive instead of deleting[edit]

I know a User talk page belongs to the user but there was a lot of good information on yr page, particularly the CKD drive discussion so may I suggest u archive it rather than delete it. Alternatively, I will copy it to the CKD discussion page Tom94022 (talk) 05:34, 14 September 2010 (UTC)[reply]

It was a finger check. It might be a good idea to move the CKD discussion to Talk:Count Key Data now; once I finish User:Chatul/IBM System/360 architecture I will propose it for merger into IBM System/360 and start updating CKD, with references to the new material on S/360 I/O architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:07, 14 September 2010 (UTC)[reply]

Avada Kedavra[edit]

You have as much as right as any to post what you like...but please either take a correct stance or lay off me in the Harry Potter and the Philosopher's Stone debate. Your opinion about the mythological philosopher's stone is so incredibly irrelevant to the argument that I laughed out loud...and I have to thank you for that.

However, I do not thank you for accusing me of making faulty arguments just because I have the courage to tell these people they are wrong. Do you not read the talk pages? They make it clear they know they are wrong. By sound of your remarks, I'd say you have absolutely NO idea what you're on about.

Anything with more than one title, simultaneously known and in the same language, MUST list all titles equally in whatever order the source wishes to list them. Banishing alias titles far down the 1st paragraph is no intelligent move. Clearly you don't realize that. Read the way they handled it in the article about the film version.

Anyway, just a friendly request: lay off if you don't know what you are on about.76.195.86.50 (talk) 05:58, 5 October 2010 (UTC)[reply]

PKB. It is clear that you did not understand my comments.
In fact, I did read the talk pages, and two things were clear:
  • You were relying on argumentum ad hominem
  • You didn't understand what others were telling you.
This discussion belongs on the talk pages of the articles, not in user talk pages. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:50, 5 October 2010 (UTC)[reply]

OK, very well, not going further but I do take exception to your accusation that I'm going ad hominem. I've had this before, being accused of logical fallacy...do you even know what it means? Just curious....75.21.150.217 (talk) 08:18, 10 October 2010 (UTC)[reply]

Data is vs. data are[edit]

I happen to agree with your recent HDD article edit that data are is proper, but this is an ongoing dispute and unfortunately many style guides now allow data is as a "mass noun" usage. So don't be surprised if yr edit gets reverted and I recommend not getting into an edit war on this subject. Tom94022 (talk) 21:44, 18 November 2010 (UTC)[reply]

CPU cache page's somewhat x86-biased history section[edit]

The CPU cache page has 5 paragraphs in the history section talking about x86, but the only occurrence of the number "85" on the page is in the number 1048576 in the "Address translation" section. This seems wrong. :-) I suspect you're in a better position than I to fix that (in that you probably know a lot more of the 360/85 history and cache than I do). Guy Harris (talk) 10:04, 23 November 2010 (UTC)[reply]

I need to check a 360/67 manual to refresh my memory before hitting that section; there was a claim on the talk page that it had a TLB, which I don't recall. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:03, 23 November 2010 (UTC)[reply]
The 360/67 Functional Characteristics manual on bitsavers.org says, on page 11, "To avoid repeating this translation process for every memory reference by a user program, the page table entry (page starting address, bits 8-19) is recorded with, and identified by, its virtual address (segment and page address, bits 8-19) in an associative storage register. If a subsequent reference is within that virtual page, the virtual address accesses the associative register. The page starting address stored in the register is affixed to the byte address and forwarded to the BCU." "This translation process" refers to the page-table walk described in the previous paragraph. The paragraph after the quoted one gives details about the "associative storage registers"; it sounds like an 8-entry TLB. Guy Harris (talk) 21:00, 23 November 2010 (UTC)[reply]

Policy on unilateral removal of split template?[edit]

{{Adminhelp}} What is Wikipedia policy on removing a {{split}} template from an article, e.g., Burroughs large systems, with no discussion? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:02, 7 December 2010 (UTC)[reply]

Have you reviewed Wikipedia:Splitting? There is no official policy on how much discussion needs to take place before removal of tags such as these. The page is 52 kilobytes long, so it's getting into the suggested range. If you feel it should be kept together then you can easily post a note to that effect on the article's talk page and wait a week or so to see if anyone replies. Or, if anxious you could boldly remove the tag now and give your reason in the edit summary... but in the spirit of collaboration the first option may be better.  7  05:15, 8 December 2010 (UTC)[reply]
The intent of my question was the opposite; I added a {{split}} template and someone else removed it with no discussion. I don't feel that it should be kept together because there were three unrelated line of Burroughs large computers. I hadn't even considered the size issue, but it's certainly another argument in favor of splitting it. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:39, 17 December 2010 (UTC)[reply]

WP Computing and System/360 arch[edit]

I responded to your request at WP:COMP/A. I posted on the talk page some suggestions for next steps to improve the article. I also replaced the "unreviewed" banner with some cleanup messages. Please take a look at what I posted, and let me know if there are other ways I can help. Thanks for your contributions to Wikipedia's coverage of computing! --Pnm (talk) 19:07, 16 December 2010 (UTC)[reply]

It's on my watch list, and I actually saw that before I saw this note. If you have time, all of the articles listed in User:Chatul#My contribs could use another set of eyes.
My motivation for writing the architecture article was that I wanted to add technical descriptions of CKD and ECKD to Count Key Data, and the material would rely on details of the S/360 architecture thqt really didn't belong in the CKD article itself, so I wanted to add architectural details to IBM System/360. Because of the size, someone suggested that I first write the text as a separate article in user space and then merge it.
Note that I wrote from a programmers perspective; I made no effort to describe the electrical and mechanical details of the I/O channel architecture. If you know of a URL for FIPS 60 then I probably should cite it for details, since I have neither the time nor the background to write an article covering those aspects. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:39, 17 December 2010 (UTC)[reply]

Yr Disk Formatting Edit[edit]

In yr Disk Formatting Edityou introduced the concept of "Intermediate-level formatting" a concept that I am not familiar with, does not appear in the art and as you describe it does not appear to be much different than high level formatting. At best this is WP:OR but I really think it is a distinction without substance, but before I revert or tag the change I thought I would give u a chance to explain. Tom94022 (talk) 21:24, 20 December 2010 (UTC)[reply]

BTW, I'm not sure there is or has been any substantive difference between mainframe, server and/or PC - differences in detail yes, but not substantive enough for this article Tom94022 (talk) 21:27, 20 December 2010 (UTC)[reply]

Formatting volumes for use by the operating system has been around since the mid 1960's. In OS/360 it was done by the IEHDASDR utility, or stand-alone with the IBCDASDI utility. For newer devices ICKDSF replaced IEHDASDR, and is still used for the same purpose in z/OS. These utilities clearly are part of the art.
The formating donw by ICKDSF et al are totally unrelated to factory formatting. The functions include creating a volume label, creating a volume label and writing Record 0 on every track. ICKDSF does not handle low level functions such as writing timing marks, and ICKDSF cannot reinitialize a disk that has been degaussed or otherwise lost the factory formatting.
Similarly, FDISK et al do not do low level formatting, but are at a lower level than file systems.
One difference between the mainframe and PC world is that mainframe operating systems[1] do not support DASD partitioning while PC operating systems do not support a volume table of contents (VTOC).
I have no objection if you want to pick a different term than intermediate, but the actual formatting is real, well established and well documented in the literature.


Notes

  1. ^ As opposed to mainframe DASD subsystems

Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:05, 21 December 2010 (UTC)[reply]

I believe the IBM formatting utility is accurately described as a combination of what is now commonly called low-level and high-level formatting, that is it both lays down the (variable) block structure and then applies into the structure the data structures and other information necessary for access by IBMs OSes. I suspect most early minicomputer utilities operated in the same manner but Unix today is more PC like. The lack of partitioning in IBM OSes is a detail that really doesn't change anything. So I am going to rewrite your edit back to two types of formatting with the note that IBM utilities combined them. Tom94022 (talk) 17:25, 21 December 2010 (UTC)[reply]
Your belief is incorrect; as I explained, the utilities in question do neither the low level formatting nor the high level formatting. I am restoring my changes and marking the article for dispute resolution. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:33, 21 December 2010 (UTC)[reply]
This is now being discussed at Talk:Disk_formatting#Three_levels_of_formating where there is some support for my belief Tom94022 (talk) 17:13, 27 December 2010 (UTC)[reply]

File Systems[edit]

Hi: In your spare time :-) you might take a glance at List of file systems and Comparison of file systems; this appears to me to be yet another PC (and minicomputer) oriented article completely oblivious to IBM and other mainframe systems. There is some coverage at MVS#MVS_filesystem. I will defer to your expertise in this matter, but it seems the lack of IBM Access Methods, BDAM, SAM, ISAM and VSAM from these articles is a serious omission. Comment? Tom94022 (talk) 17:13, 27 December 2010 (UTC)[reply]

Verizon did some work on a neighbors local loop and managed to disconnect me in the process. Their taking their own sweet time cleaning up after themselves, so I currently have no internet access at home. I'm using the computers at the library, but they have a 30 minute time limit. I'll get back to you when I'm back on the air. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:04, 27 December 2010 (UTC)[reply]

SCRIPT[edit]

I have copies of the DWScript manuals along with voluminous amounts of examples of documents written in SCRIPT. Some of the documents were written such that they'd format properly in either DWScript or SCRIPT/VS (so that they could be printed on high speed mainframe printers).

I can license the examples in whatever's needed.

Let me know if you're interested. Joshua (talk) 14:07, 27 July 2011 (UTC)[reply]

Would you be willing to contribute them to bitsavers? I've got dead tree documentation for several versions of Script, but I'd rather use online sources where possible. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:41, 3 August 2011 (UTC)[reply]

SPF Disambiguation[edit]

I noticed that you had added the second entry pointing to ISPF. At first glance it looked to me like a duplicate entry. Only after I re-read the entry did I notice the slight name difference. It confused me, so it could probably confuse others as well. I combined the two entries, clarifying the apparent duplication as intentional. If you feel it could be better explained, please go ahead.

Thanks, WesT (talk) 21:41, 15 December 2011 (UTC)[reply]

IBM provided a succession of program products starting from the original code base. The first two were Structured Programming Facility and Structured Programming Facility Version 2. They used the name System Productivity Facility for only one version and used the name Interactive System Productivity Facility from then on. For a while some of the ISPF functionality was broken out into separate products, ISPF and ISPF/Program Development Facility, but ultimately ISPF and ISPF/PDF were merged back. I believe that it is appropriate to have separate entries for Structured Programming Facility and System Productivity Facility, but am not sure how much of the background to include on the disambiguation page. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:37, 16 December 2011 (UTC)[reply]


Steps to format a disk[edit]

Please see Steps to format a disk. Tom94022 (talk) 22:50, 18 December 2012 (UTC)[reply]

Feedback Requested: Replace Assembly Language Example[edit]

Hi Shmuel, Since you have been heavily involved in maintaining the Assembly_language page, and since I seldom edit wikipedia, I wanted to get your feedback. I am proposing to replace the Assembly Language Example with a program that I wrote. But I don't want to start an edit war etc.. So I have posted the proposed change on the Talk:Assembly_language#Don.27t_like_the_example talk page (it's at the bottom). Please let me know what you think, please put your response with the proposal, that's where I will look. Thanks. OldCodger2 (talk) 10:12, 29 January 2013 (UTC)[reply]

Also if you would review my comments about Talk:Assembly_language#I_disagree_with_your_revert_--_Data_Sections, I'd appreciate that as well. IMHO EvilCat seems rather clueless, 'pseudo-ops' has zero relevance. OldCodger2 (talk) 11:25, 29 January 2013 (UTC)[reply]

Web site with hardware/firmware information about the Model 65 (and the FAA version thereof)[edit]

I stumbled upon www.ibm360.info, which says

[2012-01-04]
This embryonic site will eventually hold a great deal of hardware detail pertaining to the IBM S/360 Models 65 and 67. At the moment it is just a repository for the odd snippet where there is an immediate need to make information available for a particular purpose.
If you link to any particular part of this website be aware that the structure will change when I revamp it and "do it properly"! (The home URL will, of course, remain.) This is not likely to be for at least a year though. You are welcome to download anything on the site for reuse with suitable attribution - e.g. "Source: www.IBM360.info".
All the documents below are scans from my own hardcopies. To keep thing quick and tight I have used the lowest resolution that is easily readable. At some point I intend to high-res scan the main IBM documents (FETOMs, FEMMs, etc) for inclusion on the bitsavers site.
Whilst there will be much of general IBM S/360 interest my main focus at the moment is on the 2065 Model 65 and its enhanced sibling the FAA IBM 9020D 7201-02 Computing Element (CE). Whilst the FAA CE is generally understood to be based on the Model 65 I believe it may actually be closer to the Model 67 (it has a DAT frame). I have the FETOM and FEMM for the Model 65 but would welcome links to any other Model 65 or 67 documentation out there (there's nothing on bitsavers). ...

It was referred to by watermarks added to this FAA manual on the microinstruction format for the Model 7201-02 Computing Element. That guy's site is a wiki he set up for his project:

On November 29th, 2011, I acquired an IBM System/360 model 65 operator's console panel. I have been working to restore this panel (see a blog of this project). I am now planning to write a software emulator that mimics the model 65's microarchitecture. For that purpose I have set up this wiki to gather as much information as I can about the microarchitecture of the '65. Without a lot of model 65 specific documentation available, most of the information comes from interpretation of the legends to the register lamps. Please join this wiki if you can contribute.

He's now building an FPGA-based hardware emulator, as per his blog for the project. He has a video of it running. (Another guy reimplemented the Model 30 microengine out of an FPGA; video here, project page here.) Guy Harris (talk) 03:01, 19 February 2013 (UTC)[reply]

Email in 1962 on the IBM 1440? Surely you're joking, Mr. Chatul.[edit]

I'm not sure what it is about email that encourages people to present overreaching claims to have invented it. There's a guy at MIT who has made a career of it!

Well, I never claimed to have invented it, or even to have used the first e-mail system. Shmuel (Seymour J.) Metz Username:Chatul (talk)

I removed the 1962 reference in Email because the cited document (IBM H20-0129-1) did not support the allegation.

It did; read the beginnning of Email, where it says "Some early email systems required that the author and the recipient both be online at the same time, in common with instant messaging.". Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

You reinstated it, citing a page number, and chastizing me for "deleting references without reading them". I had read the document, and found no reference at all to email. Rather than start an edit war, please tell me what content on page 10 of that document supports your allegation that the IBM 1440 Administrative Terminal System supported email? The closest I can see is: 

 TERMINAL COMMUNICATIONS  Any terminal may transmit its working storage to any other terminal  and as many messages as desired to the same terminal.  Since the  system does not poll, the receiving terminal must request that messages  be transmitted to it. The computer attracts the receiving terminal  operator's attention by typing the word (MSG) the first time that  terminal is used after a message has been directed to it.

This is not email. This is, at best, squirting a file to a terminal. Many older systems had a way to send a message to another logged-in user's terminal. That's different than sending an email to a user (which works whether or not they are logged in, for example, and doesn't need to know what terminal the user is logging in on). Do you have any other text from that page that you think supports your claim of ATS offering email service?

See above. Also note that the messages are queued, not simply written to the destination terminal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

If not, I believe the claim that the IBM 1440 in 1962 had an email system is false.

It's true for email as defined in the introduction to Email . Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

A separate question is whether the IBM 360 version of ATS included an email function. I did not remove that 1968 entry from Email because I did not have access to the document cited. But if you do have access, and all it offers is the same "send a document to a terminal" function, then please remove that entry from Email too.

Not that it's relevant, but ATS on DOS and OS supported queuing messages to an operator rather than to a terminal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

PS: I used an IBM 1401 extensively in 1970-71, and used many IBM 370's throughout the 1970s, both at the console and through timesharing at terminals.

By then I had stopped using the 1401 and had been doing systems programming on the S/360 for several years. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

Did you have personal experience with ATS? Gnuish (talk) 02:56, 7 May 2013 (UTC)[reply]

I used ATS under DOS/360; I installed and maintained ATS under OS/360.
PS: Doesn't this discussion belong in talk:Email? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 7 May 2013 (UTC)[reply]

SY24-3581[edit]

You cite SY24-3581-2 on IBM System/370; bitsavers.org has SY24-3581-1, but not -2. I don't see any mention of DAT in the -1 manual, but it does mention the "logical" to "real" address mapping for the DOS compatibility feature - does the -2 version mention DAT (and possibly mention that the associative memory used for "logical" to "real" address mapping was also used as a TLB for DAT)?

(It'd be nice to refer to an on-line version of SY24-3581, but if the references have to be to the -2 version in order to fully describe how DAT could be added with only a microcode change and no hardware/data path changes....) Guy Harris (talk) 00:12, 6 December 2013 (UTC)[reply]

If you read the description of the DOS compatibility feature, you'll notice that the hardware doesn't do relocation but instead matches the high bits of the address against an associative memory (p. 2-118), trapping to microcode if there is no match. It was hard to read that and not anticipate paging.
As for the edition, I relied on my dead tree bookshelf, and generally prefer to use the most recent edition that I have access to, but SY24-3581-1 does contain the relevant material, and I have no objection if you want to use that instead. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:27, 6 December 2013 (UTC)[reply]

B5000 processor A and B model numbers[edit]

According to The Operational Characteristics of the Processors for the Burroughs B 5000, processor A was a B 5280 and processor B was a B 5281. The same numbers were used for the B5500, according to the Burroughs 5500 Information Processing Systems Reference Manual. Guy Harris (talk) 19:29, 26 March 2014‎ (UTC)[reply]

Formal mediation has been requested[edit]

The Mediation Committee has received a request for formal mediation of the dispute relating to "Tensor". As an editor concerned in this dispute, you are invited to participate in the mediation. Mediation is a voluntary process which resolves a dispute over article content by facilitation, consensus-building, and compromise among the involved editors. After reviewing the request page, the formal mediation policy, and the guide to formal mediation, please indicate in the "party agreement" section whether you agree to participate. Because requests must be responded to by the Mediation Committee within seven days, please respond to the request by 14 April 2014.

Discussion relating to the mediation request is welcome at the case talk page. Thank you.
Message delivered by MediationBot (talk) on behalf of the Mediation Committee. 15:36, 7 April 2014 (UTC)[reply]

Request for mediation rejected[edit]

The request for formal mediation concerning Tensor, to which you were listed as a party, has been declined. To read an explanation by the Mediation Committee for the rejection of this request, see the mediation request page, which will be deleted by an administrator after a reasonable time. Please direct questions relating to this request to the Chairman of the Committee, or to the mailing list. For more information on forms of dispute resolution, other than formal mediation, that are available, see Wikipedia:Dispute resolution.

For the Mediation Committee, Sunray (talk) 05:47, 12 April 2014 (UTC)[reply]
(Delivered by MediationBot, on behalf of the Mediation Committee.)

Any non-IBM compatible system use CKD?[edit]

Hi Chatul - hope u are well.

Off the top of yr head do u know if any computer system manufacturer other than IBM (and its clones) that implemented a CKD file system? To the best of my knowledge none did, but my knowledge is limited. Tom94022 (talk) 00:45, 27 May 2014 (UTC)[reply]

The only systems that I know to use CKD were clones or near clones, e.g., RCA Spectra 70. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:27, 27 May 2014 (UTC)[reply]
That is my understanding also, Thanks Tom94022 (talk) 05:36, 28 May 2014 (UTC)[reply]

IBM 3310[edit]

U added a section on the IBM 3310 but it was already discussed in the IBM 680 section as are all other IBM small disk drives that wound up on IBM computer systems. I don't think it would be a good idea to add back all the other stuff. It maybe that this is the only OEM product that was re-badged as a mainframe drive (33xx series) in which case it would be OK to leave it, shortened and with a link to the 680. We could also retitle Section 4 to "OEM HDDs (many offered on IBM computing systems)" or some such. I'm watching this page for yr response. Your thoughts? Tom94022 (talk) 16:42, 31 July 2014 (UTC)[reply]

Maybe Section 4 is just "OEM and System's HDDs" with appropriate correction to the section lede. Tom94022 (talk) 16:43, 31 July 2014 (UTC)[reply]

It might be appropriate to add cross-links, but the 3310 definitely belongs in IBM System/360 and other IBM mainframe HDDs; in particular, the fact that it was FBA rather than CKD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:42, 1 August 2014 (UTC)[reply]

My Library (computing) edit edited only an HTML comment[edit]

My edit only affected an HTML comment, so the page should look the same to the viewer in the version before the edit and the version after the edit. If you try to edit the page, however, you should see an undamaged version of the "This statement is overly broad..." comment preceding the article's text. Guy Harris (talk) 20:12, 11 August 2014 (UTC)[reply]

What was the RAMAC price and capacity?[edit]

You are invited to join the discussion at Talk:Hard_disk_drive#An_End_To_The_RAMAC_Price_Duologue. Please help end the duologue on capacity and price of the IBM RAMAC Model 350 disk file. Thanks. Tom94022 (talk) 21:52, 4 September 2014 (UTC)[reply]

360/50 maximum memory size[edit]

Sorry, I was using http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2050.html for the memory size (see "Memory cycle time"); the IBM functional characteristics manual are presumably better sources. Guy Harris (talk) 19:10, 8 October 2014 (UTC)[reply]

EXEC II produced by UNIVAC or CSC?[edit]

The UNIVAC EXEC II page says:

EXEC II was an operating system developed for the UNIVAC 1107 by Computer Sciences Corporation (CSC) while under contract to UNIVAC to develop the machine's COBOL compiler. They developed EXEC II because Univac's EXEC I operating system development was late. Because of this the COBOL compiler was actually designed to run under EXEC II, not EXEC I as specified in the original contract.

so should the History of operating systems page say UNIVAC, or CSC, produced EXEC II? Guy Harris (talk) 21:09, 24 November 2014 (UTC)[reply]

If it's not TMI, say that CSC produced it under contract to UNIVAC. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:33, 24 November 2014 (UTC)[reply]
The George Gray reference says "EXEC I wasn't ready yet, so CSC went ahead and devised its own operating system for the 1107, which became EXEC II. CSC stretched the terms of their contract a good bit: when the COBOL compiler was finished, it was for an EXEC II environment, not EXEC I!", so while CSC was under contract to UNIVAC, they were under contract to produce a COBOL compiler, not an operating system, so the operating system itself was only loosely produced under contract - I guess CSC could have argued "hey, we needed an operating system for the compiler, and yours wasn't ready yet, so we had to roll our own" and thus say EXEC II was produced as part of the contract.
I'd be inclined to say CSC produced it and delivered it to UNIVAC. Guy Harris (talk) 22:05, 24 November 2014 (UTC)[reply]
That works: whatever level of detail you believe to be appropriate. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 24 November 2014 (UTC)[reply]

Formal mediation has been requested[edit]

The Mediation Committee has received a request for formal mediation of the dispute relating to "Vectors are not tensors". As an editor concerned in this dispute, you are invited to participate in the mediation. Mediation is a voluntary process which resolves a dispute over article content by facilitation, consensus-building, and compromise among the involved editors. After reviewing the request page, the formal mediation policy, and the guide to formal mediation, please indicate in the "party agreement" section whether you agree to participate. Because requests must be responded to by the Mediation Committee within seven days, please respond to the request by 6 April 2015.

Discussion relating to the mediation request is welcome at the case talk page. Thank you.
Message delivered by MediationBot (talk) on behalf of the Mediation Committee. 21:06, 30 March 2015 (UTC)[reply]

Request for mediation rejected[edit]

The request for formal mediation concerning Vectors are not tensors, to which you were listed as a party, has been declined. To read an explanation by the Mediation Committee for the rejection of this request, see the mediation request page, which will be deleted by an administrator after a reasonable time. Please direct questions relating to this request to the Chairman of the Committee, or to the mailing list. For more information on forms of dispute resolution, other than formal mediation, that are available, see Wikipedia:Dispute resolution.

For the Mediation Committee, TransporterMan (TALK) 17:00, 7 April 2015 (UTC)[reply]
(Delivered by MediationBot, on behalf of the Mediation Committee.)

CKD I/O Graphic[edit]

I think the CKD article needs some graphics to make it understandable so I already posted the track format which shouldn't be an issue. Please take a look at this "architecture" graphic and comment on it before I post it into the article

IBM S/360 & S/370 Input/Output operations for CKD DASD showing channel, storage control unit and DASD device

You can comment at the graphic or here. Thanks Tom94022 (talk) 16:55, 20 August 2015 (UTC)[reply]

It's hard to read the text; otherwise it looks reasonable. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:33, 20 August 2015 (UTC)[reply]
I can make the heading and box headings bigger, what would u suggest? Did u like the IBM Blue :-)Tom94022 (talk) 00:19, 21 August 2015 (UTC)[reply]
Lt's the internal text that I was referring to. I'd suggest enlarging all of the text and expanding the box as necessary to avoid overruns. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:09, 21 August 2015 (UTC)[reply]

Disconnected Command Chaining/Command Retry[edit]

To the best of my recollection these two features were introduced with the Block Multiplexer Channel and for DASD with the 2835:

  • Disconnected Command Chaining - specifically for Seek CCW
  • Command Retry - in channel retry, especially for certain data errors

I've looked for RS's without much success. Any recollections and RSs? Tom94022 (talk) 18:48, 4 December 2015 (UTC)[reply]

The logical disconnect is discussed in various manuals under the heading of multiple requesting.
Command Retry is signaled by the combination of a unit check and status modifier.
The first place I'd look is System/360 and System/370 I/O Interface Channel to Control Unit OEMI, Eleventh Edition, IBM, September 1992, GA22-6974-10. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:21, 4 December 2015 (UTC)[reply]
There is a nice section in 3830/3300 RM GA26-1592-2 p.1 which covers in sequence RPS, Multiple Requesting and Command Retry. Is it also your recollection that these were simultaneous introduced with the BMux Channel and the 2835? If so, it maybe that the RPS section of the CKD article needs to expand to cover all three. BTW, I've always preferred the term Disconnected Command Chaining to Multiple Requesting but I guess I'll have to use the IBM term. Tom94022 (talk) 17:34, 7 December 2015 (UTC)[reply]
Yes, the 2305/2835 reference manual has discussions of all three, and if you're looking for the earliest publication that covers them, that's it. I cited GA22-6974-10 primarily because it's available in a form that lets me give a link to a specific section, as opposed to the PDF files on bitsavers, where I can only point to the entire document. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:52, 7 December 2015 (UTC)[reply]

Caching/Paging 3880 Manuals[edit]

There are 3880-11 and -13 manuals at Chicago Classic Computing. I plan to referencing them when I update the Caching section of the CKD article. Tom94022 (talk) 18:19, 18 December 2015 (UTC)[reply]

If you look at the source for User:Chatul/Sandbox/Count key data/notes you will see numerous citations, including reference manuals for the 3880-11 and 3880-21. Unfortunately, I have still been unable to locate copies of the manuals for the 3880-21, 3880-23 and ISC; I may wind up using the 370/168 Functional Specifications for the latter.
A number of the online manuals that I found are linked to from Shelf: Hardware collection, June 2000 or bitsavers.
A number of the announcement dates are available from Storage product profiles, although there are some strange gaps. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:05, 18 December 2015 (UTC)[reply]
I believe the site referenced above has -13 manuals and as near as I can tell u have not yet cited any. For the purposes of Wikipedia there should not be much if any substantive difference between the -13 and -23. Tom94022 (talk) 01:54, 19 December 2015 (UTC)[reply]
Storage product profiles, Storage product profiles doesn't have any manuals. I plan to use it as a RS for the announcement and ship dates that it contains.
Please take a look at the table [13] following the outline in User:Chatul/Sandbox/Count key data/notes and at User:Chatul/Sandbox/Count key data/notes#Proposed table; I expect to include some verion of them in User:Chatul/Sandbox/Count key data Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:37, 22 December 2015 (UTC)[reply]

Formal mediation has been requested[edit]

The Mediation Committee has received a request for formal mediation of the dispute relating to "Count key data". As an editor concerned in this dispute, you are invited to participate in the mediation. Mediation is a voluntary process which resolves a dispute over article content by facilitation, consensus-building, and compromise among the involved editors. After reviewing the request page, the formal mediation policy, and the guide to formal mediation, please indicate in the "party agreement" section whether you agree to participate. Because requests must be responded to by the Mediation Committee within seven days, please respond to the request by 15 January 2016.

Discussion relating to the mediation request is welcome at the case talk page. Thank you.
Message delivered by MediationBot (talk) on behalf of the Mediation Committee. 20:56, 8 January 2016 (UTC)[reply]

I would happily agree to mediation but not with the issues as u state them, see: please see "Malformed statement of primary issues" in Talk section Tom94022 (talk) 01:10, 10 January 2016 (UTC)[reply]

Request for mediation rejected[edit]

The request for formal mediation concerning Count key data, to which you were listed as a party, has been declined. To read an explanation by the Mediation Committee for the rejection of this request, see the mediation request page, which will be deleted by an administrator after a reasonable time. Please direct questions relating to this request to the Chairman of the Committee, or to the mailing list. For more information on forms of dispute resolution, other than formal mediation, that are available, see Wikipedia:Dispute resolution.

For the Mediation Committee, TransporterMan (TALK) 19:24, 12 January 2016 (UTC)[reply]
(Delivered by MediationBot, on behalf of the Mediation Committee.)

Request for arbitration[edit]

Hi Chatul. I'm an arbitration clerk, which means I was appointed to assist the Arbitration Committee in the administration of arbitration proceedings. Regarding your recently-filed request for an arbitration case, the Committee has requested that the clerks informally ask you to withdraw your request for arbitation, as the case is fundementally a content dispute (which the Committee cannot handle) and would certainly be declined, in order to save everyone the hassle of formally voting to decline the case. Please let me know if you have any questions. Thanks. In my capacity as a Clerk of the Arbitration Committee, Kevin (aka L235 · t · c) 17:37, 16 January 2016 (UTC)[reply]

Just to let you know, I have removed the case as a ArbCom clerk, as it has been declined by the committee. Thanks, Mdann52 (talk) 16:28, 19 January 2016 (UTC)[reply]

{{cite manual}} vs. {{cite book}}[edit]

As of December 2012, {{cite manual}} is an alias for {{cite book}}, so either one works. (Here's a discussion of that.) If you reverted Yobot's change of {{cite manual}} to {{cite book}} in this edit because you wanted the page's editable text to reflect that the book being cited was a manual, you should probably suggest to Yobot's master that it not make that particular change. Guy Harris (talk) 00:47, 9 March 2016 (UTC)[reply]

Thanks. Done. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:03, 10 March 2016 (UTC)[reply]

Should the current artist's impression be removed from the Planet Nine infobox?[edit]

Hello, Chatul. You have new messages at Talk:Planet Nine#Conclusion 2.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Regards, nagualdesign 15:02, 11 March 2016 (UTC)[reply]

Is the 3830-2 a Director?[edit]

IBM apparently thought so long before the 3880 shipped

"The NAS [New Attachment Strategy] essentially split the function of the controller into various boxes such as a director, or integrated storage controller, and a blivet"
"The "Smash" announcement in August 1972 included two directors, the 3345 and the 3830-II."
"And one IBM planner wrote that "one of the motives for the A box attachment strategy was to restrict our PCM vulnerability by embedding the initial drives in the A box.""
"A July 6, 1971 memo from Lewis Branscomb to Evans indicated the corporate technology committee "is not convinced that the director plan for machines noted above or the proposed NAM which integrates channels and control units is sound. The directors do not provide any technical or functional advance, cause some serviceability problems and reduce the flexibility for file switching."
"On July 29, 1971, Evans indicated to Cooley that, concerning the director approach on tapes, "there is no new engineering with regard to logic on directors. Existing control units are merely split apart and repackaged with part of the logic in the drives and the remaining part in the appropriate CPU"
""It is our intent to price the inboard directors to cut off production of 3830s, but not to displace those already installed in small 155 and 165 systems," the [1972] memo said."

From: Via 'New Attachment Strategy' IBM Meant to Frustrate PCMs February 20, 1978

The quotes are mainly from IBM internal documents mostly in 1971 and 1972 and were made public both in the US Government case and in the Memorex case. Also note the use of A Box within to apply to the 3330 and beyond IBM long before the 3380 even started FWIW, a blivet is a string controller.

Jack Harker pretty much says the same thing in his oral history - he was the SJ Lab Director at the time of the NAS

I hope this puts to bed the endless discussion about both the director and the A-unit Tom94022 (talk) 08:52, 10 April 2016 (UTC)[reply]

The source you cite includes "Gardner says that memo supports his conclusion that the cost and price of directors are disproportunate to the cost and price of the 3830-II." In general, the article seems to be talking about directors as components of integrated adapters. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:37, 11 April 2016 (UTC)[reply]
What is it about
"The "Smash" announcement in August 1972 included two directors, the 3345 and the 3830-II."
that doesn't say the 3830 is a director? Furthermore, I can find nothing in the article about directors as components of integrated adapters; directors are not "components" of anything, director type storage controls have one or two direstors. The Gardner quote is about the ISC of thde 148 {and of the 158 and 168) for which there are RS's that the ISC and the 3830-2 are the same thing in two different packages. Of course if you accept the ISCs as directors we can stop here.
If you didn't stop above please read the Oral History of Jack Harker at the Computer History Musuem on "attachment strategy"
If you didn't stop above, please read, "Extracts relating to New Attachment Strategy" from the US v IBM antitrust matter.
There are now multiple reliable secondary sources that 3830-2==ISC==Director; please stop denying it. Tom94022 (talk) 16:36, 11 April 2016 (UTC)[reply]
FWIW, it appears that all you have to support an POV that the 3830-2 is not a director are several non-statements in primary sources. The fact that such primary sources say nothing about directors, is not a reliable source for asserting the 3830-2 is not a director. Now that we have at least three reliable sources calling the 3830-2 a director, I again request you stop asserting the POV that the 3830-2 and -3 are not director type storage controls. Tom94022 (talk) 15:18, 12 April 2016 (UTC)[reply]
Did you read the text I quoted? The article that you cited contradicts itself. As to the antitrust suit, Memorex alleged that the issue in contention began with the 2319. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:08, 14 April 2016 (UTC)[reply]
It is quite clear that Gardner is talking ISCs versus the 3830-2. It is an invention on your part that Gardner is talking about integrated attachments. I can find no contradictions in the article, but even if there were there are now at least two other RS's that say or can be interpreted to say that the 3830-2==ISC==Director. You have no evidence to contradict this, just the lack of the word director in some publications.
There were many issues in contention in both the Memorex and the US anti trust matters including 2319A, 2319B, FTP, ETP, 3705, New Attachment Strategy and others. No one ever contended or referred to anything other than the 3830-2 and the ISCs as directors. Again you have no evidence to support your POV that, "the issue in contention began with the 2319." Tom94022 (talk) 00:47, 15 April 2016 (UTC)[reply]

Speed of light issues in CKD DASD Cabling[edit]

You are just wrong about the speed of light not being among the limiting factors in cable lenghts in CKD subsystems. The speed of light part of the latency budget in the gap is twice the distance from the furthest head to the control unit and can as I recall is 275 feet max or well in excess of 0.5 usec. Maybe u didn't know that data cables between the SCU and B-unit could be as long as 75 feet? So if the latencies of the SCU and channel are held constant extending the cables will increase the latency until the subsystem overruns. Anyone who worked on SCUs and B-units knows this but finding RS's is a challenge since they are likely buried deep inside IBM and the PCMs archives. On the other hand, I doubt if you have any source for your assertion that, "cabling limit is not SOL." just your POV.

Perhaps the parenthentical comment should have been {latency issues, including speed of light). In any event it is a small point and I am tired of your insistence on your POV over facts, so I am not going to restate the parenthentical comment. Tom94022 (talk) 01:09, 15 April 2016 (UTC)[reply]

Perhaps you are unaware that the parallel channel use electrical signals over copper rather than light signals over optical fiber. There's also an ambiguity as to what cable length refers to, but all are affected by electrical issues, e.g., inductance, resistance, except for ESCON and FICON cables.
As to On the other hand, I doubt if you have any source , you are wrong yet again. My source is the channel to control unit OEMI, especially 2.8.3 System Configuration. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:45, 15 April 2016 (UTC)[reply]
Some how I missed yr snide comments, but let me guess that perhaps you are unaware that the speed of light applies in both electrical cables and optical cables? I know there are internal documents at IBM and Memorex that discussed this, the problem is finding and liberating them. Tom94022 (talk) 22:32, 14 September 2017 (UTC)[reply]