License Info /clarification required

[nipun_2]

Kris helped me out. But I still have a question/confrimation issue as I want to play it safe.

I have XP1000 and DS25 clustered together in a common environment running on V7.3-1 and now I am preparing to add a new node (EV68 DS25 still not booted).

I have the following licenses and units
In the data below (Act== activity table code)
(Ava == availability table code)
(U == Number of units)

1)
OVMS ALPA BASE DS20/DS20E/DS25 LIC ---- Act =A,U= 25units
2)
OVMS/A SMP Asvr1200/DS20 ----Act =A,U = 50 units

3)OPENVMS CONC 1 LIC ---- Ava= CONSTANT 100,U = 100 units

4)NAS CL 150 V/A TRAD LIC --- Ava = H,U = 1050

5) VMSCLUSTER CL V/A TRAD LIC --- Ava = H,U =1050

6) CPQ OPEN3D V/A TRAD LIC ---- Ava =CONSTANT 100,U=100

whew!!!! typed all of them right...


My question:
I saw the current units for DS25 in clustered system it has Type A 25 units,Type H 1050 and Type I 1050. The new (ev68 ds25) doesn't have Type I as you can see above. So I am not sure whether I have the right number of units. I tried to check the online system manager and cluster manuals but couldn't figure it out.


I believe one way to verify (which I figured from your responses ofcourse) to setup the current clustered environment using CLUSTER_CONFIG to add a new cluster. Then do
SHOW LICENSE /UNIT REQUIREMENTS /CLUSTER
and then check. However I do now know right now as to what happens if units are less than required. My concern is that in no way the current system should stop working(for more than 2 hours) while I add the new cluster.

Another question is do I have to reboot the system clustered system after loading and registring licenses or after running cluster_config.com ? I don't think so but do let me know

Again Thanks in advance..

[Volker Halle · Accepted solution]

Nipun,

as you already have a DS25 running, just do $ SHOW LIC/CHARGE on that node and then you know, how much license units each different type of license requires on that type of system.

Type I licenses would be for generic layered products (for usage on both VAX and Alpha).

In an OpenVMS cluster, it would be best to add ALL license PAKs into ONE LMF$LICENSE.LDB file (let's call it master license db file) and then copy that file to EVERY system disk (into SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB). Whenever you add more licenses, repeat this procedure.

This will make sure, that all license information is also homogenous throughout the cluster. The LICENSE LOAD command will check for each license it loads, whether there are enough units available in the license database compared to the units already allocated clusterwide ($ SHOW LIC/USAGE).

Example:

- you have a LMF$LICENSE.LDB file on your system disk with 2x 1050 Units for VMSCLUSTER.

- you boot the node into an existing cluster with 2 nodes already running.

- LMF sees 2100 units in the local license DB and 2100 units already allocated clusterwide, so it won't load the VMSCLUSTER license.

- if you had entered the 1050 units for the 3rd node into the LMF$LICENSE.LDB file on the local system disk, everything would be fine (3150 units in local lic db, 2100 units in use cluster-wide, so it can load the VMSCLUSTER license with 1050 units).

You can load and unload licenses without rebooting using the LIC UNLOAD and LIC LOAD commands.

Volker.

[Jan van den Ende]

Nipus,

Volker wrote:

In an OpenVMS cluster, it would be best to add ALL license PAKs into ONE LMF$LICENSE.LDB file (let's call it master license db file) and then copy that file to EVERY system disk (into SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB). Whenever you add more licenses, repeat this procedure.


An other way to do this (and much more in line with the idea that clusters are to make life simpler):
Make sure your licence database is in a location that can always be accessed by any node, even at times when not all nodes are "up".
$ DEFINE /TABLE=LNM$SYSCLUSTER_TABLE/EXEC LMF$LICENSE

This way you only have to maintain one file, and do not have to copy it around.

Of course, on a single common system disk, you have already achieved this automaticly.
On more reason to use as homogenous a cluster as you possibly can.

Proost.

Have one on me.

Jan