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":
/*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 */
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
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
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
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
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
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.
If what is available from WRKJOB does not expose the issue, then