Yes, very curious indeed. Makes you wonder if it crept into V7 as well. I did see an APAR regarding threads and the profile handle APIs. Maybe their connected to your issue?
Would using the Retrieve User Information (QSYRUSRI) API format USRI0100 to check for expired password or disabled profile help your situation? Format USRI0100 contains a profile's status, days until password expires and a flag for if the password has expired.
I don't think using QSYRUSRI will cost so much in terms of processing time to disregard it. Given what you've discovered using it could turn out to be a very handy defensive coding technique.
GM
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Wednesday, July 09, 2014 11:34 AM
To: Midrange Systems Technical Discussion
Subject: Re: Expired password change anomaly
Monnier, Gary wrote:
. . . you will receive error message ID CPF22E4 in the error code
parameter when calling QSYGETPH with an expired password.
Obviously we would get a CPF22E4: that's how we know the password is expired, and how the server program knows to tell the client program to bring up a password change dialog.
Once again, if there were a parameter we could pass to QSYGETPH to tell it NOT to actually generate the profile handle, but simply to validate the password and return its status, or if there were another documented API that ONLY validated the password, that's exactly what we'd do. But QSYGETPH seems to be the only game in town.
Also, it appears that this anomaly ONLY happens on our V6 box, not on our V5 box. Curiouser and curiouser.
--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
