iraf.net

>From bouche@nova.astro.umass.edu Mon Oct 30 15:34:31 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
cc: Shashi <shashi@fcrao1.astro.umass.edu>
Subject: Re: tapecapI am trying to read an exabyte tape from IRAF.
The tapecap is configured as follows:
-----------------------------
# Unit assignments (Linux).
# ---------------------------mtdlt0|mtst0-dlt|DLT drive:\
:dt=DLT drive:al=st0 nst0:\
:dv=/dev/nst0:lk=st0:tc=generic-dat:mtdat1|mtst1-dat|HP DAT drive unit 1:\
:dt=HP 35480A Helical Scan DAT drive:al=st1 nst1:\
:dv=nst1:lk=st1:tc=generic-dat:mtexb0|mtst0-exb|Exabyte drive on ST 0:\
:al=st0 nst0:\
:dv=nst0:lk=st0:tc=generic-exabyte:mtexb1|mtst1-exb|Exabyte drive on ST 1:\
:al=st1 nst1:\
:dv=/dev/nst1:lk=st1:tc=generic-exabyte:-----------------------------The exabyte drive seems to be on /dev/nst1.
However, when i try to allocate, i get the following err message:cl> alloc nova!mtexb1
ERROR: cannot allocate device nova!mtexb1
allocate (device=nova!mtexb1)What should i do?Nicolas-------------------------------------------------------------
Nicolas Bouche bouche@nova.astro.umass.edu
Dpt of Astronomy
LGRT 531A
University of Massachusetts Tel: 1-413-545-3026
Amherst, MA 01003 e-Fax: 1-501-423-8108
(Fax: 1-413-545-4223)
-------------------------------------------------------------
>From fitz Tue Oct 31 11:53:09 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapHi Nicolas,
Several things to check: The ":dv" field in the mtexb1 tapecap entry
should be just "nst1", the system will automatically check in the /dev
(and /dev/rmt) directories on the machine for the device. Second, there
is a typo is the linux tapecap file where the ":tc=generic-exabyte" should
read ":tc=generic-exb" to properly link to an entry below that.
Also, be sure that this is the tapecap file on 'nova' and not a
local one. Since you're using iraf networking then you should use the
NETSTAT command to be sure iraf networking is enabled on the local
machine (otherwise it fails and tries to access /dev/nst1 on the local
node). The dev$hosts file should contain both the local and remote nodes,
be sure the iraf paths are correct and a 'hostname' command returns just
'nova' and not 'nova.astro.umass.edu'. The first two lines of the NETSTAT
output will say which is used and whether networking is properly setup.
Hope this helps, let me know if you still have problems or questions.Cheers,
-Mike

>From bouche@nova.astro.umass.edu Wed Nov 1 10:39:36 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,The networking part seems to work, e.g. smurf:cl>dir nova!/home produces
the right output.
However alloc mtexb1 does not work on nova. I get, from nova:cl> alloc mtexb1
rw access to /dev/st1 is denied
cl> So, it seems it's a permission problem. However, the *.lok file has not
been created.Another thing is, i cannot deallocate the DLT drive. This drive works.
>From both nova and smurf, i have the same problem:cl> alloc mtdlt0
cl> devstat
device for which status is desired (mtdat0): mtdlt0
# Magtape unit mtdlt0 status Wed 12:28:47 01-Nov-2000 user bouche
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0
cl> cd /tmp
cl> ls *lok
mtst0.lok
cl> dealloc mtdlt0
Warning: Cannot open device (/dev/nst0)
cl> dealloc mtdlt0
device mtdlt0 is not allocatedNote the .lok file has been produced in this case.Nicolas >From fitz Wed Nov 1 10:49:42 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,> The networking part seems to work, e.g. smurf:cl>dir nova!/home produces
> the right output.
I'm assuming /home on nove and /home on smurf have different
contents and aren't cross-mounted or anything, and that NETSTAT also
confirms it's working?> However alloc mtexb1 does not work on nova. I get, from nova:
>
> cl> alloc mtexb1
> rw access to /dev/st1 is denied Check the ownerships and permissions on /dev/st1 and /dev/nst1,
they should be owned by root with permission -rw-rw-rw-. The lok file
isn't created because the alloc failed before then, but you should also
check that the /tmp on nova has world write permission.> cl> dealloc mtdlt0
> Warning: Cannot open device (/dev/nst0)
> cl> dealloc mtdlt0
> device mtdlt0 is not allocated When deallocating a drive it first tries to rewind the device, but
you'll get this message is there is no tape in the drive. You can use
"dealloc mtdlt0 rew-" to deallocate without rewinding, but it looks like
things are working here.Cheers,
-Mike

>From bouche@nova.astro.umass.edu Wed Nov 1 11:24:25 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecap
X-Status: Mike,> Check the ownerships and permissions on /dev/st1 and /dev/nst1,
> they should be owned by root with permission -rw-rw-rw-. The lok file
> isn't created because the alloc failed before then, but you should also
> check that the /tmp on nova has world write permission.OK, this is fixed now. But, i still can't read the tape! Here is what i get:ms> alloc nova!mtexb1
ms> mscrfits nova!mtexb1 temp
nova!mtexb1[1] -> temp0001.fits:ERROR on line 23: Bad tapecap entry for
magtape device (nova!mtexb1)
mscrfits (input=nova!mtexb1, output=temp)

The tape is a backup from our observations. I am assuming, it's ben
written with mscred (the observation were done with MOSAIC), but i am not
100% sure.
What are the other possiblities? It seems like it isn't a tar file.Thanks again,N>From fitz Wed Nov 1 11:29:06 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
Did you fix the ":tc=generic-exabyte" typo (should be 'generic-exb')
I mentioned earlier?? A "bad tapecap entry" usually means there's a typo
in the tapecap entry for the device, e.g. a missing '\' escape and the end
of a line, or a space after the '\', or a ":tc" field that is invalid.
You can use the SHOWCAP task to help track this down, e.g. cl> set graphcap = dev$tapecap (or some explicit filename)
cl> showcap
cmd : `set' device
| `*' (to dump full graphcap entry
| cc [arg1 [arg2 [arg3]]]
; cc : a two chararacter capcode (e.g., 'cm')
| an encoder program (non alpha first char)
; * set mtexb1 (you type this at the "*" prompt)You'll need to to this on nova directly, if you can't spot this feel free
to send me your tapecap file. -Mike>From bouche@nova.astro.umass.edu Wed Nov 1 11:39:05 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,I did fix the typo.Here is what i got with the showcap:
* set mtexb1
:al=st1 nst1:dv=nst1:lk=st1:dt=Exabyte EXB-8200 8mm tape drive:\
tt=P6-120MP:ts#2347794:bs#0:mr#32768r#32768:fb#10:rs#2000:fs#188416:\
mf:
The tapecap file has: (is attached to this email)# Unit assignments (Linux).
# ---------------------------mtdlt0|mtst0-dlt|DLT drive:\
:dt=DLT drive:al=st0 nst0:\
:dv=/dev/nst0:lk=st0:tc=generic-dat:mtdat1|mtst1-dat|HP DAT drive unit 1:\
:dt=HP 35480A Helical Scan DAT drive:al=st1 nst1:\
:dv=nst1:lk=st1:tc=generic-dat:mtexb0|mtst0-exb|Exabyte drive on ST 0:\
:al=st0 nst0:\
:dv=nst0:lk=st0:tc=generic-exabyte:mtexb1|mtst1-exb|Exabyte drive on ST 1:\
:al=st1 nst1:\
:dv=nst1:lk=st1:tc=generic-exb:[tapecap deleted]>From fitz Wed Nov 1 12:16:21 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
Any chance you sent me the tapecap file from smurf, or have a
dev$tapecap.nova on nova, or redefined your 'tapecap' environment variable
somewhere? The file you sent looks fine and the showcap output displays
all the fields so unless the file is the wrong one I don't see where the
error is. IRAF first looks for a 'dev$tapecap.<nodename>' file and if
that's not found falls back to 'dev$tapecap', assuming the 'tapecap'
environment variable hasn't named some other file to be used instead.
The tapecap file used would be the ones on nova which is why I asked
whether you're sure the files are from there and not smurf. Is the tape
readable on nova itself or do you get the same error?-Mike>From bouche@nova.astro.umass.edu Wed Nov 1 13:24:15 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,I am pretty sure the tapecap is from nova. There is no tapecap.nova
though. The tapecap is linked to tapecap.linux. There is no tapecap on
smurf, only tapecap.linuxI dont know if it's readable on nova because the package mscred is not
installed on nova. (that's partly why we go through all this)>From nova, devstat gives:
device for which status is desired (mtexb1):
# Magtape unit mtexb1 status Wed 14:17:02 01-Nov-2000 user bouche
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0
cl> >From smurf, devstat gives:ms> alloc nova!mtexb1
ms> devstat nova!mtexb1
# Magtape unit nova!mtexb1 status Wed 15:01:17 01-Nov-2000 user bouche
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0
ms> Nicolas>From fitz Thu Nov 2 10:56:21 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
I'm not sure what to suggest at this point since I see nothing
wrong with the tapecap you sent. What I'd try is to put a scratch tape
in the drive and try reading/writing it on nova to see if you get the
same errors using the standard RFITS/WFITS tasks. If you have an old
version of MSCRED there's a chance it may be a conflicting task name
in TTOOLS or FITSION (are either of these loaded???), but this shouldn't
complain about the tapecap entry. You might also try creating a tapecap.nova
file on nova with *only* the mtexb1/generic-exb entries to rule out a
control char or something in the file causing a premature EOF (but then
you wouldn't be able to alloc the drive).
If you like I could log in from here to check on things, let me
know. Otherwise, let me know what happens with the scratch tape tests.Cheers,
-Mike

>From bouche@nova.astro.umass.edu Fri Nov 3 14:05:41 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapI'd really appreciate if you could try to look at the files.Shashi, the sys administrator openned a temporary account on nova.
login as xxxxxxx, with xxxxxxx.It will be removed in three days.Hope this helps,THanks,
Nicolas BoucheFrom: Mike Fitzpatrick <fitz>
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
Give it another try. The tapecap looked okay but I noticed that
the tape drive was set to use a fixed 1024-byte block size (IRAF normally
expects a variable block size). I reset this with a mt -f /dev/st1 setblk 0command so if we're lucky it should be working now.
Let me know if there are still problems and I'll have another quick
look.Cheers,
-Mike>From bouche@nova.astro.umass.edu Fri Nov 3 14:16:42 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapNope, it didn't work..>From fitz Fri Nov 3 14:20:02 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapCould you deallocate the drive so I can have another look. Is there a
tape in the drive now that I could try reading??>From bouche@nova.astro.umass.edu Fri Nov 3 14:28:42 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapThe tape should be in there. (st1; nst0 is used for the backups)
The drive is deallocated.>From fitz Fri Nov 3 14:52:04 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapWell it worked fine for me.I first used 'dd' to pull off the image to disk and that worked.
Then I used the T2D task to read the same image, and that worked.
Then I installed a copy of MSCRED and did an MSCRFITS, and that worked.No 'bad tapecap' message through any of this. I did notice however that
the dev$hosts file contains *only* nova and the default NOAO machines.
I couldn't login to smurf but you should check that the hosts file there
contains both nova and smurf. Aside from an old version of MSCRED (or
the conflicts by having TTOOLS loaded I mentioned before), or the tape
block size being reset somehow, the only other thing this can be is a
networking problem. How exactly did it fail this last time??-Mike

>From bouche@nova.astro.umass.edu Fri Nov 3 14:59:02 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecap> No 'bad tapecap' message through any of this. I did notice however that
> the dev$hosts file contains *only* nova and the default NOAO machines.
> I couldn't login to smurf but you should check that the hosts file there
> contains both nova and smurf. Aside from an old version of MSCRED (orIt does contain both nova and smurf.> the conflicts by having TTOOLS loaded I mentioned before), or the tape
> block size being reset somehow, the only other thing this can be is a
> networking problem. How exactly did it fail this last time??The same way as before.I'll try to use dd instead. I'll let you know.Nicolas

>From bouche@nova.astro.umass.edu Fri Nov 3 15:31:46 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecap
I was able to copy the first 2 files with t2d on my local drive (from
smurf). rewind nova!mtexb1 works too.But, mscrfits does not work for me..Is there a way to read those files once they are on the disk?N

>From fitz Fri Nov 3 15:33:58 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapMscrfits will read the disk file images, if not then there may be something
wrong with the mscred package (too old?). -Mike

>From bouche@nova.astro.umass.edu Fri Nov 3 17:16:44 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecap> > Now, at the compilation time
> > mkpkg -p mscred -p tables
> >
> > I get spool.txt.(attached)
>
> The spool file didn't say what the errors were exactly, but
> I left some compiled binaries on nova in ~guest/mscred/bin.linux which
> you could just copy over.
>
Didn't help. I still got the same error message (after login off Iraf):
ms> alloc
device to be allocated (nova!mtexb1):
ms> mscrfits nova!mtexb1 dat
nova!mtexb1[1] -> dat0001.fits:ERROR on line 23: Bad tapecap entry for
magtape device (nova!mtexb1)
mscrfits (input=nova!mtexb1, output=dat)
ms> Note that it doesn't ask me for nova's passwd, anymore.So, i guess the problem is elsewhere...Anyway, MANY THANKS!!Almost there.Nicolas>From fitz Sun Nov 5 17:30:40 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
Since we know the tape is readable from nova the problem must be
on smurf somewhere. Could you arrange for a guest account for on both
smurf and nova so I can look into this. If you can get T2D to work from
smurf then you'll have the images on disk and this isn't as much
a priority. Anyway, let me know.Cheers,
-Mike

>From bouche@nova.astro.umass.edu Mon Nov 6 10:38:14 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapHi Mike,I gave you an account on smurf. Same as on nova.T2D works from smurfs, so i can get the data. It will require some
carefull management though, to get it all (23Gb) on disk.Thanks,Nicolas>From fitz Mon Nov 6 11:05:35 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecap
Cc: fitzNicolas,
I logged in and had a quick look but didn't see anything
obviously wrong. Could you let me know when would be a good time
I could try accessing the tape (tonight is fine if you could just
deallocate it before you leave)?? Also, could you try logging in
as 'guest' to see if it works from that account, I'm trying to rule
out any environment stuff in your account. It's getting more confusing
since T2D should fail in the same way as MSCRFITS if there were actually
a problem in the setup.Thanks,
-Mike

>From bouche@nova.astro.umass.edu Mon Nov 6 11:23:02 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,I tried from the guest accound, and i got the same error..OK, i'll deallocate the tape for you. I'll email you when I have done it.Nicolas>From bouche@nova.astro.umass.edu Mon Nov 6 11:59:02 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,this might be related: but when I allocate the tape, the first time it
asks for my password, but freezesms> alloc nova!mtexb1
Permission denied.
Password (bouche@nova.astro.umass.edu):untill I hit ^C.Note the 'permission denied' before the passwd inquery.Then here is what happens,ERROR: interrupt!!!
allocate (device=nova!mtexb1)
ms> devstat
device for which status is desired (nova!mtexb1):
device nova!mtexb1 is not currently allocated
tape position for nova!mtexb1 is undefined
ms> alloc nova!mtexb1
ms> devstat
device for which status is desired (nova!mtexb1):
# Magtape unit nova!mtexb1 status Mon 13:55:09 06-Nov-2000 user bouche
file = -1
record = -1
nfiles = 0
tapeused = 0 Kb
pflags = 0Seems odd to me that I have to hit ^C and then reallocate it.Nicolas>From fitz Mon Nov 6 12:19:26 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,> this might be related: but when I allocate the tape, the first time it
> asks for my password, but freezes
>
> ms> alloc nova!mtexb1
> Permission denied.
> Password (bouche@nova.astro.umass.edu):
>
> untill I hit ^C. I wish you'd mentioned the Ctrl-C a long time ago. IRAF networking
first tries to connect with an 'rsh' protocol, but since your machines aren't
setup to allow this (i.e. hosts not listed in each other /etc/hosts.equiv
file for a .rhosts file for each user) the rsh fails with a 'permission
denied'. This is normal and not fatal. At that point iraf tries to connect
using an rexec protocol which prompts for the passwd.
This should start the connection and spawn an irafks.e on the remote
machine to handle the connection (you won't be prompted again for the passwd
because there is already an open connection, until after some timeout period).
By typing Ctrl-C you are breaking this prematurely and who knows what part
of the irafks.e wasn't started properly, including perhaps the tapecap envir-
onment! You should log into nova and kill off any irafks.e processes that
you own. Then on smurf allocate the drive again and wait for the passwd
prompt to return! Ctrl-C is *never* a standard procedure for any iraf
operaton and will nearly always do bad things unless you clean up after it,
it should especially be avoided during tape operations unless you're sure
to rewind the tape (w/in iraf) and 'flpr' all tasks ('flpr 0' will get
rid of even cached tasks).
You can avoid the passwd prompts by creating a ".rhosts" file in
your unix login directory containing a line for both nova and smurf, as I
said one the irafks.e is running you won't be prompted any more so this isn't
critical. If you get more than one passwd prompt from the alloc, or it
hangs indefinitely this is a host networking problem that needs to be
resolved separately.-Mike

>From bouche@nova.astro.umass.edu Mon Nov 6 13:15:41 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,I wish i though about it too!
It did not ask me for a passwd, even after I logged off iraf several
times in the last few days. Except, today after i tried it as guest.
The thing is the prompt doesn't come back after asking for a passwd.
I have killed the irafks.e processes on nova (didn't see anything on
smurf), and now, it asks me for the passwd and returns to the prompt! But, still, mscrfits gives me the same error message, we are getting from
the beginning!

Note that when I dealloc and leave iraf, there is still one process irafks
running. When I am logged in iraf, there are three irafks.e running.
ms> alloc nova!mtexb1
ms> mscrfits nova!mtexb1 out
nova!mtexb1[1] -> out0001.fits:ERROR on line 23: Bad tapecap entry for
magtape device (nova!mtexb1)
mscrfits (input=nova!mtexb1, output=out)
Nicolas>From bouche@nova.astro.umass.edu Mon Nov 6 13:24:44 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: WaitMike,After, lots of experimentation:this works fine:
1)
cl> dir nova!/home
Permission denied.
Password (bouche@nova.astro.umass.edu):
andria cole frm keres scratch
...But this does NOT work, when 1) has not been done.
2)
cl> alloc nova!mtexb1
Permission denied.
Password (bouche@nova.astro.umass.edu): It just hangs there whithout returning the prompt.
Before, I was doing 1), then 2) which does work fine..:cl> dir nova!/
Permission denied.
Password (bouche@nova.astro.umass.edu):
amnt floppy iraf mnt2 scratch zip
bin h1 jaz mnt3 tmp
boot h2 lib proc usr
cdrom home lost+found removable var
dev incr.date mnt root vmlinuz
etc initrd mnt1 sbin vmlinuz.old
cl> alloc
device to be allocated (nova!mtexb1):
cl> Hope this helps to pinpoint the problem.Nicolas>From fitz Mon Nov 6 15:23:44 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapNicolas,
Got it, finally. Basically it's a binary incompatability problem.
Smurf and nova are running two different versions of GCC and the libc
libraries. The mscred binaries on smurf look like the ones I built on
nova and told you to install because of the other compilation problems you
were having. These were built statically against one version of the C
libs, but when run on the other machine something like a data structure
being passed to open a socket had changed and so it wouldn't run correctly
on the other machine with the other libs.
I was able to isolate the problem to just the mscred binary, then
when I downloaded the prebuilt RedHat binaries from our site and used
those everything worked as expected from smurf (presumably because the
RedHat libraries are more similar to smurf's libc). So, install the
ftp://iraf.noao.edu/iraf/extern/mscredV4.0/mscred-bin.redhat.tgz binaries
on smurf and everything should work.
The usual way to get compilation working under Debian systems is
to move the iraf$unix/bin.redhat/lib*.a files to unix$bin.linux but I
can't guarantee this will work for smurf.Cheers,
-Mike

>From bouche@nova.astro.umass.edu Mon Nov 6 16:19:46 2000
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,
> ftp://iraf.noao.edu/iraf/extern/mscredV4.0/mscred-bin.redhat.tgz binaries
> on smurf and everything should work. I think i did it, but it doesn't work, still.. The usual way to get compilation working under Debian systems is
> to move the iraf$unix/bin.redhat/lib*.a files to unix$bin.linux but I
> can't guarantee this will work for smurf.I don't have those libs. Where can I find them (without having to
resinstall IRAF)?My concern is that, even as guest on smurf, i am still having the same
symptoms: When i try to allocate the drive, after I typed in the passwd, I
don't get the prompt back, unless I hit ^C. This is regarless of mscred
being loaded or not.Any idea?Nicolas
>From fitz Mon Nov 6 16:23:48 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecap
> I think i did it, but it doesn't work, still..Move the mscred$bin.redhat binaries into the mscred$bin.linux directory.> I don't have those libs. Where can I find them (without having to
> resinstall IRAF)? They are there, do a "cd $iraf/unix/bin.redhat" as iraf to find
them. The move all the ".a" files to the $iraf/unix/bin.linux directory,
but better to use the prebuilt binaries.-Mike>From bouche@nova.astro.umass.edu Mon Nov 6 17:19:10 2000
Reply-To: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,OK, i've done the changes. But, I am afraid I am still having the same
problems.. This has no ending...N>From fitz Mon Nov 6 17:44:42 2000
To: bouche@nova.astro.umass.edu
Subject: Re: tapecapTry doing a setenv KSRSH ssheither in your .cshrc file or on the command line before logging into
the CL. I did this in my testing but it may be the required part
of the trick.-Mike

>From bouche@nova.astro.umass.edu Tue Nov 7 13:25:53 2000
From: Nicolas Bouche <bouche@nova.astro.umass.edu>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: tapecapMike,Don't worry, it's still working.
Just a minor error message when I allocate the tape:ms> alloc
device to be allocated (nova!mtexb1):
Agent parent directory is not sticky, mode is 40777 it should be 041777
bouche@nova's password:
Cannot make temporary authentication socket directory
/tmp/ssh-bouche-14859
ms>I thought I'd mention this temporary socket error.Cheers,
N