Wanted: DEC Lisp PAK

From: Andreas Freiherr <Andreas.Freiherr_at_Vishay.com>
Date: Mon Jan 28 13:23:15 2002

Well, license management uses a special logical name table
(LMF$LICENSE_TABLE), so if you are familiar with expanding logical names
and defining new ones, you may find a way to have a license for any
given product name that has the same properties as a license for another
product, for which you have a printed PAK. You will never be able to do
this directly from DCL because there is no DEFINE/KERNEL_MODE
command/option.

There are VMS versions where you can cause a SHOW LICENSE command to
come back with a $STATUS of 12 (%SYSTEM-F-ACCVIO, access violation,
reason mask=...) just by defining an entry to the LMF logical name
table, so I think this may be considered the inside part of LMF =>
nothing to play with while there are other users on the same node /
cluster... (harmless demonstration: try DEF/TAB=LMF$LICENSE_TABLE
LMF$TEST HUGO and then SHOW LICENSE, it ACCVIOs on my 7.1-2;
DEAS/TAB=LMF$LICENSE_TABLE LMF$TEST to restore original behaviour - if
somebody from COMPAQ is listening: this is due to the missing underscore
character, it is probably not really worth an SPR? :-)

Faking a license by fiddling with this name table may make a license
appear to exist for the EXE$LOOKUP_LICENSE and EXE$GRANT_LICENSE
routines, but you will not have a record for this license in your
license database file, so you'll need to do the trick each time your
machine boots, and a LICENSE LIST command will never show this license -
however, a SHOW LICENSE will (if it doesn't ACCVIO... ;-)

(Side effect: if the installation procedure checks for availability of a
license using LICENSE LIST, it will conclude you have no license, and it
may abort.)

I am not saying "go ahead, play with this", I am - of course - only
illustrating the way it works! It wouldn't make any sense to use a fake
license of this kind for production purposes of any kind anyway, but it
might make it possible to run something like your LISP system for
demonstration purposes.

--
Andreas Freiherr
Vishay Semiconductor GmbH, Heilbronn, Germany
http://www.vishay.com
Received on Mon Jan 28 2002 - 13:23:15 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:58 BST