IOM redesign thoughts
There are two viable data flow models, "DDCW push" and "DDCW pull."
doConnectChannel: walk the PCW list extract the DCW and channel number, push to doPayloadChannel doPayloadChannel: push the DCW to the device walk the DCW list push both IDCWs and DDCWs to the device device: if DCW is IDCW do instruction else is DDCW transfer data
doConnectChannel: walk the PCW list extract the DCW and channel number, push to doPayloadChannel doPayloadChannel: push the DCW to the device walk the DCW list push IDCWs to the device device: do instruction if instruction expects DDCWs loop pull DDCW transfer data until DDCW is IOTD.
The 'pull' model is more straight-forward coding in the sense that the context of the DDCW is known; in the
push model, the IDCW handler must store state information for the DDCW. e.g.
if IDCW == SEEK then pull DDCW seekAddress = directDataService (DDCW)
if DCW == IDCW If IDCW == SEEK then mode = seekMode; .... else if DCW == DDCW if mode == seekMode seekAddress = directDataService (DDCW) ...
However, error handling is more complicated due to greater stack depth.
addressing mode state transitions
Looking at the state transitions (pp B23-B25), it strikes me that they are overloaded; they
cover both LPW and DCW addressing modes, and the code might be much simpler if
the two states were disentangled.
Use the table on page B24 instead of the state machine on page B23.