Why does BACKUP ignore /since=BACKUP ?

Why does BACKUP ignore /since=BACKUP ?

Post by Rainer Lande » Sat, 16 Mar 1996 04:00:00



Hello all.

I'm on a VAXcluster (VMS 6.2) with a VAX 6000-410 and some
3100 Workstations and a MicroVAX.

Problem is:
During weekly incremental backup the following command is
automatically created by a DCL script and then executed:
===================================
$ backup /rec /ignore=(inter,label) /list=USER_BACKUP.LIST -            
   ! the command
DISK$USER1:[*...]*.*;0/exc=([*...]*.exe;*,*.obj;*,*.map;*,*.gks;
*,*.tex_*;*,*.log;*,*.lis;*,*.dvi;*) -
 ,DISK$USER4:[MUELLER...]*.*;0/exc=([*...]*.exe;*,*.obj;*,*.map;*,*.gks;
*,*.tex_*;*,*.log;*,*.lis;*,*.dvi;*) -
    -
    -
    -
    -
    -
    -
    -
    -
   /SINCE=BACKUP   -
    PHY3$MKB500:USER08MAR.inc/save -
    /BLOCK=65534 /COMMENT="bck week tape 30"
===================================================================
(The 2nd, 4th, 6th line have been wrapped around here to get it
 readable.)

Problem is: Although it is specified "/SINCE=BACKUP" and the last
BACKUP/REC has been done one week before --- as every friday ---
the command will backup ALL files, regardless if they have been
altered during this week or not.
Example:
[AP1.GAYMANN]LOGIN.COM;8 has been backed up.

dir/date=(mod,backup) login.com gives:

Directory DISK$USER1:[AP1.GAYMANN]

LOGIN.COM;8           5-APR-1994 14:31:38.01  11-MAR-1996 14:19:21.15

So the backup has been recorded (as is done every week...)
although the file has not been altered since 2 years!

I have changed the position of the "/since=backup" qualifier in
the backup command because the documentation says it's important,
but this did not change anything.

The last time it worked O.K. was one year ago with VMS 6.0 and
an IBM 3480 Backup tape drive.
We did not use this dcl routine for backups for one year, because
the drive broke.
Now we use it again, have changed to VMS 6.2, changed the node
BACKUP is running, from the microvax to a station3100, and have
"cleaned up" the routine at some places where errors were located,
and now...

By the way, the files to be backed up are located on the VAX 6000-410.

Can anyone shed some light on it?

Thanks,

--
Rainer Landes                 eMail:

Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
Computer facilities of the Faculty of Physics, University of Karlsruhe,
GER

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Alfred Falk 450-51 » Tue, 19 Mar 1996 04:00:00




Quote:> I'm on a VAXcluster (VMS 6.2) with a VAX 6000-410 and some
> 3100 Workstations and a MicroVAX.

> Problem is:
> During weekly incremental backup the following command is
> automatically created by a DCL script and then executed:
> ===================================
> $ backup /rec /ignore=(inter,label) /list=USER_BACKUP.LIST -            
>    ! the command
> DISK$USER1:[*...]*.*;0/exc=([*...]*.exe;*,*.obj;*,*.map;*,*.gks;
> *,*.tex_*;*,*.log;*,*.lis;*,*.dvi;*) -
>  ,DISK$USER4:[MUELLER...]*.*;0/exc=([*...]*.exe;*,*.obj;*,*.map;*,*.gks;
> *,*.tex_*;*,*.log;*,*.lis;*,*.dvi;*) -
>     -
>     -
>    /SINCE=BACKUP   -
>     PHY3$MKB500:USER08MAR.inc/save -
>     /BLOCK=65534 /COMMENT="bck week tape 30"
> ===================================================================
> (The 2nd, 4th, 6th line have been wrapped around here to get it
>  readable.)

> Problem is: Although it is specified "/SINCE=BACKUP" and the last
> BACKUP/REC has been done one week before --- as every friday ---
> the command will backup ALL files, regardless if they have been
> altered during this week or not.
> Example:
> [AP1.GAYMANN]LOGIN.COM;8 has been backed up.

> dir/date=(mod,backup) login.com gives:

> Directory DISK$USER1:[AP1.GAYMANN]

> LOGIN.COM;8           5-APR-1994 14:31:38.01  11-MAR-1996 14:19:21.15

> So the backup has been recorded (as is done every week...)
> although the file has not been altered since 2 years!

> I have changed the position of the "/since=backup" qualifier in
> the backup command because the documentation says it's important,
> but this did not change anything.

> The last time it worked O.K. was one year ago with VMS 6.0 and
> an IBM 3480 Backup tape drive.
> We did not use this dcl routine for backups for one year, because
> the drive broke.
> Now we use it again, have changed to VMS 6.2, changed the node
> BACKUP is running, from the microvax to a station3100, and have
> "cleaned up" the routine at some places where errors were located,
> and now...

> By the way, the files to be backed up are located on the VAX 6000-410.

> Can anyone shed some light on it?

By any chance do you run PathWorks-Mac?
If so, see the VMS 6.2 Release Notes, section 3.3.
I had the same symptoms.  Digital Support pointed me to that section of
the Release Notes, and the solution there worked for me.

---------------------------------------------------------------------------

Information Systems Dept          (403) 450-5185            R E S E A R C H
Box 8330, Station F                                           C O U N C I L
Edmonton, Alberta, Canada
T6H 5X2
http://saturn.arc.ab.ca/~falk/                     http://www.arc.ab.ca/

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Robert Koehl » Wed, 20 Mar 1996 04:00:00


: Hello all.

: I'm on a VAXcluster (VMS 6.2) with a VAX 6000-410 and some
: 3100 Workstations and a MicroVAX.

: Problem is: Although it is specified "/SINCE=BACKUP" and the last
: BACKUP/REC has been done one week before --- as every friday ---
: the command will backup ALL files, regardless if they have been
: altered during this week or not.

Check the modify dat on the directories.  A change in backup/since handling
of VMS 6.2 or so now backs up all files in any directory that has been
modified.  It's not clear to me exactly why.

------------------------------------------------------------------------------
Bob Koehler                     | CSC/SSD/MITG

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Rainer Lande » Tue, 26 Mar 1996 04:00:00


Still no success, summary so far:

...

Quote:

> Problem is: Although it is specified "/SINCE=BACKUP" and the last
> BACKUP/REC has been done one week before --- as every friday ---
> the command will backup ALL files, regardless if they have been
> altered during this week or not.


#If you don't have /MOD, it's not clear which file date it compares to
#the BACKUP date.

I added /MOD, but still EVERYTHING was backed up on last friday...


section 3.3 and sent me a copy of the lines in question:

#"A recent change to fix other problems now causes Backup to detect whether
#a directory file has been modified since the date indicated by the Backup
#Date field in the file header.  If a directory file has been modified, all
#subdirectories and files of that directory are saved for possible later restore
#operations.  Updating the modification date of directory files is unusual for
#OpenVMS systems, but it can happen, for example, if you rename a directory
#file from one location to another.  By contrast, the PW-Mac server maintains
#the modification date of directory files for Mac users; that is, it updates the
#modification date for each directory change, file creation, and file deletion."
#... and so on.


#Check the modify dat on the directories.  A change in backup/since handling
#of VMS 6.2 or so now backs up all files in any directory that has been
#modified.  It's not clear to me exactly why.

This does not describe my case (I don't use PATHWORKS/MAC, and the modification dates
of the directories are OK), but maybe it points to the right direction.(?)
---------------------------------------------
As mentioned before, I do every week:
$ backup /rec /ignore=(inter,label) /list=USER_BACKUP.LIST DISK$USER1:[*...]*.*;0  .....
   /SINCE=BACKUP    PHY3$MKB500:USER08MAR.inc/save .....

the dates show:
$dir/date=(mod,back) disk$user1:[000000]
AP1.DIR;1             5-APR-1994 12:23:27.94  23-FEB-1996 18:17:46.88
....

$dir/date=(mod,back) disk$user1:[ap1]
GAYMANN.DIR;1         5-APR-1994 14:31:37.59  22-MAR-1996 16:00:43.19
....

$dir/date=(mod,back) disk$user1:[ap1.gaymann]
LOGIN.COM;8           5-APR-1994 14:31:38.01  22-MAR-1996 16:00:43.19
....              

So: The directory disk$user1:[ap1] which _WAS_ backed up at 22-mar-1996 did not
get recorded! (It has the backup date of the last FULL backup on 23-FEB-1996)
but the modification date is nearly 2 years old.
The subdirectories, e.g. disk$user1:[ap1.gaymann], and everything below, WERE backed up and GOT RECORDED
on 22-MAR-1996 althogh it has not been modified since 2 years.

Other ideas/questions:

The backup routine (written by an previous system manager some years ago) uses version
numbers of  ";0". What does that mean? Can this be a part of the problem?

The command has 13 continuation lines, quite a lot. Can this be part of the problem?
Although in the backup the command is recorded in full length.

But, alltogether, to me this seems like a bug in VMS.

Are there still other ideas as to what to do now?

--

Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
Computer facilities of the Faculty of Physics, University of Karlsruhe, GER

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by jnor.. » Wed, 27 Mar 1996 04:00:00



>  Still no success, summary so far:

<snip>  

>  Other ideas/questions:

>  The backup routine (written by an previous system manager some years ago) uses
version
>  numbers of  ";0". What does that mean? Can this be a part of the problem?

File.ext;0 specifies a relative version number; i.e. the most recent version.
Quote:

>  The command has 13 continuation lines, quite a lot. Can this be part of the

problem?
No
>  Although in the backup the command is recorded in full length.

>  But, alltogether, to me this seems like a bug in VMS.

>  Are there still other ideas as to what to do now?

>  --

>  Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
>  Computer facilities of the Faculty of Physics, University of Karlsruhe, GER

How about reviewing what is actually in the saveset?  Before going much further, I
would want to know what files are present in the saveset.
For what it is worth, on my V6.2 system, backup/since=backup works fine going from
disk to disk.
Jim Norris
 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by mloeff.. » Wed, 27 Mar 1996 04:00:00



>  Still no success, summary so far:

[SNIP]

Quote:>  Other ideas/questions:
>  The backup routine (written by an previous system manager some years ago) uses version
>  numbers of  ";0". What does that mean? Can this be a part of the problem?

[SNIP]
>  But, alltogether, to me this seems like a bug in VMS.

Not sure why your incrementals don't work, but I wouldn't think it would be related to the ";0".  This indicates to
use only the current version (I.E.: Only backup the top-most version instead of all versions).  ";" is functionally
equivalent (at least as far back as VMS v5.1).

----------------------------------------------------------
Michael J. Loeffler
Teletrade, Inc.

The opinions expressed are my own and not necessarily that
of my company.
----------------------------------------------------------

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Syseca Gm » Wed, 27 Mar 1996 04:00:00




>>  Still no success, summary so far:

><snip>  

>>  Other ideas/questions:

>>  The backup routine (written by an previous system manager some years ago) uses
>version
>>  numbers of  ";0". What does that mean? Can this be a part of the problem?
>File.ext;0 specifies a relative version number; i.e. the most recent version.

>>  The command has 13 continuation lines, quite a lot. Can this be part of the
>problem?
>No
>>  Although in the backup the command is recorded in full length.

>>  But, alltogether, to me this seems like a bug in VMS.

>>  Are there still other ideas as to what to do now?

>>  --

>>  Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
>>  Computer facilities of the Faculty of Physics, University of Karlsruhe, GER

>How about reviewing what is actually in the saveset?  Before going much further, I
>would want to know what files are present in the saveset.
>For what it is worth, on my V6.2 system, backup/since=backup works fine going from
>disk to disk.
>Jim Norris

Are you sure that the original backups were done with backup/record.
If not, backup/since=backup has no effect. Do a test with one
particular file and check the backup date using DIR/FULL.
Peter Blaquiere.
 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Carl J Lydi » Fri, 29 Mar 1996 04:00:00


=

=>>  Still no success, summary so far:
=>>
=><snip>  
=>>  
=>>  Other ideas/questions:
=>>  
=>>  The backup routine (written by an previous system manager some years ago) uses
=>version
=>>  numbers of  ";0". What does that mean? Can this be a part of the problem?
=>File.ext;0 specifies a relative version number; i.e. the most recent version.
=>>  
=>>  The command has 13 continuation lines, quite a lot. Can this be part of the
=>problem?
=>No
=>>  Although in the backup the command is recorded in full length.
=>>  
=>>  But, alltogether, to me this seems like a bug in VMS.
=>>  
=>>  Are there still other ideas as to what to do now?
=>>  
=>>  
=>>  
=>>  --

=>>  Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
=>>  Computer facilities of the Faculty of Physics, University of Karlsruhe, GER
=>>  
=>>>>>
=>How about reviewing what is actually in the saveset?  Before going much further, I
=>would want to know what files are present in the saveset.
=>For what it is worth, on my V6.2 system, backup/since=backup works fine going from
=>disk to disk.
=>Jim Norris
=
=
=Are you sure that the original backups were done with backup/record.

He probably is.

=If not, backup/since=backup has no effect. Do a test with one
=particular file and check the backup date using DIR/FULL.

That probably won't help him.  The problem is almost certainly that BACKUP now
checks the backup dates for both the target files AND all directories used to
find the target files.  If, for either the target file, or any of its
directories, the backup date is non-existent or older than the appropriate date
(modification date, by default, if I recall correctly), then the file will be
backed up.  E.g., the command:
        $ BACKUP DEV:[DIR1.DIR2]FILE.TYPE/RECORD/SINCE=BACKUP save_set_name/SAVE
will copy DEV:[DIR1.DIR2]FILE.TYPE if:
        1)  The backup date of DEV:[DIR1.DIR2]FILE.TYPE is earlier than its
            modification date;
        2)  The backup date of DEV:[DIR1]DIR2.DIR;1 is earlier than its
            modification date;
        3)  The backup date of DEV:[000000]DIR1.DIR;1 is earlier than its
            modification date; or
        4)  The backup date of DEV:[000000]000000.DIR;1 is earlier than its
            modification date;
--------------------------------------------------------------------------------

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by E.M.B. Pou » Sun, 31 Mar 1996 04:00:00





> >>  Still no success, summary so far:

> ><snip>  

> >>  Other ideas/questions:

> >>  The backup routine (written by an previous system manager some years ago) uses
> >version
> >>  numbers of  ";0". What does that mean? Can this be a part of the problem?
> >File.ext;0 specifies a relative version number; i.e. the most recent version.

> >>  The command has 13 continuation lines, quite a lot. Can this be part of the
> >problem?
> >No
> >>  Although in the backup the command is recorded in full length.

> >>  But, alltogether, to me this seems like a bug in VMS.

> >>  Are there still other ideas as to what to do now?

> >>  --

> >>  Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
> >>  Computer facilities of the Faculty of Physics, University of Karlsruhe, GER

> >How about reviewing what is actually in the saveset?  Before going much further, I
> >would want to know what files are present in the saveset.
> >For what it is worth, on my V6.2 system, backup/since=backup works fine going from
> >disk to disk.
> >Jim Norris

> Are you sure that the original backups were done with backup/record.
> If not, backup/since=backup has no effect. Do a test with one
> particular file and check the backup date using DIR/FULL.
> Peter Blaquiere.

Since VMS 6.2 the backup-strategy is changed. You should make a stand-alone backup
to record the backup-date of device:[000000]000000.dir as of that time backup will
behave like is should. If you change any directory-file the files below are copied
during the next backup/since=date=backup.

I hope this will help.

Kind regards,
Edwin.

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by alan » Fri, 05 Apr 1996 04:00:00



Quote:>That probably won't help him.  The problem is almost certainly that BACKUP now
>checks the backup dates for both the target files AND all directories used to
>find the target files.  If, for either the target file, or any of its
>directories, the backup date is non-existent or older than the appropriate date
>(modification date, by default, if I recall correctly), then the file will be
>backed up.  E.g., the command:


 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Carl J Lydi » Sat, 06 Apr 1996 04:00:00



=
=>That probably won't help him.  The problem is almost certainly that BACKUP now
=>checks the backup dates for both the target files AND all directories used to
=>find the target files.  If, for either the target file, or any of its
=>directories, the backup date is non-existent or older than the appropriate date
=>(modification date, by default, if I recall correctly), then the file will be
=>backed up.  E.g., the command:
=

I'm not sure, but I suspect it's to deal with the following scenario:

$ INIT PDA0 TEST
$ MOUNT PDA0 TEST
%MOUNT-I-MOUNTED, TEST         mounted on _$1$PDA0: (SOL1)
$ CREATE/DIR PDA0:[A]
$ CREATE PDA0:[A]TEST.DAT
This is a test.
$ BACKUP/IMAGE/LOG PDA0:/RECORD SYS$LOGIN:TMP.TMP/SAVE
%BACKUP-S-COPIED, copied PDA0:[000000]A.DIR;1
%BACKUP-S-COPIED, copied PDA0:[A]TEST.DAT;1
%BACKUP-S-COPIED, copied PDA0:[000000]BACKUP.SYS;1
%BACKUP-S-HEADCOPIED, copied PDA0:[000000]BADBLK.SYS;1 header
%BACKUP-S-HEADCOPIED, copied PDA0:[000000]BADLOG.SYS;1 header
%BACKUP-S-HEADCOPIED, copied PDA0:[000000]BITMAP.SYS;1 header
%BACKUP-S-COPIED, copied PDA0:[000000]CONTIN.SYS;1
%BACKUP-S-COPIED, copied PDA0:[000000]CORIMG.SYS;1
%BACKUP-S-HEADCOPIED, copied PDA0:[000000]INDEXF.SYS;1 header
%BACKUP-S-COPIED, copied PDA0:[000000]VOLSET.SYS;1
%BACKUP-S-COPIED, copied PDA0:[]000000.DIR;1
%BACKUP-I-STARTRECORD, starting backup date recording pass
$ CREA/DIR PDA0:[B]
$ SET FILE/ENTER=PDA0:[B]FU.BAR PDA0:[A]TEST.DAT
$ SET FILE/REMOVE PDA0:[A]TEST.DAT;
$ BACKUP/LOG/SINCE=BACKUP PDA0:[*...]/RECORD SYS$LOGIN:TMP.1/SAVE
%BACKUP-S-COPIED, copied PDA0:[000000]000000.DIR;1
%BACKUP-S-COPIED, copied PDA0:[000000]A.DIR;1
%BACKUP-S-COPIED, copied PDA0:[000000]B.DIR;1
%BACKUP-W-NOFILES, no files selected from PDA0:[*...]*.*;*
%BACKUP-I-STARTRECORD, starting backup date recording pass
%BACKUP-W-NONEREC, no files processed on recording pass
$ DISMOUNT PDA0
$ MOUNT/FOREIGN PDA0
%MOUNT-I-MOUNTED, TEST         mounted on _$1$PDA0: (SOL1)
$ BACKUP/IMAGE/LOG SYS$LOGIN:TMP.TMP/SAVE PDA0:/RECORD
%BACKUP-S-CREATED, created PDA0:[000000]A.DIR;1
%BACKUP-S-CREATED, created PDA0:[A]TEST.DAT;1
%BACKUP-S-CREATED, created PDA0:[000000]BACKUP.SYS;1
%BACKUP-S-CREATED, created PDA0:[000000]CONTIN.SYS;1
%BACKUP-S-CREATED, created PDA0:[000000]CORIMG.SYS;1
%BACKUP-S-CREATED, created PDA0:[000000]VOLSET.SYS;1
%BACKUP-S-CREATED, created PDA0:[]000000.DIR;1
$ DISMOUNT PDA0
$ MOUNT PDA0 TEST
%MOUNT-I-MOUNTED, TEST         mounted on _$1$PDA0: (SOL1)
$ BACKUP/INCREMENTAL/LOG SYS$LOGIN:TMP.1/SAVE PDA0:/RECORD
%BACKUP-S-INCDELETE, deleted PDA0:[A]TEST.DAT;1
%BACKUP-S-CREDIR, created directory PDA0:[B]
$ DIRECTORY/SIZE=ALL PDA0:[*]

Directory PDA0:[B]

FU.BAR;1           no such file

Total of 1 file, 0/0 blocks.
--------------------------------------------------------------------------------

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

 
 
 

Why does BACKUP ignore /since=BACKUP ?

Post by Rainer Lande » Sat, 13 Apr 1996 04:00:00


Hello all.

It was me that originally put up the question.

OK, this now has been solved. Carl finally got me on the right track, although other
people had the same idea much earlier, but the solution was screened behind a logical
name...

thanks to










 >That probably won't help him.  The problem is almost certainly that BACKUP now
 >checks the backup dates for both the target files AND all directories used to
 >find the target files.  If, for either the target file, or any of its
 >directories, the backup date is non-existent or older than the appropriate date
 >(modification date, by default, if I recall correctly), then the file will be
 >backed up.  E.g., the command:
        $ BACKUP DEV:[DIR1.DIR2]FILE.TYPE/RECORD/SINCE=BACKUP save_set_name/SAVE
will copy DEV:[DIR1.DIR2]FILE.TYPE if:
        1)  The backup date of DEV:[DIR1.DIR2]FILE.TYPE is earlier than its
            modification date;
        2)  The backup date of DEV:[DIR1]DIR2.DIR;1 is earlier than its
            modification date;
        3)  The backup date of DEV:[000000]DIR1.DIR;1 is earlier than its
            modification date; or
        4)  The backup date of DEV:[000000]000000.DIR;1 is earlier than its
            modification date;
--
To make a long story short, the "root" of the directory tree that I am backing up,
DISK$USER1: was not a name of a disk but a logical name which pointed to PHY1$DUA1:[USER.]
And PHY1$DUA1:[000000] had never been backed up before...
I only had checked DISK$USER1:[000000] and below, which had backup dates OK.

So, everything is fine again after I backuped the real root directory of this disk.

If anyone wants to use our Backup-Routine --- it needs some site-specific modifications,
but this should be easy --- you will find it at:

ftp://fphvax.physik.uni-karlsruhe.de/bck_daemon.com (108Blocks)

--

Tel. (+49) 721 608 3578       http://fphvax.physik.uni-karlsruhe.de/
Computer facilities of the Faculty of Physics, University of Karlsruhe, GER

 
 
 

1. "/IGNORE=LABEL" doesn't ignore: BACKUP Bug or Feature?


=The scenario: a batch job that I run monthly to create a software/data
=distribution tape uses commands something like:
=
=$ MOUNT/FOREIGN/NOUNLOAD MUA0:
=$ BACKUP/IGNORE=LABEL/VERIFY DISK7:[PDQUPD]*.* -
=   MUA0:PDQUPDFEB.BCK/SAVE
=$ DISMOUNT/NOUNLOAD MUA0:
=
=The result: BACKUP complains that the tape being used, which is a
="recycled" TK50 initialized with a volume label of "SCRTCH", doesn't
=have the proper label - please mount the proper one". None of the VMS
=5 on-line REPLY switches seem to cause the correct continuance, i.e.
=overwriting the old volume label and continuing the job.
=
=The question(s): What's going on here? What am I doing wrong?

I don't know.  I *DO* know that with some third-party tape drives and
controllers, BACKUP can't init the tape properly.

=How can I do it right?

A simple workaround is:
        $ MOUNT/FOREIGN/NOUNLOAD MUA0:
        $ DISMOUNT/NOUNLOAD MUA0:
        $! Note:  The above MOUNT and DISMOUNT are to insure that the tape is
        $! loaded prior to issuing the INIT request
        $ INIT MUA0 PDQUPD
        $ MOUNT/FOREIGN/NOUNLOAD MUA0:
        $ BACKUP/IGNORE=LABEL/VERIFY DISK7:[PDQUPD]*.* -
           MUA0:PDQUPDFEB.BCK/SAVE
        $ DISMOUNT/NOUNLOAD MUA0:
--------------------------------------------------------------------------------

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

2. Connection Pool Issue...

3. BACKUP/IGNORE=INTERLOCK fails

4. Wanted : specs for MSDOS commandlines I/O, escaping characters...

5. Backup /ignor=interlock = not ignoring

6. MSN Messenger 6 automatically updating itself?

7. Wanted: replacement for BACKUP with /IGNORE=INTERLOCK feature

8. Audio DSP

9. Backup /ignor=interlock = not ignoring

10. Request for new BACKUP /IGNORE=RMS option

11. Restoring VMS 5.4 Backup on DOS/Win Platform

12. Help Needed - Error message when doing backups

13. Problemas with memory allocation while doing standolane backup