Conference iosg::all-in-1_v30

    I've removed the kit location from .0 at the suggestion of a fellow
    moderator, who will be replying to this note shortly.
    
    Please don't post the kit locations in this conference!
    
    Thanks,
    
    Graham

    
    	Thanks Graham. No big deal about the kit locations, its just
    	that the whole system you used to get the location has been
    	set up to track who is pulling kits, and you bypass that by
    	posting kit locations.
    
    	Now on to your problem. The book states that your V2.4 license
    	is valid for V3.0. Well that is because the book is written for
    	customers and not DEC internal. For internal sites (I assume you
    	must be internal if you're using the network kit) the PAKs in
    	VTX have release date one year after you request the PAK. That
    	means you can install and use any version of the software released
    	before that date. (Not to be confused with license expiry dates).
    
    	Anyway, to cut a long story short, you, as an internal user, need
    	to pull a new PAK from VTX. The PAK you have is out of date.
    	A fresh PAK will allow you to install and run V3.0 as long as you
    	like (but you might need to pull another license to install/use any
    	possible future releases).
    
    	Customers don't have to do this, their PAKs don't have release
    	dates, so the book is correct.
    
    Regards,
    Paul

I'm still getting the same error, even after following the instructions in .2.  
The log file for the installation can be copied from SISDA::SISDA$PUBLIC:A130.LOG
if you want to see it.

Could something else be causing the problem?

RAM

    If you are using a Software Update Pak, which was supplied with V2.4
    Kits and it has a release date of 01-JAN-1991 then the V3.0 PC option will
    give you this -INVALID date message.
    
    This will also apply to our customers who have installed the V2.4 SUP.
    
    What you need to do is disable the SUP licence
    $LICENSE DISABLE/AUTHORISATION= <number> ALLIN1
    
    Then install your "proper" PAK
    $@SYS$UPDATE:VMSLICENSE
    
    When the command asks if you wish to load this PAK, say NO.
    
    Then unload the PAK you previously DISABLED
    $ LICENSE UNLOAD ALLIN1
    
    Then load your "proper" PAK
    $ LICENSE LOAD ALLIN1
    
    Hope this helps.
    
    cheers
    Jack C.
    Bristol SPS
    
    ps.  and it's allowed me to say in my own dialect, ALLIN1 !
    

    
    	I would recommend doing LICENSE DELETE instead of DISABLE if
    	your LICENSE command understands DELETE (VMS V5.5 or LMF V1.1 kit
    	installed).
    
    	Your log doesn't show much except that you have both an old
    	capacity license ALLIN1 and an old personal license ALLIN1-PERSONAL
    	loaded. If you have more problems please either post the results
    	of, or if it is too long, provide pointers to the results of, the
    	following commands:
    
    	$ SHOW LICENSE ALLIN1*
    	$ LICENSE LIST ALLIN1*/FULL/OUTPUT=X.TMP
    	$ TYPE X.TMP
    
    	(Notice for notes police, this will be okay because the checksums
    	will not be listed so no-one can copy the PAKs)
    
    Regards,
    Paul

	We had the same problem as reported in note .0 and made several
	attempts to load in new licences. It didn't matter how many times I
	ran sys$update:Vmslicense to remove the ALL-IN-1 V2.4 licence(it had 
	some real good statuses(sp) such as even extinct associated with it) or
	when I tried all the various options from DCL, whenever I did a $Show 
	License ALL-IN-1, it pointed to the old one. So we decided to go for a
	new LMF database file, loaded in the new ALL-IN-1 license and rebooted
	the system. Sho Lice ALL-IN-1 now recognises the correct pak and more
	importantly, the upgrade does too. Luckily our IS have a magic little 
	command file to allow us to remove those offending licences, we're not
	running VMS 5.5 yet.

	Now the kit we have here is not a network kit and the license is a
	temporary one from the CSC. Its possible that the PAKS from VTX would
	worked if we had used the above procedure. Quite possibly this will
	affect other inhouse upgrades so be warned...I just hope Paul is
	correct in thinking it wont affect our "external" customers.

	Regards,

		Se�n

    
    	Yes, several people seem to have a problem with getting rid of
    	those pesky licenses. I don't like running Vmslicense.com because
    	I don't know what it does. It sounds like it doesn't LICENSE UNLOAD
    	any loaded licenses which would cause the problem you are having.
    
>	Luckily our IS have a magic little 
>	command file to allow us to remove those offending licences, we're not
>	running VMS 5.5 yet.

    	LMF engineering claim that these "little command files" have been
    	known to corrupt the LMF database. They recommend you get hold of
    	the LMF011.% kit and install it on pre-V5.5 systems. This gives
    	you the LICENSE DELETE command, among other things. The
    	installation takes about 5 minutes.
    
>	I just hope Paul is
>	correct in thinking it wont affect our "external" customers.
    
    	So do I! :-) There was a long discussion about this date thing, and
    	we decided it should be implemented as per the SQM/LMF rules which
    	is why the date changed. Any licenses which are now invalidated
    	should have been sold under special conditions (we don't normally
    	sell these "restricted" licenses) and per LMF rules they should
    	not allow you to run a newer version. I just do as I'm told... :-)
    
    	By the way, what's a SUP?
    
    Regards,
    Paul

    This issue has been inactive for a while, but I thought I would throw
    in my 2�.  I heartily recommend installing V1.1 of LMF to get the
    delete command, but even if you don't, this is what works for me:

    $ LICENSE UNLOAD ALLIN1
    $ LICENSE LIST ALLIN1/FULL

    If only one shows up, use:
    $ LICENSE DISABLE ALLIN1

    Otherwise use
    $ LICENSE DISABLE ALLIN1/AUTH=first_number_from_screen
    $ LICENSE DISABLE ALLIN1/AUTH=second_number_from_screen

    With LMF V1.1,  you can then do:
    $ LICENSE DELETE ALLIN1/AUTH=first_number_from_screen
    $ LICENSE DELETE ALLIN1/AUTH=second_number_from_screen

    In either case use:
    $ LICENSE LIST ALLIN1/FULL

    You should then see one or more licenses with a status of DISABLED or
    no licenses at all if you used V1.1

    Then, finally

    $ @PAK.COM ! The new one you got from VTX

    This will load the new one.  


    Unfortunately, LMF loads the first one that it sees, and has no idea
    that this product release business is a problem, so it just goes ahead
    loads your bad one if you don't disable or delete it first.

    All this holds true for all products; it's not just ALL-IN-1.

    Ben