Hi Glenn, Comments on your changes - and could you let me know when you see the replacement run? I want to get the unlogged SS$_MEDOFL changes in ASAP so I can cross it off my list. 1) When you send code out for review, could you send a pointer to the original file (not on your workstation)? Sometimes DIFF just doesn't provide enough context to really understand a section of code 2) Why is the RC bit is in the SCSI2_DTE_ERR_PAGE_DESC? The assumption is that if the DO_MODE_PAGE fails it's because the DTE bit is in the wrong stage, but it could be the RC bit that forces a failure in this case 3) In the SETUP_CMD loop and in the CSPI$BUFFER_MAP loop the assumption is that a bad status from SPI$CMD_BUFFER_ALLOC indicates a condition which may go away with retries, which may not be true if a bad parameter was detected; as is we'll have to run through some number of retries before returning a failure status, and even then we don't return the real reason for the failure in the case of SPI$CMD_BUFFER_ALLOC, converting it to SS$_UNSAFE instead. I think that command buffer allocation and buffer mapping failures need to be addressed more consistently across all of the class drivers - there's at least one outstanding CLD which I believe to be caused by a similiar failure in GKDRIVER The assumption seems to be that when one of these calls completes, the operation is done or has failed - so unless the caller passes in parameters it can't deal with, in which case they should return SS$_BADPARAM or something more specific, the routines should stall themselves until they can complete. But unless we want to plant BUG_CHECKS in the routines themselves, the class drivers still have to check status on every SPI$CMD_BUFFER_ALLOC and SPI$BUFFER_MAP call - even if all they do is BUG_CHECK - to protect themselves from having passed bad parameters to the routine. We could add some level of protection by modifying the SPI$ macros themselves, adding FAILURE=