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



Look at the complete joblog.
Maybe the service uses different programs than DSPLICKEY does.
For example, if someone did some home grown "migration" instead of an upgrade your DSPLICKEY could be getting a record format level check between the file and the program(s) used by DSPLICKEY which wouldn't necessarily affect a service because it sure as heck is NOT going to use any RPG RLA operations.
At least with the service you can print them off and follow the recommendations in the earlier link I sent you.
Then again, maybe one of the HA machines was on a different release upgrade and they replicated this file between systems. Definitely a no-no as they would use different keys. Well, I suppose you could be replicating on the same box in order to do Saves from the "H/A" LPAR without affecting operations on the production lpar.

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