AUT parm on user profile

[Guest.Visitor]

We have had a few of the programmer's user profiles created with the AUT parm set to *EXCLUDE. This has caused the following problem. If the programmer creates a file that an end-user needs to clear, the end-user doesn't have authority to clear it. Is there a way to change the value of the AUT parm? It is not on the CHGUSRPRF command. We are on V4R3.

[Guest.Visitor]

AUT parm on user profile

Bobby, When creating a new userprofile, the AUT keyword is the last parm. Press F10 and roll to the end of the additional parameters. The default is *EXCLUDE, I usually change this to *CHANGE. I don't remember if this can be accessed from the CHGUSRPRF or DSPUSRPRF commands. Seems that when we had this issue a few years ago, we created new profiles and deleted the old ones for our programming staff. I'm sure someone on the board has the correct, answer, but this is at least quick. Unless you reasign owned objects anyway. Hope this helps, Bret

[Guest.Visitor]

AUT parm on user profile

Bobby, Are your programmers and users in the same group? The initial authority other than the owner or a member of the group would come from the library create authority. Display the library to see what this value is. It probably points to the system value QCRTAUT. As a programmer, I wouldn't want authority to production data. For that reason, we maintain seperate test and production environments and change the authority when objects are promoted. David Morris

[Guest.Visitor]

AUT parm on user profile

I believe you can use EDTOBJAUT to change the authority to the programmer's user profile. However, I don't think this will solve the problem you described. Are the programmers using a group profile? Are the users using group profiles? What is the value for QCRTAUT? More details please? John

[Guest.Visitor]

AUT parm on user profile

Be careful!!! When you give the *PUBLIC authority of *USE to a profile, any user with LMTCPB(*NO) that can get to a command line can submit a job to batch under that other user profile. These jobs also possess all the special authorities assigned to that user profile like *ALLOBJ, *SECADM, etc. Heck, you can bypass the check for LMTCPB too. Instead, I would always make the *PUBLIC authority *EXCLUDE to user profiles and have the programs adopt authority. Chris

[Guest.Visitor]

AUT parm on user profile

Chris, Did I reference the wrong keyword? I'm not sure, but I thought that had to do with objects created by the user profile, not the profile itself. There is a keyword for authority and group authority that allow what your are talking about (if my memory serves me). Also, when creating files, I always, without fail give *CHANGE to the file so that all users can have access to the files. They can't get to them without a program or DB editor on my system anyway, and I don't allow them access to such outside their requirements. Later, Bret

[nycsusan@hotmail.com]

AUT parm on user profile

Bobby, There is a parm in the user profile called "Owner". I'll wager that right now it is set to *USRPRF which means that the user profile associated with the job is the owner of the object. If you set the Owner parm on the user profile to *GRPPRF then the group profile is made the owner of newly created objects and has all authority to the object. Hope this helps.

[Guest.Visitor]

AUT parm on user profile

Hi Susan, Does'nt the OWNERSHIP refer to owner of the object created by the user? If I remember correctly, I used to set my programmers so that their GRPPRF was QPGMR (I know, not very original) and that QPGMR was the owner of the object. This had nothing to do with the user accessing the file, outside of ownership anyway. It was with EDTOBJAUT, that we set the object to *CHANGE for the user to access. There are actually 10 levels of OBJAUT you can use to set, but KISS prevails if you plan correctly. What needs to happen is the command to create files, and other objects needs to be set to *CHANGE for files, so the user can delete workfiles, etc. and for program objects, it needs to be set to *USE. The command of EDTOBJAUT can only update one object at a time, but if you do a GRTOBJAUT you can specify all objects in a library or library list, or *all/*allusr libraries to be what you want the authority to be for every object or object type in the library(ies) you specify. Hope this helps, Bret

[nycsusan@hotmail.com]

AUT parm on user profile

Yes, the Owner parm on the user profile determines "who" owns the object created by that profile. Yes, typically a group profile should be there so that the entire group (of programmers, managers, users, whatever) can access the newly created object. Yes, EDTOBJAUT will fix the object once it is created. But to fix the cause of the problem, or the possible cause of the problem, I am suggesting that Bobby take a look at the Owner user profile parm. We had problems when one of our people had this Owner parm on her user profile set to *USRPRF. The file she created is cleared as a regular part of batch processing and other profiles were not authorized to clear it (or delete, I forget now). That was a pain to debug because there were "authority problems" out of the blue. Perhaps I am misunderstanding Bobby's issue. That's entirely possbile. I am a bit distracted today after reading some of the "exchanges" in this forum. Anyway, if I misunderstood and/or muddied the issue, please ignore this post. This is something else for Bobby to look at that may answer his question. I took a shot at helping out.

[Guest.Visitor]

AUT parm on user profile

Susan, I too am distracted and thought maybe I misread the question. I was not able to go back and read the thread beginning, but I do know that between the two of us, we are right. Promise, the next can of worms I open will be to go fishing at the lake with. Bret

[Guest.Visitor]

AUT parm on user profile

Wow! Lot's of confusion in this thread. Just to set the record straight... The AUT parameter on any CRTxxx command controls what *PUBLIC's authority to this newly created object will be. In the case of the CRTUSRPRF command, you definetly want *PUBLIC's authority to the new User Profile to be *EXCLUDE because any one who has read authority to another User profile can assume the identity of that profile at will. Now, for your original questions... As for programmer's creating objects that user's cannot access, there are a couple of solutions. First, don't let programmers put objects directly into production. There ought to be a change management /source control step that sits as a firewall between programmers and the production environment. This will prevent silly little errors such as users not having authority to objects in production 9and many other error types I'm sure). You should have a single profile that owns all of the produciton objects (and, no, it should not be the group profile that all the users belong to). This profile can confer authority to the user community either through adopted authority (the *USRPRF/*OWNER option on the CRTxxxPGM command), or through a combination of adopted authority and membership in an authorization list 9my preferred method). Last (and certainly least) you _could_ set the defualt public authority on the library (CRTAUT parameter) to something higher than *EXCLUDE, but understand that *PUBLIC is everyone who has access to your system and if you give _everyone_ *CHANGE or *ALL, don't be surprised when someone *CHANGE's or *DELETE's your data accidently-on-purpose. hth, jte

[Guest.Visitor]

AUT parm on user profile

John, "...You should have a single profile that owns all of the produciton objects (and, no, it should not be the group profile that all the users belong to). This profile can confer authority to the user community either through adopted authority (the *USRPRF/*OWNER option on the CRTxxxPGM command), or through a combination of adopted authority and membership in an authorization list 9my preferred method)...." I think this sounds like the best solution and is how our systems are secured. Unfortuanately, we are running into more and more exceptions where this does not work. One of the reasons is that a single profile owning all production objects is rarely practical. On our system we have owners for payroll, test payroll, production, and at least one required by a vendor package. For example, how do you get multiple profile authorities in an exit program? We swap profiles for the first level but I am sure we will need at least two other authorities at some point to support packaged software and payroll. The group profile only offers one more level and this is also adding quite a bit more complexity. Another options might be to give private authority to secondary profiles to all objects and only use a single level. For example, grant payroll authority to all files. Also, we are currently struggling with authorities in the IFS. As we get more and more private authorities in the IFS, we are experiencing more problems in that area. Is profile swapping the way to go in this area? I am currently trying to come up with an updated unified authority scheme and any comments on how best to accomplish this would be appreciated. One goal is to continue the use of adoption/authority list a primary means of obtaining authority. David Morris

[J.Pluta]

AUT parm on user profile

In your situation, David, I would use Supplemental Group Profiles. The SUPGRPPRF keyword allow you to associate up to 15 additional group profiles, in addition to the one on the GRPPRF keyword. I've found this to be sufficient to supporting even very complex environments. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[Guest.Visitor]

AUT parm on user profile

John, I agree with not allowing programmers to put things into production. Even my stuff is, and rightly so, tested by someone else, before another person puts it into production. I am writing a change management system that will maintain this for us. It allows ONE programmer type to check out an object, into their library, allows them to compile it, and test it and when it is ready to be put into production, it is done so, with the correct library lists and object authorities. Later, Bret

[nycsusan@hotmail.com]

AUT parm on user profile

Speaking of supplemental group set-ups ... I have a question about that. What happens if you (your profile) is a member of several groups and the various groups have different authority to an object? Say your user profile has supplemental groups set-up: Group1 and Group2. Now Suppose that Group1 has *USE authority and Group2 has *ALL access to an object. What authority do you have in that case? Also, does it make a difference if one of the Groups in my example is your primary group instead of a supplemental group? Would the primary group "rule"?