× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, heck, this is a non-starter.  The LICENSE_INFO view (like the WRKLICINF command) shows everything EXCEPT ... <drum roll>... the actual license key.  So now we're battling through the ESS site which of course decided today to suffer sudden onset amnesia  and tell us we have no keys for ANY of our machines.

Hmm.

Is someone trying to tell us something?


On 3/14/2019 1:31 PM, Joe Pluta wrote:
Exactly my plan.  I should end up with a table that looks like the *OUTFILE for DSPLICKEY.

On 3/14/2019 1:28 PM, Rob Berendt wrote:
If saved the output of that service to a different table you could read every row and issue a call to QCMDEXC to redo the ADDLICKEY.
Just wrap your sql statement with
Create table mylib.lickeys as (
<existing sql statement here>
) with data;

This kind of stuff was an inspiration for me to learn SPL.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Joe Pluta
Sent: Thursday, March 14, 2019 1:39 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: DSPLICKEY not showing keys (but LICENSE_INFO does!)

Okay, this is a brand new one for me.  I've got several machines/LPARs.
They have varying combinations of products: HA/replication LPARs should
be the same, and the DEV box obviously has a somewhat different
configuration.  Had some unexpected license messages come up and so I
decided to compare keys.  On one of the LPARs, DSPLICKEY returns CPF9E58
License key information not found.  Now I expect this when looking for a
key that is not there, but with DSPLICKEY PRDID(*ALL) LICTRM(*ALL)
FEATURE(*ALL) I definitely don't expect to see that error; that implies
that there are NO KEYS on this machine!  AHHHHH!  PANIC!

Now I know that the fine folks at IBM continue to provide us with new
services and I wondered if there was one for keys and lo and behold, the
LICENSE_INFO view does just that.  When run on the working LPARs, it
shows me the same information I get from DSPLICKEY.  But on the
misbehaving LPAR, LICENSE_VIEW shows me the keys I expect, even though
DSPLICKEY shows nothing!

So now I'm stumped.  Looks to me like I've got some internal tables
munged up and a call to IBM may be in order.  But before I do that, I
thought I'd reach out to the collective community. Anybody else ever see
something like this?





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.