DRMS SUM_get() Call Interface		03Jun2011
		-----------------------------


When drms calls SUM_get() it should have the TOUCH mode bit set
in the SUM_t handle and tdays set to -3. This will guarantee that
sums sets a minimum retention time of 3 days. 

If drms wants to retrieve the data from tape if it is not online,
then it sets the RETRIEVE mode bit. When a ds is brought on line
from tape it automatically has a retention time of 3 days.

Here are the SUM_get() return codes:
0 = success
1 = error in communication with the DB or tape_svc. Give err ret to caller.
2 = tape_svc taken offline by manual intervention by the operator. Delay
    30mins and then retry the SUM_get()
4 = sum_svc is dead. Drms should sleep and loop, waiting for the sum_svc
    to automatically restart. The SUM_get() is then reissued. The current
    implementation of this seems to be working fine.
5 = tape_svc is dead. Delay 30mins and retry the SUM_get()
32= RESULT_PEND

A return code of RESULT_PEND (32) means that the dataset(s) are
offline and will be retrieved from tape. DRMS does a SUM_wait()
or a SUM_poll(), as desired. 
When the SUM_wait() completes, drms inspects the SUM_t handle
status word and if sum->status !=0 then an error occured in 
the tape read operation. An I/O error return s/b given to the
original module caller.


P.S.

I have notice that on a show_info -p to read a tape I get this:

> show_info key=dirname -o sunum=22081316 -p
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 1 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 2 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 4 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 8 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 16 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 32 seconds.
SUM_poll() returned 3.
SUM_nop() returned 0.
Tape fetch has not completed, waiting for 64 seconds.
SUM_poll() returned 0.
online  dirname SUDIR
N       /SUM8/D14449554/S00000/fd_V_01h.103978  /SUM0/D175435421/D22081316/S00000

Now the tape read completed at the start of the last 64 second wait.
So the command completion was delayed by the timeout. This is probably
not so bad here, but does the timeout keep on doubling and eventually
we're waiting some prohibited time after the tape has in fact been read.