Conference vaxaxp::vmsnotes

What's the customer trying to do? /FOREIGN means that the application
driving the tape is responsible for volume swithing, and that has not
changed.

Jur.

   V7.1, and the "Redhawk" kit on V6.2, is a new MOUNT design, and this
   work has caused some illegal qualifier combinations to be rejected,
   combinations that were previously permitted but were meaningless or
   were illegal.  The work was intended to resolve a number of subtle
   (and not-so-subtle) problems seen with the older MOUNT design, and
   particularly around its use with shadowing.

   Recode the procedure to use the correct syntax.

Thanks for the prompt reply,

The customer feels the need to mount multiple volumes /FOREIGN and select the
volume labels to be used. As this was not a meaningless combination of Mount
qualifiers, why is it now 'illegal'. 

Also, do you have any ideas on how the customer should do the above?

Thanks

Scott.

   There is a known bug around ISO9660-format CD-ROM processing and the
   new MOUNT code that is being ECO'd -- if this is a different problem,
   please provide the specific details around just what the customer is
   up to here, and I can pass these along to the MOUNT maintainers.

    re .4
    
    What difference between MOUNT/FOREIGN and MOUNT/FOREIGN/NOAUTO did the
    customer perceive in previous versions of VMS? There is some suggestion
    (but I certainly can't verify it) that /AUTO is implemented by the ACP
    and hence would have been ignored if used with /FOREIGN in previous
    versions anyway.
    
    What application is handling the magtape?                     

1.     The command files that used the MOUNT/FOREIGN/NOAUTOMATIC had not been
       changed prior to the upgrade of VMS V7.1. This was working OK under VMS
       6.1 and under 7.0.

2.     We need the above mount command so as to make the tape available for an
       RMU backup of an RDB relational database. As the databases are very
       large, a full backup may require two DAT tapes, the routine requests the
       tapes be loaded, and their volume labels identified. The backup specifies
       these labels explicitly, so as to avoid the backup requesting an
       additional volume, where the volume label would be overridden by the
       backup. We make use of the volume labels as a control as to what is
       physically on these tapes, and therefore cannot let VMS write its own
       label.

           i.e. vol1 = 123400, vol2 = 123500,
                       and not vol2 ending up as 123402. !!

       As far as we are concerned, it was WORKING before and must remain so now
       and in the future. Therefore we need this resolved as soon as possible.


Does this help?

Scott.

: As far as we are concerned, it was WORKING before and must remain so now
: and in the future. Therefore we need this resolved as soon as possible.

   The customer said the magic works -- where's the IPMT?

re .7
    
>This was working OK under VMS 6.1 and under 7.0.
    
    Sorry to labour the point but was it actually working or was it just
    not producing an error message? i.e. did the customer ever verify what
    the labels getting written were? What is the difference in V7.0 or
    earlier between MOUNT/FOR and MOUNT/FOR/NOAUTO as far as observable
    effects are concerned?
    
    The fact that they are using the tapes with RMU/BACKUP makes some kind
    of sense i.e. that RDB might really have the tape end logic within
    it. (Unfortunately that might complicate any fix since we may not know
    what functionality Oracle was/is relying on, if any, and what it was/is
    doing.)
    
    Does RMU itself contain any qualifiers to get the desired tape label
    behaviour (as BACKUP does)? e.g. does RMU/BACKUP/LABEL=(...) have the
    desired effect? (Have the customer read the description.) While the
    customer may want to beat up on Digital for making an incompatible
    change, it may make more sense for them to discuss with Oracle whether
    Oracle RDB can already do what they want.

I think the following extract from the customers backup command file illustrates
the problem......



$       RMU/BACKUP/ONLINE -                ! Full Backup
          /LOG/NOREWIND/BLOCK_SIZE=49152 -
          /Label=('tape_label_list') -     ! May contain 1 or more volume labels
          /Tape_expiration="''keep'" -
          divorced$db -                    ! Logical for .RDB database
          tape:'backup_set'.rbf

$       RMU/BACKUP/ONLINE/INCREMENTAL=COMPLETE - ! Incremental Backup
          /LOG/NOREWIND/BLOCK_SIZE=49152 -
          /Label=('tape_label_list') -
          /Tape_expiration="''keep'" -
          divorced$db -
          tape:'backup_set'.rbf

$       RMU/BACKUP/AFTER_JOURNAL/QUIET_POINT/FORMAT=NEW_TAPE - ! Journal Backup
          /LOG/NOREWIND/BLOCK_SIZE=49152 -
          /Label=('tape_label_list') -
          /Tape_expiration="''keep'" -
          divorced$db -
          tape:'backup_set'.AIJ

(.7) I have just raised an IPMT so I hope that we can give the customer a fix or
at least a good explanation as to the reasoning behind the change.

Thanks.

Scott.

   I've done a number of multi-volume RMU tape backups over the years, and
   have never needed nor used that MOUNT command qualifier for them.

Steve could you please expand on .11.

Looking at the RMU backup commands used in .10, how do you suggest the customer
mounts multiple volumes while giving the volume labels.

If we go back to .0 you will remember that me original request was 

'My customer is not happy with the change and would like us to suggest an
alternative command to have the same result.'

If you have send suggestion, then I would appreciate any contructive help that
you could give.

Thanks.

Scott,

   I would expect RMU to handle to handle the volume switches and the
   volume labeling itself, either checking the labels or not, depending
   on the number of labels specified via the RMU /LABEL qualifier.  (If
   the customer wants to check all labels, then the RMU/BACKUP command 
   in the procedure needs to specify a sufficient number of labels.)

   MOUNT/NOAUTOMATIC is for ACP-mounted tapes.  If you look at MOUNT
   /AUTOMATIC, you will see references to the use of the magtape ACP,
   and to the ability to use multiple tape drives and multiple volumes
   and to switching.  If you look at /FOREIGN, you will see that no ACP
   is used, nor is an ACP provided.

   In other words, remove /NOAUTOMATIC, and specify enough /LABELs.

re .10

>I think the following extract from the customers backup command file
>illustrates the problem......

    It doesn't illustrate it sufficiently for me.

    The first paragraph in my .9 does not appear to have been answered i.e.
    while it is true that a combination of qualifiers that was previously
    accepted is now not accepted, is this of any consequence? What
    difference did it previously make? Since /AUTO apparently only applies
    to tapes controlled by the ACP did RMU really take any note of whether
    /AUTO or /NOAUTO was in force if MOUNT even made that information
    available for a tape mounted /FOREIGN, or, from a users perspective, is
    there any observable difference?
    
    Can the customer explain what functionality over and above
    RMU/BACKUP/LABEL is required?
    
    Can the customer explain what goes wrong if they just MOUNT/FOR the
    tape and do the RMU/BACKUP?