The midseventies SHARE survey 76

and might run on the 85, 75, some possibility in 65 (i.e. the 65 tended to have one or two channels that you could attach 2301 drum ... which read-wrote 4heads in parallel and transfer rate about 1.5mbytes-sec). it wouldn't support 3330 block multplexor operation with set sector commands on machines that didn't have block multiplexor channels (i have some vague recollection there is some possibility that 85 was late enuf in the engineering cycle that it might have gotten block multiplexor channel).

the 3330 had 20 surfaces and 20 heads ... however, only 19 platters-heads were addressable. the 20th surface had sector information.

normal 360 CKD dasd operation was

seek search-id (equal, say cchhr) tic *-8 read-write

the cchr argument for the search operation was in main memory. in CKD dasd architecture you could tag a record with some id value (standard programming tended to use CCHHR type tags). Rather than having indexes of stuff in memory, it was possible to just know the ID of the record ... and start an operation that searched for that record ID.

this architecture traded off real-storage (which was typically in 360 generation terribly constrained ... or at least believed to be terribly constrained) with I-O bandwidth; the search operation would maintain device, controller, and channel dedicated use while it recognized the start of each record, (re)fetched the ID from main memory and compared it to the ID of the record currently rotating under the head. This was horribly expensive in terms of device, controller and channel utilization. However, in the 360 era, it was deemed to be an acceptable trade-off if it saved on needing real storage.

for 3330, the architecture was enhanced if you had a relatively regular data format; you could know ahead of time the sector location (rotational position) of the start of the record you wanted. the ccw sequence then looked something like

seek set-sector search-id tic *-8 read-write

the sec-sector operation freed up the control unit and channel (and possibly string-switch, if one was involved) ... until the sector location rotated under the 20th head. This could cut the channel and controller busy in half or better ... potentially doubling the i-o thruput (in i-o intensive environment).

so the other side is looking at the business ROI ... it turns out that they were shipping standard 3330s as fast as they could make them. Any possible incremental 3330 business that came from retrofitting 3330s to 360s would have to be really significant ... to pull the (scarce) engineers off work on 3330 enhancements, 3350s, 3370s, 3375s, 3380, etc work. The big paying customers were getting a lot larger bang for the buck off the other work the engineers were doing than any possible retrofit that they might do for a relatively few number ofs 360s.

Now on the otherside ... they didn't completely fix CKD dasd (say by converting everything over to fixed-block architecture, FBA).

CP67-VM370-CMS effectively always had an FBA architecture that they were forced to emulate on CKD dasd. There was significant features of OS-360 genre of operating systems that were dependent on CKD dasd search feature. Both PDS directories and the master volume VTOC (directory) relied on multi-track search. Rather than maintain indexes (that would require being cached in memory ... tying up real storage), they used multi-track searching to find a unique directory entry out on disk; these records had ids that represented what they indexed, rather than their relative position on disk. Rather than read-cache multi-level of pointers ... they just told the disk to go find the specific directory entry they were interested in.

this design had even more serious impact on channel, controller, device (and potentially string-switch) busy-utilization.

In the late 70s, i shot a customer performance problem at a large retail batch shop (not vm370-cms) ... where they had multiple machines sharing the same large disk farm. It turns out all the machines shared the same application program library ... and during busy period of the day ... all the machines were constantly loading various applications out of the library. Every application load always first reading the directory entry. Reading the directory entry first required searching for it. Each search operation was taking 1-3rd to 1-2 second elapsed time, during which the device, string-switch, controller and channel was busy. The actual application program load was on the order of 30-50mils elapsed time. In addition to the server resource busy time ... the aggregate cluster of machines was limited to approx. two application program loads per second. There were hundreds of applications in this particular library ... that had aggregate use demand on the order of scores, per second not two per second.

--