CAC 2015-10-14

IOM redesign thoughts

data flow

There are two viable data flow models, "DDCW push" and "DDCW pull."

DDCW push

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

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 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.

pull:

if IDCW == SEEK then
  pull DDCW
  seekAddress = directDataService (DDCW)

push:

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.