RE: QSTRUP Issue

Evan,

Well, unless I did something wrong (which is entirely possible), using adopted authority did not help. I compiled the program with USRPRF(*OWNER), which is me (and I have *ALLOBJ authority). I even used AUT(*ALL) on the CRTBNDRPG command. I just checked and there is only one version of the program on the system. I, also, checked (DSPPGM) and it says Use adopted authority =- *Yes.

And yet the program halts on an OPEN line where the printer file is referenced. The printer file itself has *PUBLIC = *All.

The QUSEADPAUT system value = *None which, if I'm reading the Info Center right, just means that anyone can create a program that uses adopted authority; i.e., no effect on the actual execution of such programs.

I just re-read your reply (after cleaning my glasses). You suggested, I think now, to create QSTRUP with adopted authority. Instead I changed the user program that was falling over with adopted authority. My ILE RPG program is invoked by its own CL, such that:
CALL QSTRUP
CALL CLPGM
CALL IDIOTSPGM - and fall down
QSTRUP finishes OK after cancelling the error and ignoring the failing CL program.

Should I have created all three programs with adopted authority?

I was thinking, as an alternative, to submit the CL from QSTRUP with me as the user.

All the @#$% program does is list the contents of the job scheduler so that, when coming out of a restricted state (or recovering from a power failure), we can determine if there were any jobs that did not run that should have (most have *NOSBM as the recovery for various reasons - but that's neither here nor yonder).

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

I'd be willing to bet you, if I was a betting man, that I never bet on baseball. -Pete Rose


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, May 20, 2010 5:39 PM
To: Midrange Systems Technical Discussion
Subject: Re: QSTRUP Issue

Hi Jerry

The QSTRUP Program gets started by an autostart job in subsystem QCTL.
It will run when subsystem QCTL started, that's why it would have had
a different user.

As to your authority issue, no doubt something has changed. Others may
disagree, but my standard approach is to alter my startup program to
use adopted authority and then make to make the owner of the program
QSECOFR, or an equivalent profile. That way I can be confident that I
will not have the startup process disrupted by an authority issue.

Regards
Evan Harris


On Fri, May 21, 2010 at 8:14 AM, Jack Kingsley <iseriesflorida@xxxxxxxxx> wrote:

Is ITSCHEDP a perm file or temp file??  What id are you signed on with when
you do the option 21.

On Thu, May 20, 2010 at 1:01 PM, Jerry Adams <Jerry@xxxxxxxxxxxxxxx> wrote:

I just finished doing a SAVE 21 on our backup system (prior to installing a
new Cume and some Groups).  QSTRUP is run whenever the system returns from a
restricted state.  Part of my QSTRUP program has a call to a program that I
wrote a year or two ago.  In the program there is a printer file when is
defined as USROPN.

There is a message waiting (the text of which is not very helpful - a call
to a procedure ended in error).  Under debug I found that the program is
stopped at the statement which opens the printer file.  The joblog prior to
that has CPF4104 - User not authorized to operation on file ITSCHEDP.
 Running DSPOBJAUT over the printer file shows *PUBLIC with *All; there are
no exclusions.  The job (QSTRUPJD) is running under QPGMR (which has no
password on our system).

I've had this program running in QSTRUP for a year or so without any
mishaps.  Any ideas?

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email:  jerry@xxxxxxxxxxxxxxx<mailto:jerry@xxxxxxxxxxxxxxx>

I've seen the future and it's much like the present, only longer. -Don
Quisenberry

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.