| The WINDOW_SYSTEM parameter are okay. In the hopes that it might help, I
attached the MODPARAMS.DAT below. It is exactly the same as the one used
under VMS V5.1, except MSCP_LOAD and MSCP_SERVE_ALL are set to 0 to
turn off the cluster-wide sharing of local satellite disks (hoping to
increase cluster performace). What I did was install the VMS V5.1-1
upgrade and reboot. Everything hunky-dory. Then edit MODPARAMS.DAT as
described and edit SATELLITE_PAGE.COM to mount the local disks /SYSTEM,
instead of /CLUSTER. I then autogen and reboot, and "No graphics
devices found", "No DECwindows drivers are going to be loaded", "Go
home you're a loser".
Also noticed that the page and swap file are not being installed even
though I stuck a SET VERIFY in SATELLITE_PAGE.COM and watched them get
installed at boot time! Is there some kind of pattern here that
somebody recognizes? There is something easy that I am overlooking.
If I do @SATELLITE_PAGE.COM after I log in, they install fine.
The wierdest thing of all is that if I use the exact same MODPARAMS.DAT
file, change WINDOW_SYSTEM to 2, add the magic VWS parameters to
the bottom (attached below), and then autogen reboot, VWS comes up
fine.
Is it possible that my MODPARAMS.DAT is using values which are evil?
It's 2:30 in the morning and I can't think of anything else to try.
----------------------------------------------------------------------------
attached: MODPARAMS.DAT
----------------------------------------------------------------------------
!
! Site specific AUTOGEN data file. In a VAXcluster where a common system
! disk is being used, this file should reside in SYS$SPECIFIC:<SYSEXE>,
! not a common system directory.
!
! Add modifications that you wish to make to AUTOGEN's hardware configuration
! data, system parameter calculations, and page, swap, and dump file sizes to
! the bottom of this file.
!
SCSNODE="DAYGLO"
SCSSYSTEMID=27766
NISCS_CONV_BOOT=1
WINDOW_SYSTEM=2
NISCS_LOAD_PEA0=1
VAXCLUSTER=2
VOTES=0
PAGEFILE=0
SWAPFILE=0
MSCP_LOAD=0
MSCP_SERVE_ALL=0
INTERCONNECT="NI"
!
!===============================================================================
! The sysgen parameter settings above this line were generated by the original
! system installation procedure. The settings below this line were added later
! by hand. In the future, it should be possible to throw away most of the
! settings below the line and let the AUTOGEN feedback mechanism take care of
! adjusting things automagically.
!
! The KITS cluster is a homogeneous cluster. If you make a parameter change on
! one system, please propogate this file and the change to all other systems.
! All systems should have exactly the same MODPARAMS.DAT file below the line.
!
! All parameters below should start with MIN_ so that AUTOGEN.COM can set
! them higher than is stated below if it wants to.
!
! Since VAXstations can run either DECwindows or VWS for windowing software,
! and the sysgen parameter settings are so different for each, there must be
! 2 different versions of this file for each VAXstation:
! MODPARAMS.DAT_DECW containing settings for running DECWINDOWS, and
! MODPARAMS.DAT_VWS containing settings for running VWS.
! When an AUTOGEN is to be performed, first copy the appropriate file to
! MODPARAMS.DAT and then run AUTOGEN. Because KITS and KBTOYS are not
! VAXstations, they cannot run VWS, but they can run DECwindows; therefore,
! they have only one version of this file called MODPARAMS.DAT.
!
! For all layered products.
!
MIN_VIRTUALPAGECNT = 100000 !50 MByte virtual address space per process
MIN_WSMAX = 20000 !10 MByte working set maximum per process
MIN_MAXPROCESSCNT = 50 !w DECwindows it's easy to have 30+ processes
MIN_NPAGEDYN = 900000 !guarantee over 10% free NPAGE for satellites
MIN_GBLPAGES = 40000 !prevent up-ing this every time install software
MIN_GBLSECTIONS = 500 !prevent up-ing this every time install software
MIN_SRPCOUNT = 2000
MIN_IRPCOUNT = 1000
MIN_LRPCOUNT = 127 !RDB V3.0 wants this
!
! To make subprocesses have same quota and limits as processes. It was noticed
! when running MMS, which runs in a subprocess, that compiles take much longer
! than doing the same compiles manually at the $. MMS was paging like crazy
! with a very small working set (and other small limits and quotas) even
! though all users have hefty settings in the UAF file. A little investigation
! revealed that the settings in the UAF file only pertain to processes while
! subprocesses get their settings from the following PQL parameters. Strange!
!
! Please check that the settings below match the current settings in the UAF
! file. All accounts in the UAF file should be identical, also.
!
MIN_PQL_DASTLM = 512
MIN_PQL_DBIOLM = 100
MIN_PQL_DBYTLM = 50000
MIN_PQL_DDIOLM = 100
MIN_PQL_DFILLM = 200
MIN_PQL_DPGFLQUOTA = 40000
MIN_PQL_DPRCLM = 50
MIN_PQL_DTQELM = 100
MIN_PQL_DWSDEFAULT = 2048
MIN_PQL_DWSQUOTA = 6144
MIN_PQL_DWSEXTENT = 20000
MIN_PQL_DENQLM = 3092
MIN_PQL_DJTQUOTA = 4096
!
! To prevent modification of existing page, swap, and dump files. The pagefile
! and swapfile for all the satellites are local and are located in the dir
! LOCAL_DUA1:[SYS0.SYSEXE]. There are only 2 dump files. KBTOYS has its own
! dump file in its own SYS$SPECIFIC:[SYSEXE] directory. The satellites all
! share a dump file in the SYS$COMMON:[SYSEXE] directory. See "VAX/VMS V5.0
! Release Notes" pg 8-41.
!
PAGEFILE = 0 ! always 50K bl, except KBTOYS and KITS 75K bl
SWAPFILE = 0 ! always 20K bl
DUMPFILE = 0 ! 65541 for 32 Mbyte
----------------------------------------------------------------------------
attached: Magic VWS parameters added to bottom of above MODPARAMS.DAT
----------------------------------------------------------------------------
!
! For VWS V4.0. These were barfed out by the VWS startup command file,
! claiming that VWS would not run until these parameters were properly set-up.
!
MIN_CHANNELCNT = 400
MIN_CTLPAGES = 1500
MIN_GBLSECTIONS = 512
MIN_GBLPAGFIL = 17600
MIN_NPAGEDYN = 419840
MIN_NPAGEVIR = 1259520
MIN_PAGEDYN = 3072000
MIN_PROCSECTCNT = 64
MIN_PQL_MASTLM = 600
MIN_PQL_MBIOLM =40
MIN_PQL_MBYTLM =10000
MIN_PQL_MDIOLM =100
MIN_SPTREQ = 2300
|
| Well it's 3:45 in the morning and following the release notes solved
the DECwindows problem. That is, placing @SYS$MANAGER:DECW$STARTUP.COM
in the batch job which starts up the network (after the line
@SYS$MANAGER:STARTNET.COM) works. It just takes forever for the
DECwindows login screen to popup though, so I had to be patient. So if
anybody else has the same problem as I did, now you know what to do.
Thanks Mike Foley for your suggestion!
Unhappily, the swap and page file still are not being installed even
though SATELLITE_PAGE.COM is definately being executed at boot time (I
know because I stuck a SET VERIFY in SATELLITE_PAGE.COM and I can see
it execute before SYSTARTUP_V5.COM starts). Again, this problem
started at the same time as the DECwindows problem and the turning off
of cluster-wide disk serving for the local disks. I assume the
problems are unrelated, but they surfaced at exactly the same time.
Are the parameters MSCP_LOAD and MSCP_SERVE_ALL in any way influencing
SATELLITE_PAGE.COM, or I am still missing something obvious? Any
ideas would be appreciated. SATELLITE_PAGE.COM is attached below.
Again, it works fine under VWS and it used to work fine under VMS V5.1.
PS. I know in the previous reply I have WINDOW_SYSTEM = 2 instead of
= 1 in the attached MODPARAMS.DAT - a goof due to my flipping back and
forth between DECwindows and VWS trying to figure out this problem.
----------------------------------------------------------------------------
attached: SATELLITE_PAGE.COM
----------------------------------------------------------------------------
$ verify = 'F$VERIFY(0)'
$ !
$ ! Delete the temporary page file that Satellite_config created
$ !
$ if f$search("PAGEFILE.TMP") .eqs. "" then goto WAITDEVICE
$ Delete/nolog PAGEFILE.TMP;*
$ !
$ ! Install the secondary page and swap files
$ !
$
$WAITDEVICE:
$ if f$getdvi("DAYGLO$DUA1", "EXISTS") then goto MNTDEV
$ write SYS$OUTPUT "***** Waiting for page/swap device: DAYGLO$DUA1 *****"
$ wait ::05
$ goto WAITDEVICE
$
$MNTDEV:
$ mount /noassist/system DAYGLO$DUA1 DAYGLO1 DAYGLO1
$ if .not. f$getdvi("DAYGLO$DUA1", "MNT") then goto NO_PAGEFILE
$
$INSTALL_FILES:
$
$ SYSGEN := $SYSGEN
$
$SWAPFILE:
$ if f$search("DAYGLO$DUA1:<SYS0.SYSEXE>SWAPFILE.SYS") .eqs. "" then goto PAGEFILE
$ SYSGEN INSTALL DAYGLO$DUA1:<SYS0.SYSEXE>SWAPFILE.SYS /SWAPFILE
$
$PAGEFILE:
$ if f$search("DAYGLO$DUA1:<SYS0.SYSEXE>PAGEFILE.SYS") .eqs. "" then goto NO_PAGEFILE
$ SYSGEN INSTALL DAYGLO$DUA1:<SYS0.SYSEXE>PAGEFILE.SYS /PAGEFILE
$
$ verify = 'F$VERIFY(verify)'
$ EXIT
$NO_PAGEFILE:
$ WRITE SYS$OUTPUT "Did not install page or swap file"
$ verify = 'F$VERIFY(verify)'
$ EXIT
$
|
| I too experience the failure to install page and swap (posted
in VMSNOTES 1508.5). It only happens on my DECWindows satellites,
and I am at a loss to explain why. Page and swap can be installed
manually after the system is up, by reinvoking SATELLITE_PAGE.COM
This was happening to me with VMS V5.1 - I've just switched
to V5.2 and haven't seen the problem (yet), but we haven't rebooted
much since the upgrade...
I am trying a workaround in SYSTARTUP_V5 to check to see if
a pagefile was installed and reinvoking SATELLITE_PAGE if necessary.
(Naturally) I haven't seen the problem since updating SYSTARTUP_V5.
The related lines are:
$ reply/user=(system,krantz,vanlaanen) "Checking Pagefile"
$ if f$getsyi("pagefile_page") .eq. 0
$ then
$ old_verify = f$verify( 1 )
$ reply/user=(system,krantz,vanlaanen) "Pagefile was not installed"
$ @sys$system:satellite_page.com
$ wait 0:5:0
$ trash = f$verify( old_verify )
$ endif
The REPLYs are to help track the problem, and the WAIT it to give
us a chance to get to the system and see what (if anything) went wrong
with the reinvocation of SATELLITE_PAGE
I'd really appreciate hearing from anyone who is having (or
corrected!) this problem.
Joe
|