× 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.



Short answer, no. Not seeing the keys on the ESS site is most likely because the user profile you are using in ESS is not registered to that customer number/serial number. That whole thing is a major PITA. The other potential is, the SWMA is not in force, or the transfer of the licenses is not compete for some reason.

If you really need to see the keys, use DSPLICKEY to the green screen. It will very nicely show you the keys, and all the details associated with them. If you want to see the keys from a file, use DSPLICKEY to an outfile and view that.


--
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


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.