Hi friends!
It is a long time I have the following problem with my alphas. I already sent a message
to the list and I received some reply from people telling they got the same problem.
I noted the problem under Dunix 4.0d with no patch and it survived to
any 4.0d patch and it is still alive in 4.0e (2nd patch).
The problem exists for any tape device (tlz07 and tz885 at least) and any controller
(the two I checked at least!) and any shell (/sbin/sh, csh and tcsh) so I presume it is a
software bug.
The problem is concerning the vrestore of multitape saveset
(recovering data which was previously vdumped across two or more tapes).
You know that while vdump-ing when the EOT is reached you are request to mount the next tape.
Similary when you vrestore the same data you should be requested to mount the next tape
when the EOT is reached.
I found that vrestore of a multitape saveset does'nt ask for next tape when EOT is reached in
the following two situations:
1) you extract files but the environment language LANG is set to en_US.ISO8859-1
2) you do a vrestore -i but don't ask to extract any file (quit or exit)
The point 1) has been solved by DEC Engeeniring (case GOZ101108, mr. Gardner)
which gave to me new vrestore and vdump. Now MY vrestore works properly reguardless
any LANG setting.
===> Please note that True64 Unix 4.0e 2nd patch still have
===> old buggy vdump and vrestore
The point 2) has not been addressed by DEC Engeeniring (I don't know why) and now I can't
call them again since my software support has expired.
Of course I tested the LANG variable, but it is not guilty in this case (the error happens
even in Single User State).
Now I'm asking again the list (and hopefully some from COMPAQ) to help me in finding a solution
of the point 2) since it is very important to me.
I do vdumps at night, and after them I read back the tapes just to have the listing of what has
actually been dumped. The reading is done in a loop of
vrestore -if /dev/nrmt0h
ls
quit
which is very fast since no data is really restored. But, as I told before, when the
vrestore -i is done on a saveset which begins on a tape and ends on onother, then I got an error.
To bypass the problem I have to exit from vrestore not with "quit" but with "extract" which
properly asks for the next tape, but it takes a very long time to be executed even if
no file was previously selected ("add") for beeing restored.
The point 2) error is the following:
mt -f /dev/nrmt0h rew
mt -f /dev/nrmt0h fsf 2
vrestore -if /dev/nrmt0h
vrestore: Date of the vdump save-set: Thu Nov 18 08:16:50 1999
(/) quit
vrestore: nothing will be restored
vrestore: unable to forward tape to next file; [5] I/O error
I'll be very happy to receive any help about this topic from our list
and mainly from our DEC/COMPAQ of course!
Thank you all,
Emanuele
Just for documentation here it is the error produced in point 1)
mt -f /dev/nrmt0h rew
mt -f /dev/nrmt0h fsf 2
vrestore -xf /dev/nrmt0h
vrestore: Date of the vdump save-set: Thu Nov 18 08:16:50 1999
Exit the interactive shell without restoring any files.
unknown command
--
$$$ Emanuele Lombardi
$$$ mail: AMB-GEM-CLIM ENEA Casaccia
$$$ I-00060 S.M. di Galeria (RM) ITALY
$$$ mailto:lele_at_mantegna.casaccia.enea.it
$$$ tel +39 06 30483366 fax +39 06 30483591
$$$
$$$ |||
$$$ \|/ ;_;
$$$ What does a process need | /"\
$$$ to become a daemon ? | \v/
$$$ | |
$$$ - a fork o---/!\---
$$$ | |_|
$$$ | _/ \_
$$$* Contrary to popular belief, UNIX is user friendly.
$$$ It's just very particular about who it makes friends with.
$$$* Computers are not intelligent, but they think they are.
$$$* True programmers never die, they just branch to an odd address
$$$* THIS TRANSMISSION WAS MADE POSSIBLE BY 100% RECYCLED ELECTRONS
Received on Tue Nov 23 1999 - 11:27:21 NZDT