Re: Issues with Adopted Authority

Thanks to all who responded to this. Rob Berendt is correct, the issue is
not from QCMDEXC stopping the adoption string, it is from another issue.
That issue is the user doesn't have authority to the libraries in the
library list. SBMJOB defaults to INLLIBL(*CURRENT). When the sbmjob
runs, adoption is initially lost so the user reverts back to no authority.
This causes issues with the SBMJOB because the user is not authorized to
those libraries.

The routing entry idea is very cool, I wish I had thought of that. I may
choose to do this. I typically lean to solutions that can be embodied in
code, as opposed to work management tweaks that are not obvious to less
experienced administrators and may be lost when an o/s upgrade replaces a
subsystem description (QBATCH). I will weight the pros and cons.

I have figured out a way to solve the library list authority issue in my
approach, I pass the library list as a parameter in my command and set the
library list when my program starts up in batch. It works.

Thank you all for your input.

Joe



From: DrFranken <midrange@xxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/29/2018 14:25
Subject: Re: Issues with Adopted Authority
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



If you are going down this path the routing program I think is the right
direction.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 5/29/2018 3:03 PM, Marc Rauzier wrote:

Le 29/05/2018 à 16:52, Joe Hatchell a écrit :

The call stack is
lost and therefore they have no authority to the objects needed to run
the
program.

I solved a similar issue by writing a program which is invoked in the
routing entry of the batch subsystem in place of QSYS/QCMD program.
The program I wrote does adopt owner authority. In fact, it is a bit
more complex but this is the principle.

Marc