Conference cookie::sls

2224.0. "SYSTEM-F-VOLINV sls v2.8" by IJSAPL::KNOL (isn't every bug a bit wrong) Wed Mar 19 1997 05:52

    problem:
    
    sls starts next backup sequence and gets the following error:
    (no errors in the rdev_server and or rdev_client logs, no errors
    in the other log files or in the hardware errorlog)
    
    config:
    
    alpha cluster with hsj's v2.7 and tl820 robots, 
    several clients (vax andalpha)  
    OpenVms V6.2 and SLS V2.8 
    
     run/NODEBUG sls$system:sls$sysbak.exe
    %SLS-I-AUTOLOADING, automatically loading volume AAH316 in drive
    _IRAS$RDEVA0:
    %MOUNT-I-MOUNTED, AAH316 mounted on _IRAS$RDEVA0:
    %MOUNT-I-MOUNTED, AAH316 mounted on _IRAS$RDEVA0:
    %SLS-I-STARTING, starting volume AAH316 at position 27 on drive
    _IRAS$RDEVA0: at
     18-MAR-1997 05:07:43.59
    $ V = 1
    $ SET NOON
    $ ASSIGN _MBA4880: SYS$COMMAND
    $ ASSIGN _MBA4882: SYS$ERROR
    $ SET COMMAND SLS$SYSTEM:BACKUPCMD.CLD
    $ ASSIGN SLS$SYSTEM:VMSBUXX.EXE; BACKUP
    $ RUN/NODEBUG SLS$SYSTEM:SLS$LOAD_FINALSTS.EXE
    $ -
    BACK/LIST=_MBA4885:/FULL -
    DISK$OPENVMS:[*...]*.*;*/SINCE=BACKUP/IGNO=(LABE,INTE)/RECORD/BLOCK=65534
    -/EXCLUDE=[SYS*.SYSCOMMON...]*.*;* -
    _IRAS$RDEVA0:I_IRAS_VMS./PROT=(S:RW,O:RW,G:R,W:)/NOASSI
    %BACKUP-F-OPENOUT, error opening _IRAS$RDEVA0:[000000]I_IRAS_VMS.; as
    output
    -SYSTEM-F-VOLINV, volume is not software enabled
    %SLS-I-FINISHED, finished volume AAH316 on drive _IRAS$RDEVA0: at
    18-MAR-1997 05
    :07:47.74
    
    the next volume is selected mounted and the backup continues.
    
    (looks like the ipmt case cfs 43877  but I have no vc and/or tape
    errors)
    
    jan
    

This is fixed in V2.8A.  See the release notes section titled
"STORAGE LOAD Command Prevents Cluster Access to Device".

\David

    re.1
    
    I don't think that it's fixed in V2.8A.
    The volume is already loaded and mounted and backup is trying
    to write to the tape, which is failing....
    
    
    jan

    
    Engineering has received the ipmt case for this problem - it
    is case CFS.49828.  Under investigation.
    
    	-Marty

My response to the IPMT case was:

  It is possible, in V2.8, that a STORAGE LOAD on a different node
  in the cluster could leave the hsj device set "not available" even
  though the node running the sysbak has mounted the device.  Thus,
  before proceeding on this case, you must upgrade the server node(s)
  to V28A.  If you have more than one system disk in the cluster,
  make sure you upgrade SLS for each sys disk.  I also would advise
  upgrading the rdf client node because 2.8A does include a new
  version of RDF.

and the response from the field:

  Hi Marty,
  the solution is acceptable. However the customer
  has to decide to upgrade or not. The upgrade has
  a big impact for the customer.
  We will close the case.
  Thanks for help.