iraf.net

Jim, the standard FITS blocksize is 2880 bytes, which evolved in the days
of 9track tapes. The Exabyte is horrendously inefficient at 2880 bytes, so
some people have been advised to write non-standard exabytes with the WFITS
blocking_factor=10, which is 10*2880 or 28800 byte blocks. It is true this
is non-standard, and I thought people were supposed to be warned only to use
this factor if they used IRAF's RFITS to read the tape. Someone from VLBA
would probably be using AIPS to read the exabyte, and it would be expecting
2880 byte blocks. See "cl> help wfits", the "blocking_factor" paragraph,
which cautions that it is a "very dangerous option". The DEFAULT is 1, or
2880 byte blocks, so the VLBA observer must have overridden the default and
should have been aware of the hazard.Perhaps Jeannette needs to get together with you to review the status and
usage of the mountain exabytes. Maybe we need an up to date list of known
bugs with tape drivers, etc., so people know whether to use WFITS or that DD
script, and under what conditions they can or can not append data to the end
of existing tapes without rewinding. Maybe in the form of a troff poster
that could be taped over the drive in each dome.Do you know what time you'll be on the mountain Wednesday morning? I would
like to have some mail before I attempt to write to that tape, just to make
sure the scratch tape is loaded.Thanks, Steve