Conference turris::microvax

        The MS42-CA (16MB) cannot be configured with the MS42-KA (8MB) (I
        think they won't fit) but that is the only restriction that I know of.
    
        24MB can be achieved with either MS42-KA+MS42-BA (8+12 as you are
        doing) or MS42-CA+MS42-AB (16+4). The SOC says nothing about the
        order of the parts.
    
        What does the console think? (Try TEST 50). You did AUTOGEN didn't
        you?
    
        Antonio

:Unfortunately, after the upgrade, the system boots into VMS as 16Mb!

   Check the SYSGEN parameter PHYSICALPAGES (raise it if needed),
   and re-AUTOGEN.

:Is there a problem with having the smaller board (8Mb 5419830-01) before the
:larger (12Mb 5418287-01)? I know that if I had a 16Mb board instead of the 8Mb,
:everything would work (we have a system like that).

   This configuration should work.

What are the valid configurations?

   On the VAXstation 3100 series (other than the model 76):

     MS42-CA 16MB and MS42-KA 8MB modules allow a second board,
     either an MS42-AB 4MB or MS42-BA 12MB.

   The VAXstation 3100-76 uses up to eight MS44-AA 4MB boards.

:P.S. All this ancient knowledge should really be stored somewhere. This isn't
:the only time I've wanted an "Ancient Systems and Options Guide".

   Hey!  Stay out of my file cabinet!  :-)

   --

   The other `gotcha' with the entire VAXstation 3100 series...
   These systems can *not* be reliably booted and operated off
   a local SCSI system disk larger than 1.073GB, regardless of
   the host operating system.  OpenVMS prior to V6 supports data
   disks of up to 8.5GB, while V6.0 and later support 1TB disks
   as data drives.

Thanks, All!

AUTOGEN is what was needed. I don't know why. In my past experience, adding
memory caused SHOW MEMORY to display the new total, and one then ran AUTOGEN to
cause the other parameters to correspond to the new amount. This time, I needed
to run AUTOGEN first. Perhaps someone manually set PHYSICALPAGES, and running
AUTOGEN removed that setting?

Thanks alot,
John Saunders
DECdns Engineering

   < AUTOGEN is what was needed. I don't know why. In my past experience,
   < adding
   < memory caused SHOW MEMORY to display the new total, and one then ran
   < AUTOGEN to
   < cause the other parameters to correspond to the new amount. This time,
   < I needed
   < to run AUTOGEN first. Perhaps someone manually set PHYSICALPAGES, and
   < running
   < AUTOGEN removed that setting?
    
    Starting with VMS V6.0, AUTOGEN sets physical pages to the total amount
    of memory found at the time of the autogen rather than setting it to
    its theoretical max.  This change is documented in the release notes.
    You must rerun autogen in order for PHYSICALPAGES to be set correctly.
    
    Brian Hibbert
    

Thanks, Brian. I must not have added memory to any system after V6.0...

John Saunders
DECdns Engineering

    Hi,
    
    I don't know if this is related, but perhaps someone could help.
    
    My customer recently purchased a 3100 Model 98 with 128MB of memory and
    an additional 128MB upgrade to provide 256MB total.
    
    All of the packing slips etc indicate that the system should have
    256MB, yet when the customer does a show mem, the system thinks it only
    has 128MB.  The system was installed by Digital service so I believe
    the memory is physically present.  
    
    Are the previously discussed Autogen steps required?  Could this be a
    microcode issue (ie system can't see beyond 128MB)?
    
    Any help is appreciated.
    
    Bill

   Re-run AUTOGEN, and make sure that PHYSICALPAGES gets set
   sufficiently high.  (_Why_ AUTOGEN was recoded to ever lower
   the setting of PHYSICALPAGES is beyond me...)

    Just an update.  The customer ran AUTOGEN and the extra 128MB of memory
    appeared.  They couldn't reboot because of the importance of the
    application the machine runs, but will do so at a later date.
    
    
    Thanks,
    Bill