Conference vaxaxp::vmsnotes

659.0. "VAXCLUSIO01 won't install if sys$gl_base_level != X67K or R5K1" by COMICS::SUMNERC (OpenVMS Counter Intelligence) Thu May 29 1997 07:37

    	VAXCLUSIO01 won't install if sys$gl_base_level != X67K or R5K1
        ==============================================================
    
    
    Hello,
    
    Can anyone tell me what might change a system base level to be anything
    other then X67K or R5K1 ?
    
    My customers problem (now fixed) was as follows:
    ------------------------ Problem Description --------------------------
    Customer had a new 6.2 OpenVMS system disk on a 3100 (wanted to move it
    to a 4100)
    
    He has installed
    VAXF11X03_070
    VAXLOA02_070
    VAXRMS02_062
    VAXSYS06_070
    VAXSYS03_062
    
    He then wanted to installed VAXCLUSIO01   but as a requirement he had
    to install the following (he didn't reboot before or after these
    installations)
    
    VAXDOSD06_062
    VAXMANA03_070      <- Specified in VAXCLUSIO01 ECO kit
    VAXSYS05_070          customer didn't reboot between each patch
    			  application
    
    
    He then tried to install VAXCLUSIO01 which failed in the following
    way...
    
    31) VMS$REMEDIAL_ID (new image)
    
    This software ECO (remedial kit) is not compatible with the
    special version and/or component of OpenVMS VAX currently
    running on your system. The contents of this remedial kit are
    either already included with your system, or there is a
    special version of a software ECO that is compatible with your
    system. For assistance please contact your normal Digital
    support channel.
    
    %VMSINSTAL-E-INSFAIL, The installation of VAXCLUSIO01_ V6.2 has failed.
    %DELETE-W-FILNOTDEL, error deleting
     $2$DKB400:[SYS0.SYSUPD.VAXCLUSIO01_062]VAXCLUSIO01_062.TXT;1
    -RMS-E-FLK, file currently locked by another user
    %DELETE-W-FILNOTDEL, error deleting
     $2$DKB400:[SYS0.SYSUPD]VAXCLUSIO01_062.DIR;1
    -RMS-E-MKD, ACP could not mark file for deletion
    -SYSTEM-F-DIRNOTEMPTY, directory file is not empty
    
            VMSINSTAL procedure done at 11:52
    
    
    
    I didn some investigation and found the following piece of DCL located
    in the KITINSTAL.COM in the VAXCLUSIO01_062.A saveset.
    
    $Version_failure:
    $!
    $! If we get to this point, we have some an LHR or possibly
    $! field test release.
    $!
    $ type sys$input
    
      This software ECO (remedial kit) is not compatible with the
      special version and/or component of OpenVMS VAX currently
      running on your system. The contents of this remedial kit are
      either already included with your system, or there is a
      special version of a software ECO that is compatible with your
      system.  For assistance please contact your normal Digital
      support channel.
    
    $         exit vmi$_failure
    
    
    This code is triggered by the following DCL:
    $! Patch baselevel to identify this as a VAXCLUSIO_062 installed system
    $!
    $       open/write ofile vmi$kwd:dopatch.com
    $       write ofile "$ patch/journal=vmi$root:[sys$ldr]SYS.JNL " + -
            "/output=vmi$root:[sys$ldr]sys.exe vmi$root:[sys$ldr]sys.exe"
    $       write ofile "define sys$gl_base_level=8000444C"
    $       write ofile "verify/asc sys$gl_base_level='X67K'"
    $       write ofile "deposit/asc sys$gl_base_level='R5K2'"
    $       write ofile "update"
    $       write ofile "exit"
    $       close/nolog ofile
    $
    $       open/write ofile vmi$kwd:dopatch2.com
    $       write ofile "$ patch/journal=vmi$root:[sys$ldr]SYS.JNL " + -
            "/output=vmi$root:[sys$ldr]sys.exe vmi$root:[sys$ldr]sys.exe"
    $       write ofile "define sys$gl_base_level=8000444C"
    $       write ofile "verify/asc sys$gl_base_level='R5K1'"
    $       write ofile "deposit/asc sys$gl_base_level='R5K2'"
    $       write ofile "update"
    $       write ofile "exit"
    $       close/nolog ofile
    $
    $       open/write ofile vmi$kwd:checkr5k2.com
    $       write ofile "$ patch/journal=vmi$root:[sys$ldr]SYS.JNL " + -
            "/output=vmi$root:[sys$ldr]sys.exe vmi$root:[sys$ldr]sys.exe"
    $       write ofile "define sys$gl_base_level=8000444C"
    $       write ofile "verify/asc sys$gl_base_level='R5K2'"
    $       write ofile "exit"
    $       close/nolog ofile
    $
    $       define /process sys$output nl:
    $       define /process sys$error nl:
    $       set noon
    $       @vmi$kwd:dopatch
    $       saved_status = $status
    $       if .not. saved_status
    $       then
    $               @vmi$kwd:dopatch2
    $               saved_status = $status
    $       endif
    $!
    $! If we were not running X67K before, check to make sure we are
    running R5K1
    $!
    $       if .not. saved_status
    $           then
    $               @vmi$kwd:checkr5k2
    $               saved_status = $status
    $       endif
    $
    $       if f$search("vmi$root:[sys$ldr]SYS.EXE;-1") .nes. "" then -
                    purge vmi$root:[sys$ldr]sys.exe
    $       if f$search("vmi$root:[sys$ldr]SYS.JNL") .nes. "" then delete -
                    vmi$root:[sys$ldr]sys.jnl;*
    $!      if f$search("DOPATCH.COM") .nes. "" then delete dopatch.com;*
    $!      if f$search("CHECKR5K.COM") .nes. "" then delete CHECKR5K.com;*
    $       deassign /process sys$error
    $       deassign /process sys$output
    $       set on
    $
    $       if .not. saved_status then goto Version_failure
    
    ---------------------- end of problem description ----------------------
    
    
    So, if I understand this correctly, if the baselevel isn't X67K or R5K1
    the patch won't install.
    
    I asked the customer to check if he had installed *ALL* of the
    requested patches first - he had.
    
    The customer rolled back to a vanilla system, re-applied all patches
    with a reboot between each one and this time VAXCLUSIO01_062 patch
    installed OK.
    
    Can anyone offer any suggestions as to what may change the system base
    level (sys$gl_base_level).
    
    Thanks,
    
    Chris Sumner
    Enterprise Server Support, UK. 7833 3667.
    
    PS. If I'm barking up the wrong tree, will someone pull me down and
    point me in the direction of the correct tree to bark up.
    

    X67K was the Dragon SSB build, i.e. the OpenVMS VAX V6.2 build, I
    don't know about R5K1, but I also recall having seen some instructions
    on how to install and when to reboot the system...
    
    /cmos

    Hi,
    
    From the article:
    "BLITZ TITLE:  BLITZ SUPPORTING the OpenVMS V7.1 - V6.2 COMPATIBILITY
     KITS"
    
   "The VAXCOMPAT_062 kit will patch this longword and change it
    from "X67K" to "R5K1".  So, if you are looking at a dump or running
    system, typing "SDA> examine sys$gl_base_level" will show one or the 
    other."
    
    But what would cause this longword to be something else ?
    
    Thanks in advance,
    
    Chris

   Given things are working now that the customer followed the ECO
   directions, I'm not sure how much more effort this is worth...

   I've seen previous reports of problems with some ECO kits, when a
   reboot is not performed after the installation of the kit, before
   the next ECO kit is installed.  

   Without the journal files and without the "offending" baselevel ID
   seen by the kit -- information very likely unavailable -- it will
   be interesting to see which kit actually caused this (mis)behaviour.

   You might want to log a suggestion QAR against the ECO kit itself,
   as it would seem reasonable to log this information -- particularly
   the failing baselevel ID -- somewhere, or to display it as part of
   a message.

    Actually, the comment in the KITINSTAL is a little misleading...
    The 3 valid strings are X67K, R5K1 and R5K2 (so you can re-install
    the VAXCLUSIO01 kit on itself if you need to..)
    
    There is no easy way to display or log the version it 
    actually found, unless we were to display the sys$output from PATCH,
    which is ugly.
    
    The VAXCOMPAT_062 (R5K1) and VAXCLUSIO01_062 (R5K2) are the only 
    patch kits developed by OpenVMS Engineering that changes the 
    this cell (sys$gl_base_image).
    
    Sounds like the system worked as planned.  The customer had some
    unknown version of SYS.EXE that would potentially conflict with the
    rest of the kit, so the kit did not complete the installation.  Once
    the system was rebuilt under V6.2, it worked correctly.
    
    Agreed, it would have been interesting to know what the value in the
    cell was...  
    
    Cheers,
    jeff
    

    
:    There is no easy way to display or log the version it 
:    actually found, unless we were to display the sys$output from PATCH,
:    which is ugly.

  PATCH?  Who needs PATCH to look at this?  (We can create our own tool
  to look at the ECO, and does exactly what we want.  We have had a gap
  in OpenVMS in this area for a while -- we've never had a SHOW VERSION
  command.)

    >I'm not sure how much more effort this is worth.
    Call it interest.  That's why we're not logging this formally.  My
    customers problem was getting his systems working.  It wasn't until
    well after this, that I found what would cause this message.  I had bot
    previously heard if base levels before.
    
    If nothing else touchs this longword, is it possible that it just got
    corrupted ?
    
    Thanks anyway you guys, next time I'll check the baselevel value.
    
    Cheers,
    
    Chris

    Well, patch is what is used to figure out what the cell contains 
    and is used to deposit the new value in it (just like the major 
    version installs that uses patch to change the version from T7.1 to
    V7.1...)
    
    A SHOW VERSION wouldn't work in this case as the cell in question does
    not contain the version number as displayed in SHOW SYSTEM.  This is 
    an extra cell that is loaded with the build ID.
    
    Certainly, a tool could be written to read and display this cell.  It
    was not seen as a priority.  You can use SDA (as described in the 
    support Blitz) to get this information in the few cases where it fails.
    This is the first failure that I am aware of...
    
    BTW - I quickly reviewed the other patches that you believed were on
    the system and none of them touch that cell.  In addition, no kit for V6.2 
    ships SYS.EXE....  Either something else change the cell, or the 
    customer was not running V6.2-SSB...
    
    Cheers,
    jeff
    

    Hi Jeff,
    
    >>BTW - I quickly reviewed the other patches that you believed were on
    >>the system and none of them touch that cell. 
    Yeah, I found that too.
    
    >> In addition, no kit for V6.2 ships SYS.EXE....  Either something else 
    >>change the cell, or the customer was not running V6.2-SSB...
    I would have thought that, but it was a new system and he retraced his
    steps, except the second time he reboots after each patch install.
    
    Thanks for your interest guys, maybe someone else will get this and
    know the examine the base level longword.
    
    Chris
    

    Rebooting between kits should not have changed this behavior, since
    there is no change in SYS.EXE...
    
    Still a mystery to me..
    
    Cheers,
    jeff