James,
If you are using the QSYGETPH or QsyGetProfileHandle APIs and are actually providing a password you should be, given your description, receiving CPF22E4 - Password for user profile &1 has expired.
QsyGetProfileHandle states "To obtain a profile handle when the password is expired, use the Get Profile Handle No Password (QsyGetProfileHandleNoPwd) API."
QsyGetProfileHandleNoPwd states "To obtain a profile handle when the password is expired, specify *NOPWDCHK or *NOPWDSTS for the password parameter."
QSYGETPH states "To obtain a profile handle when the password is expired, specify *NOPWDCHK or *NOPWDSTS for the password parameter."
Seems to me if you are obtaining a handle for a profile with an expired password and are not using *NOPWDCHK or *NOPWDSTS for the password parameter you may have found a serious bug.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Tuesday, July 08, 2014 3:03 PM
To: Midrange Systems Technical Discussion
Subject: Expired password change anomaly
I've noticed something I can't explain.
Given an account with an expired password:
If I sign on to a terminal session, and refuse to change the password, it doesn't let me in, but neither does it increment the "Password verifications not valid" counter.
On the other hand, we have a client-server product that recognizes expired passwords, enforces the expiration, and uses QSYCHGPW to allow the user to change the expired password through the client server connection.
At no time in its life-cycle does any server job use a profile handle to do a "user swap"; rather, a profile handle is obtained strictly to verify the password, and then a child-server job is submitted under the user's profile, and the socket is transferred to the child-server job.
It seems that when an expired password is processed through the product, IF ONE CANCELS THE SIGN-ON INSTEAD OF SETTING A NEW PASSWORD, the "Password verifications not valid" counter increments. But it doesn't increment immediately, but rather, it increments WHEN THE SOCKET IS CLOSED, AND THE JOB CURRENTLY HOLDING THE SOCKET (WHICH OBTAINED THE PROFILE HANDLE) EXPIRES.
I can't make head or tail of this behavior. It certainly doesn't appear to be trying to obtain any profile handles with bad passwords.
--
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
