Re: Modifying CHGPWD -Reply

Hope this finds everyone well after COMMON,  sounds like the problem is
not the authority of the command but who is trying to run it... in your case
you must make sure the CL that you wrote is owned bu QSECOFR or a
Group or User that has *SECADM , that is required to chg user profiles,
after checking that make sure your program is running as user profile
*owner not *user.... you can check this with DSPPGM and it can be
changed either by a re-compile or simply CHGPGM...  as a general rule I
always change the defualts to be user profile *owner... then my
programs are owned by QPGMR for instance and your system authority
just got a lot easier..... good luck

Bob Kerr
Director of Data Center Services
NordicTrack
Chaska, MN

>>> Al Barsa, Jr. <barsa2@ibm.net> 09/29/97 08:57am >>>
At 10:11 PM 9/29/97, you wrote:
>On Tue, 23 Sep 1997 11:36:57 CST, david.gibbs@silvon.com wrote:
>
>>On 24 Sep 97 at 0:07, Matthias Oertli wrote:
>>
>>> I'd like to duplicate the CHGPWD command into a library
>>> above QSYS. The CPP would be a CL in the same library
>>> which would put up a screen explaining the rules applied
>>> by the 400 to new passwords (set using system values).
>>> Once a user presses enter, the CL would transfer control
>>> to the original CHGPWD command (using QCMDEXEC).
>>
>>Seems to me that it would be pretty easy to do... as there are no 
>>parameters for the CHGPWD command.
>
>I've got no problem with the CL, DDS and the duplicated command,
>it all works.
>The real problem is this: if a userprofile is set to PWDEXP(*YES),
>when that person next logs in the system requests a password change.
>On pressing enter the 400 sends CPI2240 (Not allowed to change
>password because you don't have authority to CHGPWD command)
>Now the library, the CL, the DDS and the Command all are 
>PUBLIC(*USE) which should be sufficient.
>There must be a catch somewhere...
>Anyone have an idea?

The shipped public authority for CHGPWD is *USE.  Make sure that your
command has not been changed.  The design of the AS/400 insures that
changed public authorities will survive from release to release.  As a
matter of fact, there's no way to restore authority for a command object
onto a system without deleting the pre-existing command first.  If your
command defaults have been changed from default and you want to
reset them, you have to go to another system, and do DSPOBJAUT to an
output file, etc...

Al

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:  914-251-9400
Fax:    914-251-9406





Private mail should be sent to barsa@ibm.net
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to
"MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator:
david@midrange.com
+--- umidr


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---