license keys

[SCC_2]

Hello,
I was wonder, is there anyway to find out keys on my 3100 system. I ran the lic management and it show me the product and authorization example line SSU ,ALS-KA-XXXXX-XX and also 3 sets of Vax-vms lic AlS-KA-XXXXX-XX.

I try to create a licence_pak.com file and I can create one for the dvnetend and one for SSU, both give me the same information like above but this time it also show the checksum #. What is this number for ?. And when I try to create a licence_pak.com file for the Vax-vms, it don't allow me, it say ..
%license-w-ambig, information provided was ambiguour, multiple licenses was found for Vax-vms.

The reason I have to try this is. On other post. I post I have a dead Hard drive for my Micro Vax II (another system). I am lucky I still can recover more of my the data, but the disk was mark as write protection. So I have to init/erase the disk before I install the image backup in. I was worry if something go wrong, how can I recover the licence for my Vax and other licence pak like fortran.EXE and dibol.EXE and the Vax-vms for that system. I still have the orginal tape from Digital but no pak key.
Thanks !
SCC

[Uwe Zessin]

The license checksum is a guard against typing errors - if one mistypes some license information, the checksum makes sure this error does not go by undetected.

Most likely the VAX-VMS licenses are intended for several machines and have the NO_SHARE attribute (it's been some year that I have worked with a VAX). You should be safe for now if you use the one with the highes unit number.

You should be able to copy the entire LMF$LICENSE.LDB file and re-use it on the new system, provided that it is not currupted, but regenerating the PAKs is still a good idea. Store them in a safe place.

[comarow]

Yes, you can generate a new pak from an old pak, but it disables the existing pak. That command was made to move licenses from one machine to another. Few realizes it disables the existing license.

It is so important to keep your license. Even if used to trade up.
I find it best to create a com procedure to install and create the licenses. Then if the file becomes corrupt, you can simply run the file and recreate the license data base.


But as stated earlier, save the license database file in a safe place.

[Eberhard Wacker · Accepted solution]

Licenses, a wide area of unwelcome issues (for the customer ;-)

The checksum is not only for integrity reasons it is also a kind of marketing instrument.
As a normal user and systemmanager you are not able to produce your â ownâ license so if the license has a termination date built in then you cannot simply change this.
Besides the lifetime restriction of licenses from (now) HP for test purposes itâ s the business trick of some third parties to let you pay for the service of their products on a continous way even if you are not interested in support or updates (but still need the product itself).

Saving the information of your environment:
1.) Copy your license database file LMF$LICENSE.LDB to another directory.
2.) Make a license issue with /database=newdev:[newdir]lmf$license.ldb and print it out.
3.) Delete the copy and copy the original file again (just to be as fast as possible)
4.) Make a license issue with the /data=â ¦/proc=â ¦/out=â ¦ qualifiers to produce a DCL procedure
5.) Delete the modified copy and copy the original file again

Now you have a print-out, the original license database (without any internal modification), an online backup copy and a procedure to rebuild the database.

Two additional remarks: define the system-wide logical LMF$LICENSE and you can access a valid license file independent from its location and the way you named it. Useful e.g. when having several system disks in a cluster. And defining the logical only for your process is a way to avoid the use of the qualifier /data=â ¦ in the various DCL commands.

Now the point of moving licenses from one hardware to another:
- if not made in agreement with HP this is not a valid way as far as I know
- I do not know how it is at all if you do not have a service contract
- moving from VAX to VAX is possible but depends from the license charges (hardware related, needed units), if there is no option MOD_UNITS in the license you may have no chance (typically regarding the base licenses)
- using a license on VAX and Alpha too is only sometimes

[Eberhard Wacker]

possible

Cheers
EW

[Antoniov.]

Hi SCC,
%license-w-ambig means you don't put all pak informations.
It's better you find old original paper pak.

Antonio Vigliotti

[Karl Rohwedder]

If you did an LICENSE ISSUE VAX-VMS command and you received the ambigous message, you must supply more information to the ISSUE command, esp. /AUTH=... to exactly specify which license to issue. Do a LICENS LIS/FUL vax-vms to gather this information.

regards Kalle

[Antoniov.]

to be sure issuing all informations you can use @SYS$UPDATE:VMSLICENSE.COM

Antonio Vigliotti

[Bart Zorn_1]

There is no need for step 3 in the procedure described by Eberhard.

You can use the LICENSE ISSUE command multiple times, regardless if the PAK is disabled or not.

Regards,

Bart Zorn