Security APIs and Profile Handles

[andy...@my-deja.com]

I am currently having some problems with the OS/400 security APIs. I
wish to change the user profile under which my job is running. I
believed the sequence would be something like:

1) Retrieve user profile handle (QSYGETPH)
2) Set user profile (QWTSETP)
3) Do actions as user

However, after step 2 my job still seems to be referred to as COOKA
everywhere (i.e. both locations of the PSDS, etc), except for on screen
1 of the DSPJOB command.

I have since tried adding a step between 2 and 3 using the QWTSJUID,
which should explicitly set the user profile to the one I 'activated'
in step 2. This had the effect of changing the 'Set By' value on screen
1 to *APPLICATION instead of *DEFAULT, but had no other perceptible
effect.

Does anyone know how I can change my job so that the PSDS correctly
reflects the 'adopted' profile?

Sent via Deja.com http://www.deja.com/
Before you buy.

[Paul Nicolay]

Hi Andy,

Not having it with me, but the PSDS contains the new user as well at another
location. Normally you should use that one (also when the profile isn't
switched) in all circumstances.

The same is true for RTVJOBA which also has the swapped user (one you also
should use in all circumstances).

Regards,
Paul
------------------------
<andy...@my-deja.com> wrote in message news:8ccsth$tb0$1...@nnrp1.deja.com...

[Carsten Flensburg]

<andy...@my-deja.com> wrote in message news:8ccsth$tb0$1...@nnrp1.deja.com...

> Does anyone know how I can change my job so that the PSDS correctly
> reflects the 'adopted' profile?

Hi Andy,

As far as I remember the RPG/III PSDS does reflect the current user profile,
as for RPG/IV there has been added a second field, please check out this
APAR:
http://as400service.rochester.ibm.com/n_dir/nas4apar.NSF/c79815e083182fec862
564c00079d117/aedfee389356a93286256561002cc714?OpenDocument

Best regards,
Carsten Flensburg

[andy...@my-deja.com]

Thanks for the info, but I was already using the second user profile
field in the PSDS. ( I didn't know that was added as a workaround.)

The problem seems to be do with the way that the PSDS is refreshed. The
workflow I am trying to achieve is something like this:

1) Enter main program as user profile USER1.
2) Call AddItem(), a procedure within SRVPGM1.
3) Change to user profile USER2 (as described in first post).
4) Call VerifyItem(), a second procedure with SRVPGM1.
5) Change back to USER1, read next record and go to step 2.

The problem seems to be that once SRVPGM1 is initialised by the AddItem
call, the PSDS within the service program is set up with USER1 in both
user-related fields. When I reenter the service program as USER2, the
PSDS still reflects USER1.

If I split the two functions into separate service programs, I can
achieve the desired effect in testing. However, this is not a
acceptable option for a production release.

Maybe I need to find a way of forcing a refresh of the PSDS, or forcing
the service program to reinitialise before the second function call?

In article <38ea3d17$0$28...@lithium.news.uk.uu.net>,

[Paul Nicolay]

Hi,

And what if you would write a routine (just use a RTVJOBA CURUSER) that
returns the active user instead of looking at the PSDS ?

Regards,
Paul
---------------------
<andy...@my-deja.com> wrote in message news:8cf5uc$f3h$1...@nnrp1.deja.com...

[andy...@my-deja.com]

Unfortunately, the data access modules are in a service program that is
not mine to change. I know that they are definitely checking the second
Current User Name field in the PSDS, and then using this value to check
whether the user is authorised to perform the requested action.

I have a work-around for the problem that involves starting
two 'instances' of the service program. The first instance is in the
entry point program, and is initialised under the USER1 profile when I
make a procedure call. I change profile to USER2, then call an ILE
shell program/procedure in a separate activation group. This starts a
second instance of the service program running under USER2.

The original problem is less of a concern now: I am just curious as to
when, how and why the PSDS is updated. If anyone can shed any light on
this topic, I would be grateful. Thanks for your interest!

Andy

In article <6%GG4.30$Ge....@nreader2.kpnqwest.net>,

[Paul Allen]

andy...@my-deja.com wrote:

> Maybe I need to find a way of forcing a refresh of the PSDS, or forcing
> the service program to reinitialise before the second function call?

Or, you could ignore the apparently stale information in the PSDS and call
the Retrieve Job Information (QUSRJOBI) API to retrieve the current user
profile for your job.

Here is a link to the v4r4 version of the QUSRJOBI API doc:
http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AM703/1.28

[Gary Monnier]

Take a look at APARs SA71206 and SA69867 ( http://as400service.ibm.com/ ).
If you are running V4R3M0, or lower, you might find the value you think is
current user actually is not and will have to load a PTF or two.

<andy...@my-deja.com> wrote in message news:8cfocv$48o$1...@nnrp1.deja.com...

> > > Maybe I need to find a way of forcing a refresh of the PSDS, or
> forcing
> > > the service program to reinitialise before the second function call?
> > >
> > >

[Carsten Flensburg]

<andy...@my-deja.com> wrote in message news:8cf5uc$f3h$1...@nnrp1.deja.com...

> The problem seems to be that once SRVPGM1 is initialised by the AddItem

> call, the PSDS within the service program is set up with USER1 in both
> user-related fields. When I reenter the service program as USER2, the
> PSDS still reflects USER1.

Andy,

As you say - it's the PSDS - which is static storage - that doesn't get
reinitialized.

One way around the problem - I think - would be creating the service program
with ALWRINZ(*YES) and then call the builtin _RINZSTAT prior to your second
call to the service program.

To easily check if it works call _RINZSTAT with it's default parameters,
which requires you to have the caller to be in the same activation group as
the program (static storage) you want to reinitialize.

Note that all programs in that activation group that has been created with
ALWRINZ(*YES) will get reinitialized:

D ActTpl Ds
D pProgram * ProcPtr Inz( *Null )
D ActGrpMrk 10u 0 Inz( 0 )

C CallB '_RINZSTAT'
C Parm ActTpl

The procedure pointer could set to a system pointer to a specific
(service)program, using the _RSLVSP2 or -4 builtins, if you would rather not
reinitialize all eligible programs in the activation group, just as
_MATAGPAT or _MATPRAGP builtins would enable you to get an activation group
mark for other activation groups, but that's a bit more complicated.

Best regards,
Carsten Flensburg