Tape i/o and scsi pass through
From: Tom Stewart (tastewar_at_newsgroups.nospam)
Date: 07/15/04
- Next message: Ant: "driver instance question"
- Previous message: Alessandro Costa: "Re: Send String of char to another application"
- Next in thread: Rhett Gong [MSFT]: "RE: Tape i/o and scsi pass through"
- Reply: Rhett Gong [MSFT]: "RE: Tape i/o and scsi pass through"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 15 Jul 2004 09:14:57 -0400
I previously posted about a problem getting EOT warnings on DLT. I'm trying to reproduce
that in a stand alone program, and am having trouble doing so (good news and bad, I guess).
Our *real* application, where this is experienced, is a port of a proprietary operating
system. This OS code assembles its own SCSI cdb's which it passes via a function call to a
function whose purpose is to execute this command in the windows environment. This function
therefore must parse the command block and translate the command and parameters into the
appropriate Windows API calls. Well, on a mode select command to a tape, this OS will
sometimes assert things like tape density, for which there is apparently no Windows API. To
deal with this, when this function is implementing a tape mode select command on behalf of
the OS, it calls SetTapeParameters with the TAPE_SET_MEDIA_PARAMETERS flag to deal with the
block size. Subsequently, it also executes a scsi pass through (via DeviceIoControl ( ...
IOCTL_SCSI_PASS_THROUGH_DIRECT ...) ), passing the original cdb to the device, to be sure
any other settings requested are enabled. My recollection (from years ago when this code was
first written) is that the SetTapeParameters call was essentially required, as the driver
needed to know the block size. Makes sense to me, since it has to re-assemble a CDB with a
block or byte count representing the buffer of the WriteFile call, depending on the setting.
Does anyone know of any issues with scsi pass through and tape, specifically passing a mode
select through? Seems odd that doing so would cause us to miss EOT warnings, but I'm at a
loss to explain otherwise. Also, each trial on this DLT takes about 2 hours to get to the
end of the tape to test the EOT handling code, so it's a BFPITA to test lots of combinations
of things.
-- Tom
- Next message: Ant: "driver instance question"
- Previous message: Alessandro Costa: "Re: Send String of char to another application"
- Next in thread: Rhett Gong [MSFT]: "RE: Tape i/o and scsi pass through"
- Reply: Rhett Gong [MSFT]: "RE: Tape i/o and scsi pass through"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|