LICENSE-F-EXCEEDED, attempted usage exceeds active license limits

[Art Wiens]

I have 4 standalone Alpha's (2 - 800's, a 1200 and an ES40 all v7.3-1) that I need to decommission. Basically one final backup that needs to be kept "forever" (the old 7 year rule) and then wipe the disks and haul 'em out. Three of the four have either DAT or a TZ87 drives, the one has a TZ89. I don't think we stand a chance of finding a DAT drive in 7 years so my plan was to "quickly" put the 4 nodes in a cluster and back them all up to the TZ89 (backup via MSCP) which I can use to transfer to SDLT, which should get us at least half way through the 7 years. Worry about the rest at a later date.

All systems retain their own system disk ie. their own license databases. My problem is trying to load existing licenses on existing machines (that load fine when not in a cluster) after I have turned VAXCLUSTER on. I haven't tried all the possibilities, but it would seem that only two nodes at a time can load all their own licenses. I have modified the licenses to /INCLUDE only the appropriate node name even if the license isn't a NO_SHARE style, to no avail.

For example this VMSCLUSTER license:

SYSMAN> do lic list/full vmscluster
%SYSMAN-I-OUTPUT, command execution on node GLBC17
License Management Facility V1.2

License Database File: SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB;1
Created on: 27-FEB-2002
Created by user: SYSTEM
Created by LMF Version: V1.2

-----------------------------------
Issuer: DEC
Authorization: ALS-IL-yyyyMMMdd-1-16
Product Name: VMSCLUSTER
Producer: DEC
Units: 1050
Version: 0.0
Release Date: (none)
PAK Termination Date: (none)
Availability: H (Alpha Layered Products)
Activity: 0
Options: MOD_UNITS, ALPHA
Hardware ID:

Revision Level: 2
Status: Active
Command: MODIFY
Modified by user: SYSTEM
Modified on: 16-JAN-2008 15:44:01.07
Include: GLBC17
[End Of List]
SYSMAN> do lic load vmscluster
%SYSMAN-I-OUTPUT, command execution on node GLBC17
%LICENSE-W-NOLOAD, license was not loaded for VMSCLUSTER
-LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
SYSMAN>

I've rebooted the whole cluster a few times, strange results. Is this somehow the result of too many license databases? The LMF$LICENSE logical is defined as SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on all four systems. 1050 units, Availability H is pretty straightforward.

Ideas please? There's no budget or time to investigate CD/DVD type solutions, nor to build a four root disk, network boot etc. so those are off the table. This was supposed to be "quick"!

Cheers,
Art

[Hoff · Accepted solution]

Since you have legitimate licenses for all of these boxes and you're here chasing a license configuration issue and not a case of trying to do anything not permitted by the licenses you have, crank up the permitted units (using that MOD_UNITS flag), and move along to the next issue.

As for the configuration here, there is a need here to synchronize the PAKs across the files, and to specify /INCLUDE uniformly across the license database file(s) that are present.

There exists an intro to troubleshooting this sort of thing with LMF and license PAKs in the OpenVMS FAQ:

http://64.223.189.234/node/1

and I have several (other) pages on LMF posted up at the web site.

But as LMF is a license management facility and not a license enforcement tool and since you have licenses for what you are trying to do here, just MOD_UNITS it to work around the LMF crankiness, and off you go.

Stephen Hoffman
HoffmanLabs LLC

[Art Wiens]

Duh ...

SYSMAN> do lic modify /units=4200 vmscluster/auth="ALS-IL-yyyyMMMdd-1-16"
%SYSMAN-I-OUTPUT, command execution on node GLBC17
SYSMAN> do lic load vmscluster
%SYSMAN-I-OUTPUT, command execution on node GLBC17
%LICENSE-I-LOADED, DEC VMSCLUSTER was successfully loaded with 4200 units

Can't see the forest for the trees some days ... perhaps because it's -33c and my brain is froze.

Thanks,
Art

[John Gillings]

Art,

Licensing is inherently cluster wide. You can't do much to change that. It leads to "RULE 1" of licensing...

"1 CLUSTER => 1 LICENSE DATA BASE".

Bottom line is all nodes need to see all PAKs for all nodes. You can do that by having a single, shared LDB, or you can have multiple identical copies of the LDB. Although it's possible to hack around that with MODIFY, it's much better to just follow the intent of LMF and stick to RULE 1. The quick and dirty mechanism is to dump each LDB:

$ LICENSE ISSUE/PROCEDURE/OUTPUT=file1 */ALL

then pour them all into 1 LDB

$ DEFINE LMF$LICENSE common_file
$ LICENSE CREATE
$ @file1
$ @file2
...

Now you may need to adjust the /INCLUDEs for NO_SHARE PAKs, then propagate the new LDB around the cluster.

(Replicating all the PAKs on each of your system disks is probably a good thing for backups and redundancy)

You may also want to keep the command procedueres generated above as a further backup of your PAKs - apart from anything else, it's human readable :-)

FWIW - /INCLUDE really doesn't do what you think for shared PAKs. For PAKs which aren't NO_SHARE, all PAKs for the same product across the cluster need to have identical /INCLUDE or /EXCLUDE lists.

On the other hand, if you're a late enough version, you may be able to use MODIFY /NO_SHARE and MODIFY /NONO_SHARE to convert shareable PAKs into NO_SHARE PAKs. In general this is about as sensible as the qualifier name /NONO_SHARE, but you may have a legitimate purpose!

[DECxchange]

Hello,
To cluster all these together, you need the LDB in sys$common:[sysexe] AND each node needs to have its own separate VMScluster license PAK. Since the ES40 may have higher license units requirements, you might have to load each VMScluster license with the /include qualifier, specifying the license with the correct units (not 100% sure about this). Buf for sure, each node in the cluster will need its own VMScluster license as well as VMS base and user licenses.

[Hoff]

From Art in the original post: "Basically one final backup that needs to be kept "forever" (the old 7 year rule) and then wipe the disks and haul 'em out."

Sure, time and effort could be spent resolving the underlying LMF issue, but -- for this case, and given that there are the appropriate licenses in Art's possession -- why bother? Get the configuration running, spin the final DLTs (with /VERIFY, hopefully) before final INITIALIZE /ERASE and box retirement, and try not to freeze solid when you're on the way home (early?)... :-)

[Art Wiens]

Hoff's answer regarding simply just increasing the units per license worked fine. I kept 4 seperate ldb's for the duration of the backups. MSCP worked great! I got two copies on DLT IV, copied the savesets to my HSG80 SAN and backed up all savesets onto SDLT. Should be good.

As said earlier, my "mind froze". We have an awful lot going on right now ... new APC in row UPS and cooling units which means pretty well everything has to move (~400 servers of all sorts and flavours and vintages), new overhead cabling trays (concrete dust has somehow been kept to a minimum ;-) ... we have to take a total datacenter outage to hook up the new power (yikes!) ... a dozen VAX and VAXstations have been migrated to CHARON-VAX, new ES47's being built and then this to cap it off ... "several" VMS systems have to go "now"!

Thanks all for your help! Hopefully I'll get some rest soon.

Cheers,
Art

[Art Wiens]

ps. plus it's freakin' cold ... wind chill warning for -44c tonight. It's a "brisk" walk to the garage for a smoke ;-)

Cheers,
Art