Conference hydra::axp-developer

A software vendor has a symbiont with an availability-based license PAK.
It starts fine, but if the node on which the queue is running fails, the
license doesn't become available.  The next available AUTOSTART queue fails
(since the license wasn't freed).

They say that they have to restart the crashed node and unload the license.

This sort of eliminates the benefit of AUTOSTART queues :-(

Q:  What needs to be done to make the license available when the crash occurs?

The vendor didn't say what version of OpenVMS.
								-- Chuck Newman

Erik --

I'm told that licenses are automatically freed up on when nodes crash.

Please provide the following:

1)  Version of OpenVMS and type of hardware.

2)  LMF command used to register the PAK and the failing PAK
    You need not include the checksum.

3)  The name of the LMF database file which contains the PAK.

Please reference this call number (1997-3453) and my name for
this particular problem.


							-- Chuck Newman

Here's his MAIL, followed by my MAIL
--------------------------------------------------------------------------------
Date:	 9-APR-1997 14:42:56.06
From:	SMTP%"[email protected]"    9-APR-1997 14:41:14.03
To:	[email protected]
Subj:	call number (1997-3453), Chuck Newman

>I'm told that licenses are automatically freed up on when nodes crash.
>
That's what I thought, too.

>Please provide the following:
>
>1)  Version of OpenVMS and type of hardware.
>
VMS 6.1, AXP and VAX.  The problem does not appear to be unique to any
hardware configuration.  

>2)  LMF command used to register the PAK and the failing PAK
>    You need not include the checksum.
>
The license was registered via the license utility, VMSLICENSE.  When the node
was shut down, and the license did not free up, the node was brought back up,
and the following command was used to unload it:

$ license unload <product_name> /producer=northlake

A window was then brought up on the node in which the licenses needed to be, and
the following command was issued:

$ license load <product_name> /producer=northlake

Nothing out of the ordinary...Now, for the PAK (from license list /full).
Note the INCLUDE values.  I thought that adding this would help free the 
license up when the node was shut down, but it made no difference...

 License Management Facility

 License Database File:       SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB;1
 Created on:                  24-APR-1990
 Created by user:             SYSTEM
 LMF Version:                 V1.0

 -----------------------------------
 Issuer:                      NORTHLAKE
 Authorization:               L311-0000
 Product Name:                XSOP
 Producer:                    NORTHLAKE
 Units:                       1
 Version:                     2.1
 Release Date:                (none)
 PAK Termination Date:        (none)
 Availability:                 000000001
 Activity:                    0
 Options:
 Product Token:               NORTHLAKE.INTERNAL.SERVER.XSOP
 Hardware ID:                 XTJMPVPON

 Revision Level:              2
 Status:                      Active
 Command:                     MODIFY
 Modified by user:            ERIK
 Modified on:                 25-MAR-1997 16:00:18.52
 Include:                     DON,LES

>3)  The name of the LMF database file which contains the PAK.
>
SYS$SYSTEM:LMF$LICENSE.LDB, as seen above.

>Please reference this call number (1997-3453) and my name for
>this particular problem.
>
>                                                        -- Chuck Newman

Let me know if you have any questions.  Feel free to call me at 503-228-3383.
If the output of LICENSE LIST /FULL is not good enough, I can fax a copy of
the actual license PAK to you.  The relevant values are:

        Number of Units: 1
Availability Table Code: CONSTANT=1

Kind Regards,
___________________________________________________________
Erik Voldengen                           Northlake Software
[email protected]                             http://www.nls.com
                                         503.228.3383
                                         503.228.5662 fax
--------------------------------------------------------------------------------
Here's my MAIL, preceded by his MAIL
--------------------------------------------------------------------------------
Erik --

Thanks for the information.  A couple more items for clarification:

1)  Please enter the following command on each node in the cluster:

$ DIRE/NOHEA/NOTRA SYS$SYSTEM:LMF$LICENSE.LDB

I see from your MAIL that the system on which you ran "license list /full" had
this file in SYS$COMMON:[SYSEXE], but please verify that all nodes in the
cluster are using the same license file.

2)  You say:
        A window was then brought up on the node in which the licenses
        needed to be, and the following command was issued:

        $ license load <product_name> /producer=northlake

What happens if you load the license on one node and (try to) start the queue on
a different node.  This will tell whether or not its relevant that nodes are
failing, or just that the licenses was loaded on a different system from the one
where it is used.

                                                                -- Chuck Newman

Date:	11-APR-1997 12:13:58.00
From:	SMTP%"[email protected]"
Subj:	Re:  call number (1997-3453)
To:	[email protected]

>Thanks for the information.  A couple more items for clarification:
>
>1)  Please enter the following command on each node in the cluster:
>$ DIRE/NOHEA/NOTRA SYS$SYSTEM:LMF$LICENSE.LDB
>
From node DON:   SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB;1
From node LES:   SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB;1

>I see from your MAIL that the system on which you ran "license list /full" had
>this file in SYS$COMMON:[SYSEXE], but please verify that all nodes in the
>cluster are using the same license file.
>
Yes, they are using the same license file.

>2)  You say:
>        A window was then brought up on the node in which the licenses
>        needed to be, and the following command was issued:
>
>        $ license load <product_name> /producer=northlake
>
>What happens if you load the license on one node and (try to) start the queue on
>a different node.  This will tell whether or not its relevant that nodes are
>failing, or just that the licenses was loaded on a different system from the one
>where it is used.
>
>                                                                -- Chuck Newman

If the license is loaded on node DON, and a queue is configured such that the
symbiont will run on node LES, it will not start due to no license being
available.  The license is an availability license, with the availability
table code set to CONSTANT=1, and the units set to 1.  This will allow
the license to be loaded on a single node only.  So it is expected that the
queue won't start on node LES.  The problem is the license doesn't unload when
the node is shut down.  So if we had queues running on node DON, and DON
crashes, we would not be able to start any of the queues until this node was
brought back up, and we either restarted the queues on that node, or unloaded
the license so we could load it on node LES.   

This brings up an interesting question - if the license did unload from a node when
it was shut down, would our problem be solved?  Say node DON goes down, and the
license unloads.  If the queues are set up as AUTOSTART queues, they will
immediately try to start on node LES.  Will VMS know to load the license on LES
on it's own, or will it need to be done manually?

Perhaps we are generating this type of license incorrectly.  I've been checking
out the LMF and the License Management Utility docs, but I'm not finding what
I'm looking for.  What we want (and thought we had) was a license PAK that
allowed the symbiont to run on a single node of a cluster, and would work with
failover.  That is, our customers could use this license on a cluster, and have
their queues be AUTOSTART queues.  

Your help is very much appreciated.

Kind Regards,
___________________________________________________________
Erik Voldengen                           Northlake Software
[email protected]                             http://www.nls.com
                                         503.228.3383
                                         503.228.5662 fax

Date:	11-APR-1997 15:11:44.60
From:	SMTP%"[email protected]"
Subj:	Re:  call number (1997-3453)
To:	[email protected]

>I think you want an ACTIVITY pak that can be loaded onto all members of a
>cluster rather than an AVAILABILITY pak.

What we want is a license PAK that will allow unlimited processes (queues)
running on a single processor.  If we went with an ACTIVITY license PAK, it
would require us to limit the number of processes (the UNITS number), or allow
unlimited processes running on ALL nodes in a cluster.  We offer customers
ACTIVITY based licenses that do just this, but we also offer a single processor,
unlimited queues license.  

If it is possible to generate an ACTIVITY license that limits use to a single
processor, and unlimited processes, I'm all ears.  From what I know, this isn't
possible - we need an AVAILABILITY license.  

So I guess we've taken a step backwards.  Could you address the
comments/questions from my previous email?  Again, your help if greatly
appreciated!

Kind Regards,
/sig 

LMF V1.2 has a new license type I called a USER license, which could
probably be used for this purpose.  Business reasons, however, have
precluded engineering to create a new PAKGEN that can create this type
of license.

The concensus is that current licenses can't do this without some more
work (e.g., programming with the lock manager, changing queueing, etc).

I'll wait until I hear from Erik STAR::ABIS what I can say about USER licenses,
then I'll compose a final note.

								-- Chuck Newman

Date:	14-APR-1997 14:20:25.69
From:	STAR::ABIS "The early worm gets eaten  14-Apr-1997 1410 -0500"
Subj:	RE: VMSNOTES Note 437.7 re:  User type licenses
To:	HYDRA::NEWMAN

I don't mind you passing this info on.  The new USER license is [poorly]
documented in the V7.1 License Management Utility Manual so it's not a secret.

I had long ago proposed a new release of PAKGEN.  Perhaps if more customers
asked for it, Digital may come to the conclusion that the investment is
worthwhile.

Eric

Erik --

I've discussed this with engineering, and there appears to be no way to get what
you want with the current PAKGEN product and no product modifications.

From your MAIL, I imply that you are seeing the following happen:
1)  System manager loads license from node A
2)  Product works on node A
3)  Node A fails
4)  System manager attempts to load license on node B, but is unable to do so
    because LMF says that the license is already loaded on node A.
5)  System manager boots node A
6)  System manager unloads license from node A
7)  System manager loads license from node B
8)  Product works on node B

If you are seeing this, please send a log showing this.  Until then, I'll assume
I've deduced something incorrectly.



Here are some options, in no particular order.  Feel free to use these ideas to
implement a solution.

1)  Changes to PAKGEN.  LMF V1.2 (shipping with VMS 7.1) has some features that
could be useful to this application.  Unfortunately, many of these features are
currently unusable due to Digital Business restrictions.

Whatever solution is chosen, LMF alone can't make this work.  Additional code
must be added to the customer's product to make them work.

LMF V1.2 has a new license type I called a USER license that allows unlimited
use to a user.  Then when that user is done using the license, the license is
then automatically available (like a failover) to another user in the cluster.
Unlike the currently available personal use license, the new USER license
doesn't have to manually assigned via a reserve list to a specific user.

For this queueing product to use this license type, it would have to pass in the
name of the node it's running on into the LMF during its license check. LMF
would then allow unlimited use on that node.  In this situation, we would size
the license for just one node (user) and you would have your ideal solution.

Unfortunately, since the Digital Business folks didn't want to do the work
required to offer this type of license, only Digital can generate the USER type
license PAK.  For third parties to use this license type, a new release of the
PAKGEN product.  There are no plans to do this.  Feel free to submit a Request
SPR to ask for this.  Customer demand is likely to be the only thing that will
get this to happen.


		(I suspect that this would require your customers
		 to upgrade to V7.1 -- Chuck Newman)

2)  A possible (untested) hack would be to change the print queue so that
    it does not autostart but to create a batch queue that does autostart.
    The sole permanent job on the batch queue would load the licence and
    start the real printer queue on the current node (and then wait for the
    system to crash). The batch job would need to be restartable.

3)  Before doing the license check, his stuff could attempt to load the license.
    If the license load fails, it would just exit.  As long as there is valid
    license on the cluster, one of the systems should be able to load it and
    start up.

3b) Reasonably creative. Does LMF give an interface for loading licences?
    Was the customer intending to SPAWN the LIC LOAD? I would suggest
    ignoring the result of loading the licence and just try to grab it. In
    this case, the AVAILABILITY licence would be appropriate.

4)  The software could start a queue on every node, and do the following:
    1)  Do some T.B.D. locking stuff
    2)  Do license check
    3)  If failure, do locking stuff so that it will get notified when
            a functional (i.e., passed license check) queue fails.
    4)  If success, go to town.

5)  Another option would be to introduce a master process of which there is
    zero or one per node - one when failover to that node occurs. Any
    symbionts would ask the master process whether the licence was OK. The
    master process could itself be implemented as a symbiont so that it
    failed over with all the others. In this case, the ACTIVITY licence
    with units enough for one concurrent activity would be appropriate.

								-- Chuck Newman