Conference vaxaxp::vmsnotes

    The interdependency between ALPBOOT08_062 and the LAN and CLUSIO kit
    are in regards to the DE500-AA support.  If you have a DE500-AA, you
    need to install all of those kits so that you can both boot through
    it and use it once the system starts..
    
    I don't know of any other interdependencies.  If it truely required
    the other kits, it would be stated that the other kits are 
    mandatory.
    
    That all said, since the customer is reluctant to put on other TIMA
    kits, I would suggest you continue to try to find a workaround for 
    the original problem...
    
    Can you mount this disk on another node, clean up some other files and
    get MESSAGE_ROUTINES.EXE moved??
    
    Cheers,
    jeff
    

 
    Jeff,
    
    Thanks for the info, and for the quick response.
    
    > Can you mount this disk on another node, clean up some other files and
    > get MESSAGE_ROUTINES.EXE moved??
    
    I'm not sure how this would work.  How could I "move" MESSAGE_ROUTINES.EXE 
    in such a way as to ensure that it gets a lower file number?
    
    Stephen Burridge
    
    

  Stephen,
    I've seen exactly the same symptom on a VAX after installing VAXLIBR06_070
  on a 3100 with a 1.3GB system disk. MESSAGE_ROUTINES.EXE had landed across
  the 1.073GB mark which is the limit for a 3100 system disk. 

    Have your customer boot the system from CD and simply COPY the image,
  then use DIR/FILE to check the FID of the new version. Repeat until you
  have a small enough FID. If there are really no low numbered FIDs, you
  may need to free one up. I'm not sure what the allocation scheme is, but
  if it's "find first", just locate any file with a low enough FID, COPY
  it (should get a higher number), then DELETE the original. Now you should
  be able to COPY MESSAGE_ROUTINES.EXE and use the lower FID (however, I'm
  fairly sure the allocation scheme isn't that simple, so "repeat until
  low enough" may be your only choice).

    For my customer the first COPY created a new version below the magic
  limit. Unfortunately standalone DCL doesn't have a DUMP/HEADER command
  so he had to reboot to check it out. Before someone jumps - he will
  consider the risks of continuing with an (just) unsupported drive size
  against the cost and hassle of changing to a supported system disk.

						John Gillings, Sydney CSC

    re .3
    
    In trying to second guess the file number it may be helpful to know the
    behaviour of the FID cache. For example, it might be that with the FID
    cache *disabled* you will get "find first" behaviour which would give
    much more predictable results in this particular exercise.

Hi,

the FID cache is sorted so that the FID with the lowest file number 
is reused on any given create - which should help here.

Cheers,

Ian

Ian Brockbank,
OpenVMS Engineering Scotland

    Thanks very much for all the replies.
    
    My customer will re-apply ALPLIBR05_070 this weekend.  If he has the
    same problem, he will try deleting some low-numbered files & then
    copying the file with the problem FID.  If this doesn't work, he will
    apply ALPBOOT08_062.
    
    Stephen Burridge

    of course you can also trahs a file with a low FID by using
    $ COPY/OVERLAY (if the file is large enough to hold your new file)
    
    /cmos

    re .8
    
    Cute. I would have thought that /OVERLAY would extend the file as
    needed. Unless the disk is so fragmented that a whole extension file
    header is needed to perform the extension it should be guaranteed of
    producing a useable file.

    I would have to go back and re-check if the size matters. But if
    you also want to make sure that no segments of the possibly 
    fragmented file lands on the wrong side of the 1+ GB mark, you
    best pick a large enough file on the correct side, then rename it
    and copy it away to its original name, then overlay the new file
    onto this.
    
    I used to do this in the pre-V1 days of Alpha, when working with
    the Mannequin simulator and the boot would just take too long, and
    I was trying to use a new image...
    
    /cmos

   re .8:
    
>    I would have thought that /OVERLAY would extend the file as needed.
    
      I can confirm that COPY/OVERLAY definitely extends as required
    
    						John Gillings, Sydney CSC

    re .10
    
    Is the 1GB mark relevant here? I am aware that certain boxes have a
    restriction to booting from a small disk (VAXstation class) but the base
    note was talking about an Alpha. Certainly that is an additional peril
    on some VAXen but I can't believe that we ever sold an Alpha with the
    same problem!

    re: .12
    
    I agree we do not have the 1GB mark on the Alpha's, but the
    COPY/OVERLAY also works for VAXen, and since the MESSAGE_ROUTINES.EXE
    as part of the 10K fix caused some grief on older VAXen with the 1GB
    mark, and apparently some other grief on Alpha with the FID, I've
    chosen COPY/OVERLAY as just one way to 'place' a file on a disk...
    
    /cmos

    
.12: Is the 1GB mark relevant here? I am aware that certain boxes have a
.12: restriction to booting from a small disk (VAXstation class) but the base
.12: note was talking about an Alpha. Certainly that is an additional peril
.12: on some VAXen but I can't believe that we ever sold an Alpha with the
.12: same problem!

   That limitation involves the console boot drivers used in certain
   systems, such as the VAXstation 3100 series.  (And specifically,
   the maximum local system disk for any member of the VAXstation 3100
   series is 1.073 GB, due to the use of six-byte SCSI commands in the
   console boot driver -- the driver "wraps" read and write references
   on larger disks.)

   On those disks accessed only by the OpenVMS disk drivers, this limit
   does not apply -- the system disk can be accessed by the boot drivers
   during a system crash, which is why the potential for disk corruptions
   exists even after a successful bootstrap.  Data disks are accessed only
   by the OpenVMS device drivers, and are not subject to any boot driver
   limitations.