RE: QSTRUPPGM issues (was: no subject)

Mark,

To make a long story short, the instructions below basically has QSTRUP run as QSECOR instead of QPGMR, correct.
This would solve many issues for me.
However, from a security stand point we should NOT be running jobs as QSECOFR, correct.
I just finished my 4-day extended security training course.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Thursday, September 18, 2014 9:53 AM
To: Midrange Systems Technical Discussion
Subject: Re: QSTRUPPGM issues (was: no subject)

Rob:

Issue:
WRKSBS

Type a "5" (for 5=Display) next to QCTL and press Enter

Select option 3. Autostart job entries on the menu. You will
see an entry for job QSTRUPJD with JOBD(QSYs/QSTRUPJD).

Issue:
DSPJOBD QSYS/QSTRUPJD

This job calls a program named QWDAJPGM that presumably retrieves the system value QSTRUPPGM and then CALLs that program.


So, the following approach could be used to solve this "problem"
(needing QSECOFR to perform certain actions at system start-up):

#1. create a new job description, based on QSTRUPJD, using e.g.
CRTDUPOBJ, named e.g. QSTRUPJD1 in library QGPL.

#2. modify this *JOBD so it specifies user profile QSECOFR and change
the CALL to call your own "fix-up" program, e.g. QGPL/QSTRUP2

#3. issue the ADDAJE command to add a new autostart job entry to QCTL on
each of your LPARs, e.g.:

ADDAJE SBSD(QSYS/QCTL) JOB(QSTRUP2) JOBD(QGPL/QSTRUPJD2)

Now, you have a straight-forward method to run a job "as" QSECOFR to do
whatever you need to do, whenever the system is IPLed, or whenever the
QCTL subsystem is started. No muss, no fuss, no "profile swapping"
APIs, etc.

HTH,

Mark S. Waterbury

On 9/18/2014 8:42 AM, rob@xxxxxxxxx wrote:
Here's the issue,
Startup program runs at IPL.
I want the startup program to set certain items that IBM mucks up upon
system restores and whatnot.
One of these items I want changed is the attribute on /QFPNWSSTG.
Startup programs runs under QPGMR. This profile cannot change that
attribute.
Calling a program that has adopted authority does not work as the stream
file system doesn't recognize adopted authority.
QPGMR cannot submit a job to run under QSECOFR, even if it uses an adopted
authority program. USER(QSECOFR) is stopped in it's tracks by SBMJOB.
Check the help on that.
I could try getting a profile handle to QSECOFR. I've not worked with
profile handles. I'm under the impression that I need to know the
password for QSECOFR in the get profile handle api. And we do change the
password, so burying it into code is not desirable.
I am leaning towards submitting the job under some user created user
profile that has *ALLOBJ. I just have to ensure that it exists on all
lpars, etc.
Any other suggestions?

Rob Berendt