|
On 10/01/2007, at 9:16 AM, Dave Murvin wrote:
I am not currently using the Request License and Release License APIs.
That explains why the grace expiration date is never set.
Since I was originally creating a temporary demo license at product installation time, I have been using the Retrieve License Information (QLZARTV) API and checking the returned license expiration date versus the current date myself.
How do you ensure that additional demo licences are not created simply by reinstalling your product?
I looks like the QLZARTV API does not update the usage counts for the grace period, so the product license will always be valid using my current method and the grace period.
QLZARTV just returns the current information. It doesn't change or update anything. The only way to get the grace period counts updated is to make a licence request that caused the grace period to be entered. That is, by exceeding the available usage.
I will look at changing the license check process to be one of Request License (QLZAREQ) and Release License (QLZARLS) instead of just checking the expiration date of the license.
If you're only trying to verify the licence is valid then call these APIs sequentially, otherwise you should hold the licence until finished with whatever function your product does and then release it.
Then again, I may go back to creating the demo license in the post install exit program and product installation time, then deleting the license creation programs from the product library.
You could do that but I still think it unsafe from a product protection perspective. You really should not ship licence generation code with the product.
What happens if there is a job blowup (not with my code of course ;)) and I don't get a chance to release the license?
You ought to include invocation exit programs to ensure licences are properly released in the event of abnormal failure.
Would it be released automatically at signoff time or would it stay active for the license?
*CONCURRENT and (I think) *PROCESSOR licenses are released when the job that requested the licence use ends--although your code should release them explicitly by calling QLZARLS.
*REGISTERED licences are not released except through QLZARLS. Details specified on the release must match those specified on the request.
By the way, do you have a good source for more details about how the Software Product APIs work besides the API manual and possibly the System Manager Use manual, or is it just the School of Hard Knocks?
Those two manuals are the official documentation. The API information tells you WHAT but not WHY or HOW. The System Manager Use manual tells you some of WHY. The HOW is pretty much up to you to determine. There is another document Bruce Vining sent me that is intended for developers using the Software Product APIs. It is fairly brief but does answer a couple of items not fully addressed in the manuals. All three sources of information are somewhat incomplete and experimentation is necessary to determine the real behaviour. For example, the installation exit programs receive 22 parameters but not all of them are set to usable values depending on why they are invoked (e.g., *BEFORE or *AFTER either of *RSTCODE, SAVCODE, DLTCODE, and CHKCODE, or *RSTLNG, SAVLNG, DLTLNG, and CHKLNG). There is no documentation stating which values will be set for each combination. Another example is case sensitivity in path names for PTFs which can screw up the supersede chain.
You could ask Bruce if you're eligible for a copy of the Licence Management Guidelines document.
Bruce Vining was also a great help getting stream file PTF support working on VRM440 where the required code did not match either the structures in QSYSINC nor the description in the API reference. He also answered numerous questions about counting usage across LPARs.
Like most things the devil is in the detail. It is easy enough to use the APIs and official documentation to create and package products and add licensing information. Doing so in a manner difficult to circumvent or being able to anticipate potential problems is another thing entirely.
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software OS/400, i5/OS Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
