RE: Issues with Adopted Authority

Jim,

We are also subsystem control freaks.
Most of ours reside in GPL, created back in the mid 90's.
Then there's all our 3rd party products, each have their own subsystem(s), which reside in their product library, about 30 of these.
We don't use QINTER or QBATCH, but a copy of those.
All our batch subsystems all start with BATCH_**.
Reason for this so when one does WRKACTJOB, any/all batch jobs are on the first page without having to page.
All our interactive subsystems all start with INTER_**.

What would be a subsystem addition/change that I may be missing since ours our old and have not been recreated since mid 90s.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Wednesday, May 30, 2018 9:18 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Issues with Adopted Authority

Rob,

Changes to IBM subsystems have been extremely rare, and well documented.
The only real change is they will add prestart jobs occasionally as new
functions are added.

The CL program to update things after and upgrade is always a good idea if
for no other reason than documentation, but that usually falls apart in a
hurry when the change is made and "I'll update the CL later" happens.

In the end it does not matter which method you choose, pick one and stay
with it. The control freak in me likes to run all my own subsystems with my
own routing programs so I know exactly how the system behaves.


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Wednesday, May 30, 2018 6:08 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Issues with Adopted Authority

I used to replace subsystem descriptions with my own. Then I realized what
a mess I made. I was always afraid that an upgrade might lose job queues
etc. We have a bazillion job queues. Then I discovered that it would not.
However I discovered it so late that it could no longer migrate my subsystem
descriptions because they were originally created under some ancient release
(perhaps even V2R1). I had to recreate them from scratch and then all was
right with the world.
Sometimes IBM adds some things to the subsystem descriptions it may need,
like some job queue for TCP for example.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 05/29/2018 10:13 PM
Subject: Re: Issues with Adopted Authority
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Joe,

The trick to avoiding issues with upgrades/PTFs is to copy the subsystem
descriptions to a user library (I use a combination of libraries at the
top of the system library list called PARTITION and SYSTEM) so during
those processes IBM will not touch them.

The basic partitions from IBM have not changed in many upgrades so they
are safe.



Jim Oberholtzer
Agile Technology Architects

On May 29, 2018, at 4:27 PM, Joe Hatchell <jhatchell@xxxxxxxxxxxxx>

wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: http://amzn.to/2dEadiD