ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Changing current user profile

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Changing current user profile

    I've noticed that there are some jobs running on our system where the CURRENT USER PROFILE is changed to something other than the user profile of the the profile that initiated the job. I don't see a parameter on the CHGJOB command to change the current user profile although there is a CURUSER parameter on the RTVJOBA command. How is this being done? Is there an API that does it? I can see the message in the job log where it was changed.

    Click image for larger version

Name:	Current profile.jpg
Views:	774
Size:	40.8 KB
ID:	152957

    I have a need to be able to do this for a project I am working on.
    Attached Files

  • #2
    Do these help at all?

    I see developers make one mistake way more often than any other. They assume that the job user name also represents the user profile under which a job is currently executing. This is, and always has been, an invalid assumption. The job user name only represents the userID under which the job was originally started.

    Tips & Techniques, APIs, TechTip: Change the User Profile for the Currently Running Job, as/400, os/400, iseries, system i, i5/os, ibm i, power system, ibm 6.1, Security, QSYGETPH, QWTSETP, authority

    Well a few days back I was working on a program that was using DDM files. Now for DDM files to work you have to add authority for each user ...

    Comment


  • #3
    I noticed there were some new sub fields added to the PSDS. One of these is CURRENT USER (posn 358-367) . I am assuming that CURRENT USER is always the same as USER PROFILE (posn 254-263) until changed by one of the API's described above. Does anyone know if that is correct. Is CURRENT USER ever blank?

    Comment


    • #4
      You are correct that CURRENT USER is the same as USER PROFILE unless the user profile has changed within the job.

      You are not correct when you refer to these fields as "new", they've been there for more than 20 years.

      I personally prefer doing this instead of the PSDS, I think its far easier to read and understand:

      Code:
           D UserId          s             10a   inz(*USER)
      -or-

      Code:
      dcl-s UserId char(10) inz(*USER);
      But the PSDS does work correctly as well. Note that in RPG/400 the "USER PROFILE" field would actually change to the current user when the profile switched which caused the opposite problem... if you tried to calculate the job id (123456/MYUSER/MYJOB) you'd get the wrong user profile for the job name, so it would not work consistently. This was fixed when they created RPG IV in 1994 and added the CURRENT USER field, then you have the best of both worlds.

      Comment


      • #5
        Just a warning about using the PSDS. It gets initialized with the current user ;profile during module initialization. (That happens the first time any procedure in the module is called, and it happens again when a cycle-main procedure goes through the *INIT part of the cycle.)

        If the current user profile changes after initialization is done, the PSDS subfield won't reflect the change.

        Same with global fields initialized with *USER.

        So if the current user profile might change while your program is running, an easy way to get the real current value is with a procedure like this. As long as the field initialized with *USER isn't defined with the STATIC keyword, it gets initialized every time the procedure is called.

        Code:
        [FONT=courier new]dcl-proc getCurUser;
           dcl-pi *n char(10) end-pi;
           dcl-s curUser char(10) inz(*user);
        
           return curUser;
        end-procl[/FONT]

        Comment

        Working...
        X