Re: CHKPWD fails for some users after LVL 2

SWAG: For whatever reason the CHKPWD processing dislikes the data that the user has entered for the PASSWORD() value, and the CLP is coded as effectively the following loop which could be [incorrectly] perceived as a "hang":

chkpwd:
?chkpwd ??password()
/*monmsg (cpf2364) exec(do) */
/* this really needs to be handled first\separately.? */
monmsg (cpf2362 cpf6801 cpf2360) exec(do)
/* incorrect pwd typed, or PFkey F12 or F3 pressed */
/* including range message cpf2360 is too generic */
/* because a cpf2364 requires an alternate effect */
rcvmsg *same *pgmq *excp rmv(*yes)
goto chkpwd /* repeat until valid pwd supplied */
enddo
enddo

Further comment inline to the quoted message...

On 30-Mar-2012 09:19 , Boling, David E. wrote:

I've been having a weird error for some users calling CHKPWD from a
CLP after we changed to LVL 2 for PWDLVL. Some users work fine for
example with all lower case and #'s (didn't try mixed case with
them).

An error message, or what is later described as a /hang/ condition?

Another user fails unless the pwd is set to all caps. The user that
fails unless all caps was *YES for <ed: both> lvl 0 or 1 and lvl
2 or 3before the change just like most of the other users.

Presumably that means that both the "Password Present for Level 0 or 1" and the "Password Present for Level 2 or 3" indicate "Yes\True" <per DSPUSRPRF fields UPENPW and UPENPH, or equivalent output from PRTUSRPRF *PWDLVL>.

I'm wondering could it be because of the CHKPWD cmd needing a ptf
(the system and I assume the cmd is at 5.4) or something of that
nature.

Presumably that implies the DSPOBJD *LIBL/CHKPWD *CMD *SERVICE shows the object to be found in QSYS and with System Level V5R4M0.

FWiW I found no APAR nor PTF when searching the support portal.

I don't have access to the CL code, but I know from the job
log that it getting hung on the CHKPWD cmd.

Presumably that means the CLP being used had invoked CHKPWD and a request message was visible in the joblog as the last activity with message text something like one of: "LibName/CHKPWD", "CHKPWD", "CHKPWD PASSWORD()", or "?CHKPWD ...".

What is the command string that appears just before the hang?

But what might better describe "hung"? One of the following?:

Is a screen from some prior invocation still showing?
Does the screen go blank?
Does the "Check Password (CHKPWD)" command prompter panel appear, possibly with the message CPD0071 "Parameter PASSWORD required." in the message subfile?

If the latter of the above, then:
Perhaps no input is accepted, or input can be typed [correctly not visible] but Enter seems not to continue?
Do various function keys function; F24?, F14? What about the effects of either F3=Exit or F12=Cancel?
If the "hang" is after both the input to the PASSWORD field and Enter is pressed, what happens at\to the display; again presumably the ChkPwd request message remains the last visible entry in the joblog?

If the latter of the above, then:
After each attempt to specify a password and having pressed Enter, does a new "CHKPWD" request message get added to the joblog? If not, then verify the actual timestamp of the message seen in the current request, to the prior request. Presumably they are separate invocations of CHKPWD such that the CLP is just looping until success... but for some reason the CHKPWD is never achieving success for these particular users... as in my opening remarks. Possible any of the users experiencing the issue may have already reached QMAXSIGN?

I think the way that the cmd works is that it encrypts the supplied
pwd and checks it against the already encrypted as400 pwd and then
just returns a 0 or 1 so I can't see that the CLP could be affecting
it.

I agree, probably not simply the CLP having invoked the CHKPWD as origin for the hang. More likely instead, how the OS is handling the request or what the CLP does upon return from processing that command. That is why clarification of what really goes on since the invocation of CHKPWD is important, and for that...

The program stack is probably relevant just prior to and at the point of the apparent /hang/ condition; all of WRKJOB OUTPUT(*PRINT) is best, taken from another job [required, obviously, if the requested action truly hangs], and each paired with a DSPJOBLOG. The DSPJOB details might provide worthwhile details to review, including most obviously the job status, locks, and stack.

Any clues?

If what is available from WRKJOB does not expose the issue, then TRCJOB should.

Regards, Chuck