HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

Boot: Large system disk on VAXstation

The Question is:

I am currently using a vaxstation 3100 m76 with vms ver 5.5
I purchased a 2.4 gig hard drive and after I installed it
in the system and restoring the standalone backup of the old
drive the system will not boot from the new drive. I was told
that I may have to upgrade to vms ver 5.5-2 or higher.  I would
appreciate any help you could offer.

The Answer is:

      Unfortunately, the console firmware in all VAXstation models up to,
    and including the M76 has a limitation on the size of the boot disk.
    It cannot address logical blocks beyond 1.073GB (that's "real" 2**30
    GB, not "marketing" 10**9 GB). This is NOT dependent on the operating
    system version and the restriction most unlikely to ever be lifted (as
    that would require physical replacement of the console ROMs on your
    system). Perhaps if some wealthy 3100ophile were to throw a truckload
    of money at Digital?

      The upshot is that an RZ26 is about the largest disk that you can
    *BOOT* a 3100 from. Once the operating system is running, the limit
    on the largest disk which can be accessed is around 8GB for OpenVMS
    V5.5 and a several TB (?) for V6 and higher. So you can definitely USE
    your disk, you just can't boot from it reliably.

      If you're into unsupported hackery, you *can* make your disk bootable
    by ensuring that all the boot files and relevant bits of INDEXF.SYS are
    below the 1.073GB mar. Since your disk is 2.4GB and INDEXF.SYS is, by
    default placed in the middle of the drive (for performance), it's
    probably the inability to access INDEXF.SYS which is causing your
    problem. Using INIT/INDEX=BEGIN or INIT/INDEX=BLOCK:lbn can be used to
    force INDEXF.SYS into an accessible area of the drive. I'm not sure
    of the exact set of other files which needs to be placed in order to
    boot from your disk. I must stress that I *don't* recommend you take
    this path! Be warned that it *will* break if you do an image backup
    and restore. Upgrades may also be interesting.

      I'd recommend you use a smaller disk for your system (RZ24 or RZ25
    should be adequate). Place your page and swap files on the large disk
    as well as your data.

   This is covered in the FAQ.

   It's not just booting that can be a problem here, a system crash also
   uses the same "wrapping-at-1.073GB" boot drivers and -- unlike a failed
   boot -- a "wrap" that takes place while writing the dump file can really
   scrozzle the system disk, should the dump file be located past that 1.073
   GB mark...