iraf.net

Hi Alan, Reviewing the mail you exchanged with Mike I don't see what the problem
is, but I can offer a few comments.The DAT drives we have locally are not "apunix drives" but generic WangDAT
drives like yours. When I first started testing with DAT here I also used
the Sun ST driver. This worked, sort of, but had problems, so we ended up
looking around for a third party driver - this is how we got started with
the ApUNIX drivers.An obvious solution to your problem (and probably other problems you haven't
run into yet) would be to get the ApUNIX driver, or some other third party
driver (I have only tested the ApUNIX driver). You can get this as a
separate product and use it with your WangDAT; probably they have a driver
for the Python as well.For example, one problem I am aware of with the Sun ST driver and DAT is
that the ST driver will not to multiple file space operations. In a FSF,
it will skip forward one file at a time. This is incredibly slow on a DAT
(also on Exabyte). A FSF operation might take tens of minutes with the
ST driver, but 10 seconds with a driver like ApUNIX which uses a multifile
SCSI space operation. The ST driver also tends to be rather buggy.I am surprised that you find you need to do fixed block (N*512) i/o. The
DAT drives all support variable block i/o in firmware in the drive itself.
If this is not available at the unix level it is due to the host driver,
i.e., the Sun ST driver, or to the way you have it configured. IRAF works
fine with fixed block devices but I don't recommend that you use fixed
blocks with DAT. There is no advantage to be gained, and for data
interchange reasons you are probably better off with variable size blocks.
It may be possible to modify the ST kernel config for the device to use
variable size records instead of fixed size blocks.I am not aware of any problems with fixed-block magtape i/o and networking.
You might try limiting the transfer size with mr#64512r#64512. I doubt
if this will make any difference since you are already using fb# to
limit the transfer size, but having too large a transfer could cause a
write i/o error. If you get a write i/o error you should examine the
system messages file (/usr/adm/messages) to see if the host driver has
output a message.This is just a nit, but if you do decide to stick with fixed blocks, it
is not necessary to set fb# to a value less than or equal to 10. For a
fixed block device the FITS blocking parameter is arbitrary and determines
only the i/o buffer size (data is always output in units of device blocks
regardless of how much data is written in each transfer). We usually use
fb#22, although since the drive buffers data internally the blocking value
makes little difference. - Doug