Conference vaxaxp::alphanotes

   Which OpenVMS Alpha version?

   PAKs with 1 unit should load fine -- I'd not expect the `load'
   routine to check this, as there may be cumulative PAKs, etc.,
   loaded, hence any check implemented in the load routine might
   (incorrectly) fail. 

   It's the run-time check that should catch PAKs with insufficient
   units.  If the run-time check is allowing this PAK, then it looks
   like there's a low-level (QAR-able) bug in the license lookup.

   And as you've mentioned, LMF is a license *management* tool,
   not a license *enforcement* tool.  There are things that LMF
   will allow that the standard Terms & Conditions will not...
   (This is legal hair-splitting, I know...)

   [OpenVMS questions are better suited to VAXAXP::VMSNOTES.]

    Thanks Steve for the reply. Sorry, I forgot to specify versions.
    I have tried it on 6.1 and 6,2-1H3.
    
    I don't understand this as I would have thought that if there is
    a requirement for say 400 units for type A then unless there was a pak
    or paks that have 400 or more units then I would not expect it to load.
    
    The customer's exact scenario is that they had upgraded their
    processor which peviously had a unit requirement for type A of 100
    units and now the requirement is 500 units and were issued with a 400
    unit pak which gives them the cumulative total of the required 500
    units.  However, they can't figure why the upgraded processor is
    working fine because they haven't even registered the additional
    license.
    
    Royston 

:    I don't understand this as I would have thought that if there is
:    a requirement for say 400 units for type A then unless there was a pak
:    or paks that have 400 or more units then I would not expect it to load.

   In most cases, I'd expect this too...  I know that the OpenVMS
   licensing checks are a little weird, given the environment that
   these checks must run in...  And as mentioned, this looks like a
   low-level QAR.

   (And as mentioned, just because LMF allows something doesn't mean
   that the act complies with the terms and conditions....)

    re .2
    
    You would expect that VMS would come up regardless of whether there
    were sufficiently registered licences in order that you can register
    more licences!
    
    One might expect some diagnostics to be issued about this during
    startup and one might expect a degraded mode that only allows system
    management but licensing was not meant to be understood by mortals.

    Normal, expected behaviour...
    
>    management but licensing was not meant to be understood by mortals.
    
    I find this quite easy to understand (full explanation below). The
    basic problem here is not "mortals" vs whatever else, it's that Digital
    internal PAKs work in an entirely different manner from real customer 
    PAKs, so very few employees ever figure out how licensing really works.
    Try running with real licenses (if you can obtain them!) for a while,
    or look at some customer problems, you'll learn quite fast! ;-)
    
    
    PAKs come in 2 basic flavors - AVAILABILITY and ACTIVITY.
    
    AVAILABILITY PAKs are "all or none", use of the product is either
    allowed or disallowed. Therefore, the number of units is tested at the
    time the PAK is loaded. If there are sufficient units visible in the
    LDB to cover any existing cluster members, plus the prospective new
    node, then the PAK is successfully loaded and use of the product is
    permitted. If not, the error "LICENSE-F-EXCEEDED,  attempted usage
    exceeds active license limits" is issued at the time of the LOAD
    command and the PAK is not loaded.
    
    ACTIVITY PAKs work on "usage" of the product. Exactly what the
    definition of "usage" and how and when it is charged and how to deal
    with insufficient available units is entirely up to the application.
    LMF will therefore always load whatever activity units it finds in the
    LDB, and leave unit testing up to the application code. IMHO, this is
    precisely the way it should be. Consider the situation in a cluster. A
    user on node A is currently using product X, thereby consuming N units,
    at the same time as node B is attempting to LOAD the PAK for X. If node
    B checked for sufficient units at LOAD time, it would conclude there
    were insufficient units for the product and refuse to load the PAK. A
    millisecond later the user returns the units.
    
    
    Now, as to this system "working". It will boot fine. If you have
    sufficient interactive user licenses, you'll even be able to login,
    but you'll find that your "courtesy system management login" won't
    work, because the login won't be able to use the activity units from
    your OPENVMS-ALPHA PAK. Is it legal? No.
     
    						John Gillings, Sydney CSC
    

   I wrote up some documentation years back that mapped LMF processing
   to the then-current variants of the 2-5-2 part numbering scheme, and
   had code for the programming calls, etc.  (It's somewhat dated, but
   I can mail copies to anyone that is interested.)

   In addition to what John mentions, one also has to look at the NAS
   group tables, as these can enable products you do not necessarily
   have a specific license for.

    re .5
    
    Granted that I as an (unofficial) internal system manager don't see a
    lot of real PAKs but something doesn't gel.
    
    The description in .0 suggests that the system requires a certain
    number of units to load period i.e. is expecting a capacity licence.
    Isn't that what SH LIC/CHARGE shows i.e. the number of units for each
    availability type on the machine executing the request?
    
    Or do we now support activity licences where the required units (per
    activity) depends on the machine type?
    
    Perhaps .0 needs to post the PAK - without checksum of course.
    
    P.S. What is "VAX/VMS F&A Server"? (type B)

>    Or do we now support activity licences where the required units (per
>    activity) depends on the machine type?

  As .0 says, this PAK has "ACTIVITY TABLE CODE=A". These are the "standard"
  type of PAK for Alpha systems today. Here's an example:

 Issuer:                      DEC
 Authorization:               ALS-SN-94031-3073
 Product Name:                OPENVMS-ALPHA
 Producer:                    DEC
 Units:                       12
 Version:                     0.0
 Release Date:                (none)
 PAK Termination Date:        (none)
 Availability:                0
 Activity:                    A (VAX/VMS Capacity or OpenVMS Unlimited or Base)
 Options:                     NO_SHARE

  On a system with a LURT of 12 for code A, this PAK would allow 1 login
  (which is, legally, your "courtesy system management" login). Other users
  would then be covered by interactive user licenses. Since it is now "normal"
  for systems to have user based licenses, the majority of systems are
  licensed this way.

  Now, there *is* a small issue here. Under normal circumstances, the
  first login will take units from the OPENVMS-ALPHA license, and subsequent
  logins will take from the OPENVMS-ALPHA-USER (or equivalent) license.
  The license check therefore accepts "insufficient OPENVMS-ALPHA units" as
  meaning "go check OPENVMS-ALPHA-USER". So, if there were no OPENVMS-ALPHA
  license loaded, a login will fail with "No license is active for this
  software product". With any OPENVMS-ALPHA license loaded, even one with
  less units than the activity table code requires, the login will succeed,
  provided there are sufficient interactive user units available.

  I think this falls into the "LMF is not a policeman" catagory.

> re: "VAX/VMS F&A Server"

  It's a "file and application server". Take a VAXstation 3100, remove the
  keyboard and boot it. It's a VAX only catagory. Under the new licensing
  model, a server is simply a system with no interactive user licenses.

						John Gillings, Sydney CSC