Licenses

[Wim Van den Wyngaert]

I have a cluster where all nodes share the licenses via 1 license database. Except 1 node that has a private system disk and thus a private license database.

What is the impact of this ?

Wim

[Karl Rohwedder]

Be carefull, when managing licenses, either login to the correct node or assign a logical accordingly.
Via the logical LMF$LICENSE it would be possible to share a common LMF database even in the case of multiple systemdisks.

Problems may arise for licenses that are clusterwide, e.g. PWLMXXX or VMS user licenses.

regards Kalle

[Volker Halle]

Wim,

I normally suggest to add ALL licenses from ALL systems in the cluster into ONE LMF$LICENSE.LDB file and then copy this file to ALL local system disks. If some licenses are only to be loaded on single systems and not on all systems, just use LIC MOD xyz/INCLUDE=node.

It's my understanding that when loading a license, a check is made for the number of units seen in the (local) LMF$LICENSE.LDB for this license against the number of units already loaded cluster-wide for this product. If more units are already allocated cluster-wide than are available in the license database file, loading the license will fail.

It's possible to point a logical LMF$LICENSE to a common license database, but the question always arises, if the disk, which this file resides on, needs to be mounted as a shadowset, does it work in SYLOGICALS.COM, if the VOLSHAD license is not yet loaded.

Volker.

[Ian Miller.]

"does it work in SYLOGICALS.COM, if the VOLSHAD license is not yet loaded."
Yes it appears to work just fine.
I thought the official recommendation is to have one cluster wide licence database.

Remember just because you can do something with LMF does not mean it is legal to do so.

[John Gillings · Accepted solution]

Wim,
Independent LDBs only work for NO_SHARE licenses (which in practice means only base operating system PAKs).

The rule is simple, ALL nodes in a cluster must see ALL units for ALL other nodes. That's because the loaded licenses are inherently cluster wide. Rather than thinking of each PAK as "belonging" to a particular node, think of it as a contribution to the cluster wide pool.

Assume you have 3 nodes shared and one "private". Consider a product with 100 units required. If you have 300 units in the shared data base and all nodes are up, there are 300 units consumed. Now bring in your "private" node with only 100 units in the LDB. It knows there's a 400 unit cluster wide requirement, but can only see 100 units, so it fails to activate the product.

As it happens, if you boot the "private" node first, it will "work" for the first two shared nodes and the 4th will fail. The danger is you might not notice a boot order dependency like this until just after a failure - precisely what you DON'T need at that kind of panic time.

You can either configure a single, physically shared LDB with all PAKs for ALL products, or you can keep multiple copies of the same LDB, one on each system disk. In both cases, ALL the PAKs are registered in ALL LDBs (binary copies are even better).

There's another option, which I DON'T recommend - you could convert some or all your PAKs to NO_SHARE (see LICENSE MODIFY/NO_SHARE). You then have to have an /INCLUDE or /EXCLUDE list on EVERY PAK!