[Info-vax] HP Integrity rx2800 i4 (2.53GHz/32.0MB) :: PAKs won't load

Jess Goodman norebid at gmail.com
Wed Feb 17 23:43:58 EST 2016


On Wednesday, February 17, 2016 at 9:15:00 AM UTC-5, VAXman- wrote:
> In article <c2a7d366-9421-4174-9ef9-92e428f99c75 at googlegroups.com>, Jess Goodman <norebid at gmail.com> writes:
> >On Tuesday, February 16, 2016 at 12:19:54 PM UTC-5, VAXman- wrote:
> >> In article <7s8bpc-a9p1.ln1 at news.chingola.ch>, Paul Sture <nospam at sture.ch> writes:
> >> >On 2016-02-16, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> wrote:
> >> >> Den 2016-02-16 kl. 02:34, skrev Paul Sture:
> >> >>> On 2016-02-15, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> wrote:
> >> >>>> Den 2016-02-16 kl. 00:08, skrev Paul Sture:
> >> >>>
> >> >>> <snip>
> >> >>>
> >> >>>>> The clue is in
> >> >>>>> LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
> >> >>>>>
> >> >>>>> What is happening is that NODE_2 is trying to load license units already
> >> >>>>> loaded by NODE_1.
> >> >>>>
> >> >>>> But, how does NODE_2 even *know* that NODE_1 exists at all?
> >> >>>
> >> >>> The nodes are clustered,...
> >> >>
> >> >> I thought it was quite clear that they was *not* clustered.
> >> >
> >> >Looking at the original message it's not clear either way.  Are they going to
> >> >be clustered together across sites, or is each site going to have its own
> >> >independent cluster?  
> >> 
> >> THey're clustered across a distance for DR.
> >> 
> >> 
> >> >> I'm working with a customer who has 2 HP Integrity rx2800 i4 (2.53GHz/32.0MB)
> >> >> (from $ SHOW CPU output).  Each has a separate system disk because they will 
> >> >> be clustered at disparate sites.  The PAKs on one of the nodes load but they
> >> >> do not load on the other.  I've checked that each node has different/unique 
> >> >> PAKs by authorization numbers.  Listed below:
> >> >
> >> >And the list given does contain VMSCLUSTER licenses, though note
> >> >that both nodes have two of each license (unique Authorization
> >> >values).
> >> >
> >> >
> >> >>                  NODE_1                         NODE_2
> >> >> 
> >> >>  Issuer:         VSI                           VSI
> >> >>  Authorization:  1R-VSI-20150903-00005         1R-VSI-20150903-00007
> >> >>  Product Name:   OPENVMS-I64-BOE               OPENVMS-I64-BOE
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >>  Issuer:         VSI                           VSI
> >> >>  Authorization:  1R-VSI-20150903-00006         1R-VSI-20150903-00008
> >> >>  Product Name:   OPENVMS-I64-BOE               OPENVMS-I64-BOE
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >>  Issuer:         VSI                           VSI     
> >> >>  Authorization:  1R-VSI-20160121-00007         1R-VSI-20160121-00009
> >> >>  Product Name:   VMSCLUSTER                    VMSCLUSTER
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >>  Issuer:         VSI                           VSI
> >> >>  Authorization:  1R-VSI-20160121-00008         1R-VSI-20160121-00010
> >> >>  Product Name:   VMSCLUSTER                    VMSCLUSTER
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >>  Issuer:         VSI                           VSI
> >> >>  Authorization:  1R-VSI-20160121-00011         1R-VSI-20160121-00013
> >> >>  Product Name:   VOLSHAD                       VOLSHAD
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >>  Issuer:         VSI                           VSI
> >> >>  Authorization:  1R-VSI-20160121-00012         1R-VSI-20160121-00014
> >> >>  Product Name:   VOLSHAD                       VOLSHAD
> >> >>  Producer:       VSI                           VSI
> >> >>  Units:          8                             8
> >> >> 
> >> >
> >> >The following error messages on NODE_2 could mean that it's failing
> >> >to load the second of each license, i.e. a bug.
> >> >
> >> >> On NODE_2, a $ LICENSE LOAD returns:
> >> >>
> >> >> %LICENSE-W-NOLOAD, license was not loaded for OPENVMS-I64-BOE
> >> >> -LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
> >> >> %LICENSE-W-NOLOAD, license was not loaded for VMSCLUSTER
> >> >> -LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
> >> >> %LICENSE-W-NOLOAD, license was not loaded for VOLSHAD
> >> >> -LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
> >> 
> >> I've been having an email discussion with Clair Grant WRT this issue.  It's
> >> NOT a simple issue of having to use /INCLUDE.  It's an issue that VSI have
> >> been looking into already and, as Clair said in email, "what a coincidence 
> >> - your issue and the problem we have been looking into."
> >> 
> >> Hang tight, I've confidence that they'll suss out the issue and correct it.
> >> 
> >> -- 
> >> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
> >> 
> >> I speak to machines with the voice of humanity.
> >
> >Been there - done this (YMMV):
> >
> >$ LICENSE MODIFY xxxxx /AUTH=yyyyyy /NO_SHARE /INCLUDE=zzzzz
> >
> >Jess
> 
> Separate system disks, separate .LDBs.  The remote node (NODE_2) could NOT be
> loading any of the PAKs on the local node (NODE_1).  I believe I stated some-
> where that /INCLUDE did nothing.
> 
> -- 
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
> 
> I speak to machines with the voice of humanity.

Brian,

Take another looK:

$ LICENSE MODIFY xxxxx /AUTH=yyyyyy /NO_SHARE /INCLUDE=zzzzz

The /NO_SHARE qualifier is the key, but you must also use /INCLUDE or the license wtll not load:


%LICENSE-W-NOINC, INCLUDE list must specify exactly one node for xxxx to be loaded

YMMV,
Jess



More information about the Info-vax mailing list