360 DIAGNOSE 1309

"real" diagnose tends to invoke machine specific microcode whose operations aren't defined in the POP (aka the POP says something about diagnose functions are defined as being model specific).

I had done a modification for CMS disk i-o while an undergraduate that used a special CCW that encapsulated the whole seek-search-read-write process in a single operation (minimizing a bunch of pathlength in CCWTRANS) and was defined to be CC=1, CSW-STORED semantics (i.e. lots of asyncronous pathlength and processing was bypbutted in both CMS and CP). part of the reason in worked was that (both CP and) CMS formated CKD disks into standardize format and effectively simulated fixed-block architecture on CKD disks (so all disk CCW operations were very uniform and regular). It cut about 90 percent of the pathlength and overhead out of CMS disk i-o operations.

People at cambridge (primarily bob adair) were very emphatic about not violating POP ... so the cms performance "enhancement" was remapped to a (simulated) diagnose instruction ... under the architecture umbrella that DIAGNOSE is defined as being model dependent ... and an artifical "model" abstraction could be defined for a "virtual machine" machine model. The semantics stayed pretty much the same ... unform channel program that bypbutted loads of generalized CCWTRANS process and that it appeared as a syncronous operation (eliminating the asyncronous processing overhead).

over the years, lots of liberties were taken to enhance and optimize the cms virtual machine environment using the "virtual machine" machine model diagnose interface.

this is not to say that there weren't things like service diagnostics that were machine model specific that would invoke unique real hardware operations that were embedded in the microcode of a specific machine model (and not defined-specified in the principle of operations).

misc. past postings about CKD disk-dasd

--