RE: System startup program and adopted authority

Dr. Franken,

While the data area works, I do not like to check for existence but for a lock. After submitting the job, have the submitter delay a certain amount of time, and then check for a lock on the data area. The first thing the submitted job does is an ALCOBJ OBJ((LIBRARY/DATAAREA *DATARA *EXCL))

No clean up necessary as once the job ends, normally or not, the lock is released.


Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Wednesday, March 07, 2018 11:41 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: System startup porgram and adopted authority

The points thus far have been good and accurate.

One thing not mentioned is that certain authorities are NOT adoptable.
As a consequence even owning the program by QSECOFR is not sufficient. A
common case I run into is the pieces that POWERHA requires to be
started. QPGMR can't do it and the needed authority cannot be adopted.

So I generally do a variation on the earlier suggestions in this thread
and with Jim's thinking try to box tight the use of higher authority. I
create a profile that has no password and no command line ability. I
grant authority to QPGMR to use that profile. In the startup job I
submit the program with the needed steps using the profile.

One thing I've done is for steps that need to be completed before the
startup job continues is to create a data are just before submitting the
second task. At the end of that task the data area is deleted. Meanwhile
the primary startup job loops waiting for the data area to disappear.

Clearly not the only way to do this but it has worked well.