Link to home
Start Free TrialLog in
Avatar of pclarkeirl
pclarkeirl

asked on

DSPUSRPRF command and TAATOOL

Using the DSPUSRPRF command requires you to know the specific User profile name. You cannot enter a generic name and select from a list of profiles. However in TAATOOLS there is a command DSPUSRPRF2 which does seem to allow a generic entry against the user profile. When I run this DSPUSRPRF2  and put a generic entry in against the user profile it tells me that library TAASECURE does not exist. I tried using CRTTAATOOL command to re-generate the command but unfortunately it did not have the required archive library and deleted the command DSPUSRPRF2 from library TAATOOL.

QUESTION
How can I get this DSPUSRPRF2 command up and running ? Where can I get the missing libraries from
Or
Is there another way to be able to enter a generic user profile in the DSPUSRPRF command.

regards

Pat  
Avatar of Member_2_276102
Member_2_276102

Pat:

Are you aware that WRKUSRPRF allows *generic names and presents a list of matches from which you can select? So does [ WRKOBJPDM QSYS *n *USRPRF ] or [ WRKOBJPDM QSYS '*om*' *USRPRF ]. The latter would present a list of profiles containing the letters 'OM' somewhere in the name.

That is, what particular actions are you trying to perform? Perhaps there are ways to do them outside of TAATOOLS.

Since TAATOOLS is a 3rd-party product, you might need to call them and get support.

Tom
ASKER CERTIFIED SOLUTION
Avatar of Barry Harper
Barry Harper
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
If you chose Tom's method, you can also create user-defined PDM options that give lots of flexibility in what operations you perform on/with the user profiles.

If you press F16 from the WRKOBJPDM screen, you can see some of the pre-defined options. For example, you could create an option X like this:
CHGUSRPRF USRPRF(&O) PASSWORD(&O) PWDEXP(*YES) STATUS(*ENABLED)
Then, from the WRKOBJPDM screen, option X would run that command against the user profile, resetting its password to default, expiring the password, and enabling the profile.

Another advantage of PDM is that it allows you to subset the list by pressing F17. You can subset generically using the profile text descriptions, for example.

Barry
Avatar of pclarkeirl

ASKER

Thanks you Tom & Barry.
The reason that they want to use the DSPUSRPRF is because they do not wish to allow the user access to Change or delete the profile but at the same time to be able to determine the profile names. If I use  WRKOBJPDM then the resulting disply will allow the user to change & delete. However Tom's solution has give me the idea to use DSPOBJD rather than WRKOBJPDM. This will display the details with giving access to change
Minor note...

If the users don't have authority to change profiles, PDM won't allow them to do it.

However, it's a little more clear what you want to do. It seems that you want to grant *USE authority to profiles to some users without allowing the users to make changes. Seems simple enough, except...

This opens a far greater security hole than simply the ability to change the profiles -- it allows the users to run jobs under the authority of the profile to which they have *USE authority. I.e., the users can submit jobs and specify another profile name for the SBMJOB USER() parameter.

There are two potential ways to go:

1. For each profile that you want to authorize to another user, make _sure_ that the Data 'Execute' rights are specifically removed so that authority is a step below full *USE authority. That will allow DSPUSRPRF to function for the users against the authorized profiles without also allowing the profile to be used elsewhere.

2. Best would be to write a small CL program that accepts the (possibly generic) profile name and displays a list of all matching profiles and their descriptions. When the program is compiled, set it for USRPRF(*OWNER) and have it be owned by a profile with sufficient authority to display any expected profiles. And then authorize it with an authorization list. Anytime you want to make it available to another user, simply grant the user *USE authority to that authorization list. That encapsulates the authority into the program rather than trying to manage it all on a user by user basis.

Tom