Re: User attribute doesn't change con CRTBNDRPG command

That's the way it's always worked with REPLACE(*YES)....

User profile (USRPRF) - Help

Specifies the user profile that will run the created
program object. The profile of the program owner or the
program user is used to run the program and control which
objects can be used by the program (including the
authority the program has for each object). *****This
parameter is not updated if the program already exists.*****

You'd need to delete then recompile the program.

HTH,
Charles

On Fri, Oct 3, 2008 at 12:37 PM, Thomas Garvey <tgarvey@xxxxxxxxxx> wrote:

Hi, everyone,

Can anyone explain why a program, created by CRTBNDRPG, which currently has
the User Profile attribute set to *USER, will NOT change that attribute to
*OWNER when the compile command clearly instructs it to do so?

For example, Display Program appears as follows:

Program . . . . . . . : I276200441 Library . . . . . . . :
UserLibrary
Owner . . . . . . . . : QSECOFR

Program attribute . . : RPGLE

Detail . . . . . . . . : *BASIC





Program creation information:

Program creation date/time . . . . . . . . . . : 10/03/08 11:16:08

Type of program . . . . . . . . . . . . . . . : ILE

Program entry procedure module . . . . . . . . : I276200441

Library . . . . . . . . . . . . . . . . . . : QTEMP

Activation group attribute . . . . . . . . . . : *DFTACTGRP

Shared activation group . . . . . . . . . . . : *NO

User profile . . . . . . . . . . . . . . . . . : *USER

Use adopted authority . . . . . . . . . . . . : *YES

Coded character set identifier . . . . . . . . : 65535

Number of modules . . . . . . . . . . . . . . : 1


Now, a recompile, as follows, occurs...
CRTBNDRPG UserLibrary/I276200441 srcfile(UserLibrary/qrpglesrc)
srcmbr(I276200441)
replace(*yes) dftactgrp(*no) actgrp(*caller) usrprf(*owner)
aut(*exclude) dbgview(*source)

Note the usrprf attribbute and the replace parameter.

Why would the new, replaced object RETAIN the *USER setting, after the
compile has successfully completed? (QSECOFR is doing the compile).

This can't be some security approach IBM is using because if I have the
authority to replace the object, and change the logic altogether through the
compile, surely I have the authority to indicate it should be run as *OWNER,
not *USER.

Furthermore, if I delete the program before the compile, the attribute is
set properly.

Any ideas?


Best Regards,

Thomas Garvey



--
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.