iraf.net

Dear IRAF gurus:I'm having trouble deallocating my exabyte tapedrives. IRAF
complains, then crashes. The 'allocate' command works fine,
but then 'deallocate' doesn't work. Also, reading files off the
tape with 'rfits' is a problem. The following is typical of the
problems I'm experiencing. The device name (for using the
tar and mt commands in unix) is /dev/rmt/1n. The device
name in IRAF is mtb0.--------------------------------------------------------------------------- NOAO SUN/IRAF Revision 2.10.4-p1 Wed Aug 30 22:08:07 MST 1995
This is the EXPORT version of Sun/IRAF V2.10.4 for Solaris 2.4. Welcome to IRAF. To list the available commands, type ? or ??. To get
detailed information about a command, type `help command'. To run a
command or load a package, type its name. Type `bye' to exit a
package, or `logout' to get out of the CL. Type `news' to find out
what is new in the version of the system you are using. The following
commands or packages are currently defined: apropos euv. lists. proto. tables.
ctio. fcrao. noao. softools. utilities.
dataio. images. obsolete. stsdas. vol.
dbms. language. plot. system. xray.
cl> !mt -f /dev/rmt/1n status
Exabyte EXB-8500 8mm tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0
cl> !mt -f /dev/rmt/1n rewind
cl> allocate mtb0
device mtb0 is already allocated
cl> devstatus mtb0
# Magtape unit mtb0 status Tue 22:58:18 04-Jun-96 user yan
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0
cl> rewind mtb0
ERROR: Cannot open device (0bn)
cl> rfits mtb0 1 junk make-
ERROR: Cannot open device (0bn)
cl> rewind
device to be rewound (mtb1): mtb0
ERROR: Cannot open device (0bn)
cl> devstatus mtb0
# Magtape unit mtb0 status Tue 23:01:36 04-Jun-96 user yan
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0
cl> deallocate mtb0
ERROR: segmentation violation
deallocate (device=mtb0)
cl> deallocate mtb0
Segmentation fault (core dumped)---------------------------------------------------------------------------...and we're back to the shell.
Of course, IRAF says that the device is already allocated to me because
I allocated it to begin with and haven't been able to deallocate it.
The problem is not tapedrive-specific, it happens on all of the ones we
have here.If it helps in the diagnosis: physically turning off the tapedrive
doesn't remove the problem. In fact, IRAF doesn't seem to care if
the drive is on or not -- devstatus gives the same output as above
if the drive is off, or if there is no tape in the drive. I know this sounds cliche'd, but indeed I successfully
read files from the same tape on the same drive a few days ago. If you have an idea as to what might be causing this problem, I'd appreciate
it a lot. Thanks for your time and help.--Yan Fernandez
Univ. of Maryland.

Yan,> The following is typical of the problems I'm experiencing. The device
> name (for using the tar and mt commands in unix) is /dev/rmt/1n. The
> device name in IRAF is mtb0.
>
> cl> !mt -f /dev/rmt/1n status
> cl> !mt -f /dev/rmt/1n rewindHere you are referencing /dev/rmt/1n and it appears to be working fine.> cl> rewind mtb0
> ERROR: Cannot open device (0bn)
> cl> rfits mtb0 1 junk make-
> ERROR: Cannot open device (0bn)Here IRAF is trying to talk to /dev/rmt/0n (0bn is an alias). Perhaps
your tapecap entry is pointing to a different unix device than intended?> The problem is not tapedrive-specific, it happens on all of the ones we
> have here.Well, there may be something else going on, but let's look at the
tapecap first. Does your entry for this device look something like:mtse1|mtst1.solaris.exb8200|Exabyte 8200 drive on Solaris:\
:al=1 1bn 1cb 1cn 1hb 1hn 1lb 1ln 1mb 1mn 1u 1ubn \
1b 1c 1cbn 1h 1hbn 1l 1lbn 1m 1mbn 1n 1ub 1un:\
:dv=1bn:lk=1:tc=solaris-exb8200:or are there lots of 0's instead of 1's? What is the value of the
:dv= entry (lower left here)? Is it :dv=1bn, or :dv=0bn?> If it helps in the diagnosis: physically turning off the tapedrive
> doesn't remove the problem. In fact, IRAF doesn't seem to care if
> the drive is on or not -- devstatus gives the same output as above
> if the drive is off, or if there is no tape in the drive. IRAF and other high level software rely on the host system (Solaris,
in this case) to manage tape drives, printers and such. The IRAF
devstatus task maintains it's own knowledge of the state of the tape
drive. This has advantages and disadvantages, but is hard to avoid
in any event in machine independent software like IRAF.> I know this sounds cliche'd, but indeed I successfully read files
> from the same tape on the same drive a few days ago. Was the device moved around on the SCSI bus? Have there been any
changes to the IRAF or unix configuration since then? Has the machine
been rebooted since the problems started (or immediately before)?
Is there a file /tmp/<drive>.lok corresponding to this tape drive?
What does it look like, who owns it and with what permissions?
The various /dev/rmt/ entries are actually symbolic links to arcane
directories and files like: /devices/iommu@f,e0000000/sbus@f,e0001000/dma@2,81000/esp@2,80000/st@4,0:n(An example, your links will be subtly different.) Do all the
directories and the final file pathname have appropriate permissions?Let us know what you find.Rob Seaman
NOAO/IRAF