Operating System - OpenVMS
1748204 Members
3240 Online
108759 Solutions
New Discussion юеВ

Re: LICENSE MODIFY/INCLUD=nodename UCX

 
SOLVED
Go to solution
Clark Powell
Frequent Advisor

LICENSE MODIFY/INCLUD=nodename UCX

In a two node, VMS 8.3 cluster I see this message when I boot. I see it for motif, decnet, ucx, disk shadowing. It seems ambiguous to me. Do I remove the node names from all of the licenses or do I add node names to the licenses that don't have node names? I don't really care either way; both nodes are identical and everything works now. But, I do object to getting this error message when I boot.

%%%%%%%%%%% OPCOM 17-DEC-2009 01:15:45.29 %%%%%%%%%%% (from node ALPHAD at 17-DEC-2009 01:15:44.24) Message from user SYSTEM on ALPHAD %LICENSE-W-LISTIGNORED, combine set for DEC UCX included a PAK without an include or exclude list; other lists ignored

thanks
Clark Powell
6 REPLIES 6
Martin Vorlaender
Honored Contributor
Solution

Re: LICENSE MODIFY/INCLUD=nodename UCX

Clark,

the error messages should disappear either way.

If you remove the nodes from all of the licenses, their units get combined and every booting node takes away as many units as it needs.

If you nail them down to particular nodes, each node will only load the licenses it's included in.

cu,
Martin
John Gillings
Honored Contributor

Re: LICENSE MODIFY/INCLUD=nodename UCX

Clark,

PAKs which don't have the NO_SHARE attribute are inherently cluster wide. When loaded, all PAKs of the same type (availability or activity) for the same product, are combined to derive the total number of units available to the cluster. INCLUDE and EXCLUDE lists are also combined.

In your case, for the products generating this warning, you have at least one PAK with an INCLUDE or EXCLUDE list and another with no list. Since "no list" means "include all" when combined, any other list is effectively overridden. That's what the warning is telling you.

The general rule in a cluster is that all PAKs for the same product should have identical INCLUDE or EXCLUDE lists. You can set it up with:

$ LICENSE MODIFY product/ALL/INCLUDE=(list)

However, with a two node cluster, INCLUDE or EXCLUDE lists are usually redundant. The warning is benign, because licensing is probably doing what you intend, even though your configuration is technically incorrect.

(It's tempting to think of a particular PAK certificate as "belonging" to one node in a cluster, and therefore /INCLUDEing that node on just that PAK. However, that's not how the OpenVMS license model works. A better way to think about it is as that node's contribution to the cluster wide pool. INCLUDE and EXCLUDE are only really useful when a particular product will only be used on a subset of cluster nodes.)

Your most likely solution is to remove all the /INCLUDE or /EXCLUDE lists from all PAKs and let LMF figure it out. (see LICENSE MODIFY/REMOVE).
A crucible of informative mistakes
Steve Reece_3
Trusted Contributor

Re: LICENSE MODIFY/INCLUD=nodename UCX

That sounds like a change to Alpha licensing John. I was aware that it works that way on Integrity (I made that mistake on the first Integrity cluster I built) but with Alpha and VAX licensing models it's always been seen as licenses but exist in all of the license databases but specific licenses should have /INCLUDE lists on them to load a specific license on a specific node.

Following the /INCLUDE pattern on Integrity means that nodes don't get the licenses they want though.

So, has the licensing model on Alpha changed as well?

Steve
Ian Miller.
Honored Contributor

Re: LICENSE MODIFY/INCLUD=nodename UCX

Steve - you should have one licence database for the cluster.
____________________
Purely Personal Opinion
Steve Reece_3
Trusted Contributor

Re: LICENSE MODIFY/INCLUD=nodename UCX

Yes, you should have only one license database but there have been instances in the past where I've needed two.

That doesn't change the fundamental issue though - there is a difference between licensing on I64 and VAX/Alpha in my experience where I64 requires that all of the licenses are available and none have an /INCLUDE or /EXCLUDE list on whereas Alpha and VAX are happier if you do use the /INCLUDE and /EXCLUDE so that the right license is loaded on the right box.

If you use /INCLUDE=nodea on an I64 license it will prevent licenses loading correctly and you'll get rude messages from the license utility telling you that you're not compliant.

The licensing model that John described seems to fit my experience of I64 but NOT VAX or Alpha.
John Gillings
Honored Contributor

Re: LICENSE MODIFY/INCLUD=nodename UCX

Steve,

I supported OpenVMS licensing from when it was introduced in 1988 (V5.0). I've lost count of how many systems I've had to correct over the years, and how many seminars/training sessions/workshops I've given to try and make sure people understand it.

If you have X nodes and X PAKs for a particular product, you can /INCLUDE one node on each PAK. It will "work" as you expect because the combined license just concatenates your INCLUDEs, and all units are loaded on all nodes. The trouble is it encourages you to think about the license model incorrectly.

Having multiple physical license data bases can be done but you have to be very careful. In general they should be identical copies, because the LOADed (active) license data base is irrevocably cluster wide. So, if you have one PAK REGISTERED on node A and another on node B, each will LOAD just what they can see. The first node will succeed, the second will fail because it can't see enough units to cover itself, plus the units already consumed by the other node.

The worst part is you can get configurations which "work" for one particular boot order, but not for others. This is usually discovered at 3am ("but it's been working for years!").

PAKs with NO_SHARE (generally only operating system PAKs) are different. They need a /INCLUDE to limit them to a single node.

The OpenVMS licensing model is somewhat counter intuitive, but once you understand how it works in a cluster, it makes a lot of sense.

The BIG mistake Digital made with licensing was to issue internal PAKs which worked in a completely different manner from those issued to customers. Internal PAKs were unlimited, so they "worked" no matter how they were configured. That meant that the majority of Digital personnel had no idea how licensing really worked, and would regularly misconfigure customer LDBs, or (worse) "fix" a system with temporary or internal PAKs. CSC folk often had to clean up the mess.

In retrospect it would have been far better to "dog food" the mechanism so everyone understood it from the start.

Here are my "Golden Rules" for licensing (at least for VAX and Alpha clusters, IA64 is a whole new ballgame!)

1) ONE cluster, ONE license data base (physical better, otherwise identical copies).

2) ONE product, ONE or NONE /INCLUDE or /EXCLUDE list

3) Beware of group products (like UCX). See SYS$UPDATE:VMSINSTAL_LMFGROUPS.COM. Make sure each node gets its units from the correct PAK.

4) TEST your configuration, both with LICENSE LOAD commands and, if possible, booting in different orders. Make sure SHOW LICENSE is consistent from all nodes.
A crucible of informative mistakes