qman$master.dat help needed!

[Paul Coviello]

in going thru the online system managers manual about printing...

there is a point about being in a cluster and setting up a logical for qman$master... now we don't have this defined in our cluster do I need to? all the files are in the original locations.

7.3-2 alpha vms cluster 3 nodes

thanks
Paul

[Uwe Zessin · Accepted solution]

Paul,
you don't need this logical name as long as you have a single system disk. And it is easy to define it later and overwrite the location of the other data files in QMAN$MASTER.DAT

[Paul Coviello]

and we do have a single system disk thanks
Paul

[John Gillings]

Paul,
Even if you have a single system disk, there is some benefit in defining your cluster environment as if it were on a different disk. That involves defining ALL the logical names documented in SYLOGICALS.COM. The benefit is that you can move your cluster environment around easily, or add a system disk, or keep a backup environment etc...

The important thing about QMAN$MASTER is, if it is defined, it must be defined *IDENTICALLY* on all nodes in the cluster.

The best way to enforce consistency across your cluster is to have SYLOGICALS.COM mount the disk containing the environment, then execute a procedure on that disk to define all the logical names.

[Jan van den Ende]

John,


The best way to enforce consistency across your cluster is to have SYLOGICALS.COM mount the disk containing the environment, then execute a procedure on that disk to define all the logical names.


Is LNM$SYSCLUSTER_TABLE not designed just for that?

fwiw

Cheers.

Have one on me.

Jan

[Uwe Zessin]

But just defining the logical name QMAN$MASTER is not enough - you need to tell the system that the location of the other queue files has changed, too. See attachment.

[Paul Coviello]

ok but with a single system disk why do I need to tell it to mount, and if I haven't changed the location of any files, I don't see the point.

thanks for your help

Paul

[Uwe Zessin]

I agree. If this is a nice and simple environment that is unlikely to undergo any changes, I wouldn't invest any time. You rather risk disruptions if you make any error. I doubt that your users or management will say 'thank you'.

[Jan van den Ende]

Paul,

I agree with Uwe, if you do not NEED it, do not DO it!.

As far as I know, there can be 3 reasons to do it; if one or more apply, then, and only then, it is usefull, and deserves the effort. (All resons boil down to Multiple System Disk configurations)

1. Mixed architecture.
A VAX/Alpha or Alpha/IA64 (& VAX/Alpha/IA64, although not supported, they work!) cluster require (at least) a separate system Disk per architecture.
Unless you care to experiment with multiple queue managers, that REQUIRES the QMAN files to be NOT on the system disks.

2. Rolling upgrades.
If you intend to perform rolling upgrades, then during your upgrade you have a clone of your SD at the beginning of the upgrade.
After the upgrade you switch your cluster nodes to the upgrades SD. If that contained your QMAN files, you would revert all your job statusses, resubmitting the jobs that ran in the meantime, and missing jobs submitted then.

3. Multisite clusters. You will want your queue stuff available when a site is unavailable for whatever reason.

But, if none of those applies: KISS
(Keep It Simple, Stupid!)
... at least, whatever it will be, you now have arguments that base your decision upon.

Success.

Cheers.

Have one on me.

Jan