No authority to call programs

[Guest.Visitor]

I've created a couple of programs. I compile all programs using adopt authority *YES and OWNER option. All programs are granted authority *USE for a authorization list called SGUSERS. All users that belong to SGUSERS can access the programs by selecting an option from the menu. My problem is when I tried to debug a program using a user ID that is not belong to SGUSERS, I encountered error for unauthorized access to program being debug. I can't use a normal user ID (that belong to SGUSERS) to debug because all normal users are not allowed to user command line (limited authority). My question how can I debug a program that only granted access by a specific authorization list without affect the existing authority for each programs. Thanks you guys in advance.

[Guest.Visitor]

Eric, Is there some reason that you don't want to debug the program using YOUR own profile? Bret

[nycsusan@hotmail.com]

Eric wrote: "My question how can I debug a program that only granted access by a specific authorization list without affect the existing authority for each programs. " Have you tried adding your userid (or whatever userid is trying to perform the debug) to the program's auth list? Remove the userid when you are finished. This has no effect on the other users. It's typically not a good idea to grant authority individually like this, but this is only temporary while you debug.

[Guest.Visitor]

Eric, Add the name SGUSERS as a supplemental group profile to your profile. You will consitently adopt their authority hwnever you change or debug a program owned by the group. Outside of that you could talk management into purchasing a change management package. It would pass authority to you at checkout to the development level. Re-establish original authority upon promotion. HTH

[Guest.Visitor]

If you do not want or can not change your security profile. You should be able to debug the program with a Service Job (STRSRVJOB). This would require two sessions, <font color=blue>Session A:</font> Sign-On with SGUSER Id <font color=green>Session B:</font> Sign-On with authorized User Id and STRSRVJOB using the Job name, User, and Job Number from <font > color=blue>session A</font>. Enter Start Debug command for the program in question. Go back to <font color=blue>session A</font> and execute the program. Debug information will display in <font color=green>session B</font>. Hope this helps Jerry Hensley Peerless Chain

[Guest.Visitor]

You Need *CHANGE authority to a program in order to put it in debug. Either grant *CHANGE authority to your user profile, or create a CL wrapper around the STRDBG command that adopts the appropriate authority. jte MC Security Editor

[Guest.Visitor]

I do beleive that the STRSRVJOB command requires that the issuer have *SERVICE special authority. And still, you need *CHANGE authority to a program in order to put it in debug. This answer is headed in the wrong direction. jte MC Security Editor

[Guest.Visitor]

Eric, I assume that you don't want your programmers? to have the rights assinged to SGUSER on a normal basis. You don't have many options with the scenerio that you describe. Adopted authority will not allow you to debug the program unless the profile also has *SERVICE special authority. That is the easiest way, but it opens up some back doors on your system that are best left shut. You do not need *SERVICE to use STRSRVJOB, you do need *USE to the user's job you are servicing. Other than that, you can grant the private authority to the program to the person debugging, their group, or change thier prifile to add the SGUSER as a group/supplimental group. I assume the last option is no good because you are protecting your data with the same mechanism. The best option is to not debug with a production object. This has a several advantages in that you can optimize and secure the production version. Downside is that optimazation can in rare cases cause problems that won't show up in a non-optimized versoin (I have seen this happen twice and that was when optimization was new). You can still use your authority scheme for the test objects, just set up your programmer's group to have change rights to test environment programs. David Morris

[Guest.Visitor]

I was guessing that Eric was trying to debug the program as a regular user (one without special authorities) and that his programmer id had the required authority to run the STRSRVJOB command (To use the command, you must be signed on as QPGMR, QSYSOPR, QSRV, or QSRVBAS, or have *ALLOBJ authority). Many programmers are unaware of the STRSRVJOB (I was for the longest time) and I thought that might be part of the problem in this instance. Jerry Hensley Peerless Chain

[Guest.Visitor]

Thanks u guys for helping me about this issue. I've resolved this problem.