can MODPARAMS have conditional logic?

[Jess Goodman]

Can you use any conditional logic in MODPARAMS.DAT, or to be more precise, in an AGEN$INCLUDE_PARAMS file?

I have a lot of systems and some of common sysgen parameters vary only between system architecture or VMS version.

I believe I read somewher that a "$" prefix before a VAX-only parameter defintion will prevent Alphas from complaining about an unknown parameter. Are there any other tricks (hacks?) like that?

I see that AUTOGEN reads thru MODPARAMS.DAT and any AGEN$INCLUDE_PARAMS files with DCL READs and parses the records for the symbol name itself. So it looks like a line like:
IF VERSION .GES. "V7.3-2" THEN MPDEV_REMOTE = 1
won't work.

With a 33 node cluster it is a pain to individually edit all the node-specific MODPARAMS.DAT files when I want a parameter set to one of two different values based on system type/version.

[Jim_McKinney]

> can MODPARAMS have conditional logic?

Yes. You can use single line conditional commands. For example:

IF F$EDIT(F$GETSYI("SCSNODE"),"COLLAPSE") .EQS. "NODEA" THEN USERD2=1234

is valid (but, it will also create warnings in the AGEN$PARAMS.REPORT that results from AUTOGENing).

[Jim_McKinney]

Or, more like your example

if f$edit(f$getsyi("version"),"collapse") .eqs. "V7.3" then mpdev_remote=1

[Robert Gezelter]

Jess,

Yes, but you don't use conditional logic.

What you DO is to use the equivalent of the SYS$COMMON and SYS$SPECIFIC hierarchy. I believe that I mentioned it in my paper on inheritance based systems variability (the abstract and reprint are available through my www site at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html .

I have to run now, but let me know if the above is not clear enough.

- Bob Gezelter, http://www.rlgsc.com

[Thomas Ritter]

We use the same approach as Bob recommends. We rely on a common file for essential parameters.

In each sys$system:modparams we include

!
AGEN$INCLUDE_PARAMS COMMON:[SYSMGR]SYSTEM_CLUSTER_PARAMS.DAT
!

[Robert Brooks_1]

Please note that MPDEV_REMOTE can be set to 1 from V7.3-1 and beyond. Support for the remote path was added in V7.3-1.


-- Rob

[Dave Laurier]

We also use the method of including parameter files in the MODPARAMS.DAT.

For example in a dual node cluster the file $1$DGA100:[SYS0.SYSEXE]MODPARAMS.DAT contains:

!
AGEN$INCLUDE_PARAMS SYS$COMMON:[SYSEXE]MODPARAMS.CLUSTER
!
AGEN$INCLUDE_PARAMS SYS$COMMON:[SYSEXE]MODPARAMS.COMMON

In our case we have separated the parameters over the following files:

MODPARAMS.COMMON
MODPARAMS.CLUSTER
MODPARAMS.NO_CLUSTER
MODPARAMS.SHADOW

[Thomas Ritter]

Jess,

please view

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

about thanking those that helped.

[Jan van den Ende]

Jess,

we have several sets of (hardware-, or function-) related AGEN$INCLUDE_xxxx
Only, we always call them from SYS$SYSTEM.

If needed, the node specific ones are in SYS$SPECIFIC, but the bulk are ONLY in SYS$COMMON.
Because of the potential conflicts, they are nerly all MIN_ or MAX_ setting.

Autogen irritates us by giving warnings about multiples, but we know to ignore them.

Since the include files can be nested, the specific ones tend to be only slightly different sets of include files from common.

For instance, each MODPARAMS contains SYS$SYSTEM:AGEN$INCLUDEFILE_MEMORY

And each SYS$SYSTEM:AGEN$INCLUDEFILE_MEMORY is a one-liner:
AGEN$INCLUDEFILE_BIGMEM or AGEN$INCLUDEFILE_SMALLMEM
(because all but one of are systems are bigmem, AGEN$INCLUDEFILE_MEMORY pointing to BIGMEM is in SYS$COMMON, and only one SYS$SPECIFIC holds one pointing to AGEN$INCLUDEFILE_SMALLMEM)

As often this is just _A_ solution.
Several options offered already, pick what suits you best!

hth

Proost.

Have one on me.

jpe