If an application is coded with RTVJOBA USER() vs RTVJOBA CURUSER(), then perhaps that application was also coded using RTVJOBA without library qualification. If so, then the request being made is actually *LIBL/RTVJOBA. That means a Trojan Horse *CMD object could intercept the command invocation to return the desired value. Presumably it was verified that RTVJOBA vs QUSRJOBI was being used by the application, and from where.? If not, that should be done via debug or trace. before pursuing that approach.

The simplest invocation [i.e. only USER() coded] could be tested first, adding parameters until the invocation by the application can function; i.e. probably need not code all of the command parameters for the Trojan version of RTVJOBA. The program as CPP for a TROJAN/RTVJOBA *CMD, where CHGSYSLIBL TROJAN has been performed previously, would need to invoke the QUSRJOBI or similar to get the current user value, which would then be returned for the USER() parameter.

Of course having said all that, I must add that I do not recommend this approach. I am only suggesting it may be a manner to resolve the noted concern. IMO the correct path to follow, is to get the 3rd party package to /correct/ their code, if that application should be using the current user instead of the job user.

Regards, Chuck

Hart, Doug - EI wrote:
I'm using the profile swap API's but have this issue and hope someone
has a work around.

After doing the 'swap' if a RTVJOBA USER(&USER) the &USER = the
original profile not the new swapped to profile name. I have a 3rd
party package that must be pulling the 'user' this way and I need it
to 'see' the new targeted profile name. Since I can't change the
vendors pgm I need to force the user ID more than what the API does.
Wish I could just use RTVJOBA CURUSER(&CURUSER) but I don't have the
vendors code.

One idea is to telnet back to the same box something like this and
the new 2nd job will be the right user.
TELNET RMTSYS('127.0.0.1') RMTUSER(<2nd profile>) RMTPWD(&pw)
RMTPWDENC(*NONE) RMTINLPGM(test)

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.