×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Ok, so you have the CPP and all other program objects for LOGCMD owned by QSECOFR and their user profile setting is *OWNER.
Let me be a little clearer about using a profile other than QSECOFR. First, cerate the profile with a user class of QSECOFR. Verify this profile has at least *ALLOBJ special authority. Second, change the owner of the LOGCMD programs to be the profile you just created. Third, test LOGCMD with the new object owner. If it still fails, add *SERVICE special authority to the new profile and try again.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Denis Robitaille
Sent: Monday, October 15, 2007 2:20 PM
To: Midrange Systems Technical Discussion
Subject: RE: Rép. : Re: Adopted authority problem
The LOGCMD object is a *CMD object, so it does not adopt authority. But the CPP and all other called programs do. And QSECOFR is the owner of all of them. There are no other instances of those programs on the system. In fact, except for the *SERVICE special authority, all other authority are given when inside the command.
If I define the user as *SECOFR, the command works
"Gary Monnier" <gary.monnier@xxxxxxxxxxxxx> 2007-10-15 16:50 >>>
Is command LOGCMD also owned by QSECOFR? What authority and ownership does LOGCMD's CPP have? Is the CPP owned by QSECOFR? Are you positive the command is running out of the library you expect?
If you create a profile with a user class of *SECOFR what occurs?
midrange.com
