[Info-vax] AGEN$INCLUDE_PARAMS

[Keith Parris]

On 8/1/2011 11:47 PM, Phillip Helbig---undress to reply wrote:
> 1) AGEN$INCLUDE_PARAMS is a useful place to put stuff common to (a
> subset of) all nodes booting from a given system disk.
>
> 2) In addition to SYS$SPECIFIC and SYS$COMMON, I also have an area on a
> non-system disk for stuff common to all nodes in the cluster, for
> example SYSUAF.DAT.
>
> I would like to put 1) and 2) together.
>
> In the case of normal operation, this shouldn't be a problem.  However,
> sometimes I want to boot a node without access to the common non-system
> disk, which (I think) might include (automatically) running AUTOGEN.
> (This is usually for reboots when applying patches or as part of an OS
> upgrade.)  If a file on the common non-system disk isn't accessible,
> then AUTOGEN will issue a warning and continue.  However, this is not
> what I want, since the include file contains some hard-coded values
> which override the AUTOGEN-calculated values.
>
> What I am looking for is something like
>
> SHADOWING=2
> FIX_SHADOWING=1
>
> In other words, prefixing any parameter in MODPARAMS.DAT with FIX_ would
> freeze its value until it is overridden in MODPARAMS.DAT (not when
> another value is calculated by AUTOGEN).  The idea is that the
> information as to which parameters are "fixed" would be stored somewhere
> other than in MODPARAMS.DAT, thus in my case preserving their values for
> runs during which the include file is not accessible.
>
> Does anyone else feel a need for this or a similar feature?  Is there
> any way to get this or similar functionality now?
>
> (This might be useful in other contexts as well.  For example,
> FIX_<value>  without specifying the value itself could freeze the value
> calculated by this run of AUTOGEN.  One could have an include file
> specifying which values are to be fixed, run AUTOGEN, then make the file
> inaccessible.  Subsequent runs of AUTOGEN would then leave these values,
> whatever they happened to be calculated as, alone.  The idea would be to
> make the file accessible for "real" runs of AUTOGEN and then not have to
> worry when running AUTOGEN while testing something etc (when perhaps
> feedback is not valid, the load is not typical etc).  An alternative to
> this would be some way to tell AUTOGEN to modify ONLY the parameters in
> a file and leave all others alone.  Is there any way to get this
> functionality now?)
>
> Of course, another way to achieve the goal stated at the top of this
> post is to have an include file on the common non-system disk and
> propagate changes to copies of it on all the system disks.  This would
> be easier than incorporating the changes in all individual MODPARAMS.DAT
> files.

Perhaps one of your AGEN$INCLUDE_PARAMS lines in MODPARAMS.DAT could use 
a logical name (possibly a search list) which, when booted normally, 
would point to the cluster-common disk, and when booted independently, 
would point to a suitable substitute (which could contain a copy of the 
cluster-common file, as you noted).