unexpected SHOW LICENSE output

[Willem Grooters]

OpenVMS 8.2

DKWSBU>SH LIC/USA

View of loaded licenses from node DKWSBU 14-DEC-2007 09:38:11.10

------- Product ID -------- ---- Unit usage information ----
Product Producer Loaded Allocated Available
...
DW-MOTIF DEC 1050 1050 0
...
OPENVMS-ALPHA DEC 15 15 0
...
VMSCLUSTER DEC 3150 5250 ***

It makes sense that
Loaded >= Allocated (what I would expect)
and therefore
Available = Loaded - Allocated

But VMSCLUSTER seem to have more allocated than loaded and so available will be < 0 (and be displayed "***".).

How can this license show up having more allocated than loaded - and is the display of "available" intentional?

[Karl Rohwedder]

Are those 'real' licenses? I ask because you may confuse the LMF utility by creating 'fake' licenses by just defining the app. logical names (on alpha) (which of course is totally illegal!)

regards Kalle

[Willem Grooters]

These are real licenses.

IFIAK SHOW LICENSE accesses LNM$LICENSE (and I've seen LMF$CHARCGE_TABLE logical referring to another file). Both refer to just one file on SYS$COMMON.

BTW: LMF$CHARGE_TABLE is new to me. I'll dig the manuals (if any data is available)

[Willem Grooters]

BTW: on a 7.3-2 system in the same cluster, the same command shows loaded = 11050, allocates 5250 and avaliable 5800 - which I would expect.Our guess SHOW LICENSE in VMS 8.2 contains an annoying bug ;). On AXP anyway, on Itanium it looks correct.

[Volker Halle]

Willem,

to get a litle bit more information, try:

$ SHOW LIC/USAGE VMSCLUSTER/FULL

The output will tell you, which node has allocated how many units.

Volker.

[Volker Halle]

Willem,

Units Loaded seems to be the sum of all units from all VMSCLUSTER licenses loaded on this node from it's (local) LMF$LICENSE.LDB.

Does this match on your V8.2 system ?

Volker.

[Willem Grooters]

$ sh lic/usage vmscluster/full

View of loaded licenses from node DKWSBU 14-DEC-2007 12:14:38.91

AVAILABILITY license DEC VMSCLUSTER usage information:
Availability: H
Activity: 0
Version: 0.0
Release Date: (none)
Termination Date: (none)
Units Node
1050
1050 Galaxy System ID: 383353574B44018011DC3C5A79A74200

1050 Galaxy System ID: 544253574B44018011DC3C5A79A74200

1050 Galaxy System ID: 554253574B44018011DC3C5A7AD86F00

1050 Galaxy System ID: 374153574B44018011DC3C5A7A3FFEA5

Units loaded: 3150 Units allocated: 5250 Units available: ***

(All x DS15. The rx1620 in the cluster is not listed)

WG

[Volker Halle]

Willem,

Units Loaded is the local node's view of the license units it is seeing in it's LMF$LICENSE.LDB.

The rx1600 does not have a VMSCLUSTER license, but is probably using OPENVMS-I64-MCOE. SHOW LIC only shows you licenses, which the local node has loaded from it's license db into memory (i.e. logical names).

I can image, that a LIC LOAD VMSCLUSTER on this V8.2 node will fail to load this license with LICENSE-F-EXCEEDED, so don't try it yet...

How do these system access LMF$LICENSE.LDB in this cluster ? Common system disk with just ONE LMF$LICENSE.LDB ? Or multiple system disks with identical copies of LMF$LICENSE.LDB ?

Volker.

[Willem Grooters]

The 7.3-2 machines in the cluster have a common system disk and use the same license database. The 8.2 machine has it's own system disk and it's own database, as well at the Itanium (obviously). Just checked: it has VMSCLUSTER licence (just checked - perhaps the MCOE license is loaded, or FOE and VMScluster of MCOE (or full) both are expired :))

[Volker Halle]

Willem,

did you sum up the VMSCLUSTER units from the V8.2 license database ? What do you get ?

Volker.

[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.

[Willem Grooters]

Found this cluster has 4 license databases:
IA64 has one, two AXP have their own, non-shared, and the remaining three nodes share the same one. The uissue has been exposed to system management to take action: combine them into one, shared by all systems (as well as other files).