unexpected SHOW LICENSE output

[Willem Grooters]

3150 - see first post ;)

[Volker Halle · Accepted solution]

Willem,

so your license database is configured incorrectly !

If you would now try to reboot the V8.2 node or issue a LIC LOAD VMSCLUSTER, this will fail.

In a cluster, you either need to have all nodes access the SAME LMF$LICENSE.LDB file or have identical copies of this file on all system disks.

Volker.

[Jan van den Ende]

>>>
In a cluster, you either need to have all nodes access the SAME LMF$LICENSE.LDB file or have identical copies of this file on all system disks.
<<<

But in the latter case, you will always have to be very carefull to KEEP them synchronised, so, a LNM LMF$LICENSE pointing to ONE and the same file is WAY preferable!

Proost.

Have one on me.

jpe

[Volker Halle]

Jan,

yes, those files need to be kept in sync.

Does your solution work, if the common license db is kept on a shadowed disk ? Can you mount the disk before loading the VOLSHAD license ?

Volker.

[Jan van den Ende]

@ Volker,

>>>
Does your solution work, if the common license db is kept on a shadowed disk ? Can you mount the disk before loading the VOLSHAD license ?
<<<

Wow, never thought about that one!
We just did it (way back when). Never had any issues with it, it just works, at least since VMS 6.2.
And that common disk _IS_ _NOT_ a system disk, and a 3-member shadow set.

hth

Proost.

Have one on me.

jpe

[Hoff]

The list of files that should be shared or that must be coordinated within a cluster is in the SYLOGICALS.COM file by default (and in the comments over in .TEMPLATE if not), and it's a long one.

There are various such files that can cause weirdnesses if not coordinated, including the queue database, the object security database, and yes the license database.

I've posted up directions on adding or removing nodes to/from a cluster, with some information on how to merge the profiles of existing nodes together, and how to extricate a node from a cluster or downsize a cluster:

http://64.223.189.234/node/169

[John Gillings]

You can work the reason for the display by examining each LMF$LICENSE, counting the units of VMSCLUSTER, then working out the boot sequence to see how many units were loaded and consumed on each node. It's obviously a waste of time, because the bottom line is, an incorrect LDB configuration breaks assumptions that LMF make, and results in non-sensical displays.

Remember that licensing is inherently cluster wide. Make sure that ALL nodes see ALL PAKs for ALL products and all will be fine.

Regarding shadowing... there is some special dispensation for mounting shadow sets early in system startup. You can certainly mount a shadowed system disk with no licenses loaded. I think you may be able to mount a shadowed cluster common disk, providing it's done before the LICENSE START command (so, for example, in SYLOGICALS.COM). Once LICENSE START has executed, shadowing will expect to see VOLSHAD units.

Another option is to keep an LDB on each system disk, but have a "master copy" on your cluster common disk. Make sure LMF$LICENSE points to the common copy at all times, but have your startup propagate a copy to each system disk during system startup (and/or on your normal housekeeping or backup cycle). Normal LICENSE commands will operate against the common copy, but you'll have a complete (and identical) copy to load from if you boot independently of the rest of the cluster.

[Willem Grooters]

So the bottom line is that there shouyld, logically spoken, be ONE license database in a cluster. In this configuration, that holds for the 7.3-2 machines, but the one on the 8.2 machine is a copy of that cluster-wide one so that would be Ok (?).
What may cause the trouble is the expired license on the Itanium (FOA + MCOE).

Question in that matter: If I have different platforms, does the same requirement hold (license database synchronized on alll systems)? Worst case, when each system has it's own license database, it would mean that I would have to install the Itanium licences on all systems - even Alpha.

[Ian Miller.]

You should have one common licence database for all systems. Use the /EXCLUDE or /INCLUDE qualifiers on each PAK so that they are available to the proper nodes only.

I think there are locks (which are cluster wide) created when PAKs are loaded and by having separate licence databases with multiple copies of the same PAKs leads to strangeness.

Having multiple licence databases for the cluster also leads to more work for the system manager and that's never a good idea :-)

[Volker Halle]

Willem,

one (master) LMF$LICENSE.LDB file with all licenses entered is certainly a good idea. You only need to work with /INCLUDE or /EXCLUDE, if there are certain licenses, which are not available for all nodes of the same architecture. VMSCLUSTER licenses should exist for all of your Alphas. For the Itanium system, there would likely be OPENVMS-I64-MCOE, which is an IA64 license and won't be loaded on Alpha anyway. Same for ALPHA licenses on I64.

Volker.