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