Re: User attribute doesn't change con CRTBNDRPG command

Hi, Thomas:

That is the way the OS/400 IBM compilers have always worked, ever since the introduction of REPLACE(*YES) support. You should see some informational messages near the end of the compile listing telling you that this parameter was ignored, because the previous version of the program being replaced was USRPRF(*USER) and not USRPRF(*OWNER).

Issue CHGPGM xxx/yyy USRPRF(*OWNER) to change the current *PGM object first, then recompile with REPLACE(*YES), or simply delete the program first, then recompile.

Cheers,

Mark S. Waterbury

> Thomas Garvey 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