RE: DSPLICKEY not showing keys (but LICENSE_INFO does!)

Reading further down the trail here, it's easy to apply keys from one partition to another.

DSPLICKEY to an out file, so: DSPLICKEY OUTPUT(*LICKEYFILE) LICKEYFILE(mylib/LICENSE)

Move the file LICENSE to the new partition in whatever way you choose. I use FTP with binary.

Now use: ADDLICKEY LICKEYINP(*LICKEYFILE) LICKEYFILE(mylib/LICENSE)

Done.

If you are slightly more clever, and have the partitions all set up with relational database names, you can even use SQL scripts to simply create the file, move it to the other partition, and apply the key with four SQL statements.


--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Joe Pluta
Sent: Friday, March 15, 2019 12:50 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: DSPLICKEY not showing keys (but LICENSE_INFO does!)

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?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com