My company is using both O/S 7.1 and 7.3.
I can not get the current user for HTTP jobs (QHTTPSVR) , tried the API OUSRJOBI, still do not get.
Current User and User are both the same, QTMHHTTP.
These jobs are part of an older version of Harris Data using PHP and RPG programs....Harris Versions 4.3 and 5.0.
In 7.1 and 7.3 the sql tables for doing this do not seem to be avaiable, if they would even help.
Any thoughts, I understand the User (Current User) swaps in and out as they do requests.
Thank You
Having Issue getting Current User OnHTTPSVR Jobs
-
Scott Klement
- Site Admin
- Posts: 911
- Joined: Sun Jul 04, 2021 5:12 am
Re: Having Issue getting Current User OnHTTPSVR Jobs
Hello,
Something this simple should work fine:
If you are doing your own profile swapping within the program, you may have to put this in a subprocedure. This is because the INZ() in a program happens when the program first activates, but in a subprocedure it happens every time the subprocedure is called. When you are swapping profiles, it's important for the INZ to run after the swap takes place.
If the HTTP server is doing the swapping for you, then its not necessary to put it in a subprocedure.
QUSRJOBI will also work (though, its much more code, and I don't know why you'd use that instead of INZ(*USER) since its more work for you.) BUT, you have to be careful to be retrieving the CURRENT user, not the user component of the jobid. The current user can be found in format JOBI0600 at offset 91. I know this because, before IBM added the INZ(*USER) feature, I used this approach. (This was more than 20 years ago, now, and INZ(*USER) is what I've used since then.)
You can also use the CL RTVJOBA command, but again, make sure you are getting the CURRENT USER, not the user component of the job id.
A job on IBM i is named with 3 parts, the job name, user name and job number. So it looks something like 123456/SCOTTK/QTMHHTTP. This identifies the job to the system, an the user portion of this will never change during the life of the job. (If it did, the system would not be able to run the job anymore.) However, there is a separate field for the CURRENT user. Just make sure you are getting THAT rather than the part that identifies the job. Any of the methods (PSDS, RTVJOBA, QUSRJOBI, etc) can get the current userid. INZ(*USER) is the easiest, and always gets the current user.
Something this simple should work fine:
Code: Select all
dcl-s UserId char(10) inz(*user);
If the HTTP server is doing the swapping for you, then its not necessary to put it in a subprocedure.
QUSRJOBI will also work (though, its much more code, and I don't know why you'd use that instead of INZ(*USER) since its more work for you.) BUT, you have to be careful to be retrieving the CURRENT user, not the user component of the jobid. The current user can be found in format JOBI0600 at offset 91. I know this because, before IBM added the INZ(*USER) feature, I used this approach. (This was more than 20 years ago, now, and INZ(*USER) is what I've used since then.)
You can also use the CL RTVJOBA command, but again, make sure you are getting the CURRENT USER, not the user component of the job id.
A job on IBM i is named with 3 parts, the job name, user name and job number. So it looks something like 123456/SCOTTK/QTMHHTTP. This identifies the job to the system, an the user portion of this will never change during the life of the job. (If it did, the system would not be able to run the job anymore.) However, there is a separate field for the CURRENT user. Just make sure you are getting THAT rather than the part that identifies the job. Any of the methods (PSDS, RTVJOBA, QUSRJOBI, etc) can get the current userid. INZ(*USER) is the easiest, and always gets the current user.