I don't quite understand what your are trying to do here... Could you
provide a bit more detail?
For example, if you can hack the vendor code to do a TELNET, why not
just retrieve the current profile name using RTVJOBA ???
??????
Kenneth
Kenneth E. Graap
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Hart, Doug - EI
Sent: Tuesday, August 12, 2008 1:33 PM
To: Midrange Systems Technical Discussion
Subject: RE: Profile Swap API
A hacking we will go.
Actually I just setup a CLP to telnet back to myself 127.0.0.1 (home)
and sign-on with the profile I need. The inlpgm takes them to the
display needed and then drops them down to SIGNOFF ENDCNN(*YES) and they
are right back to where they belong.
--
Please send all requests for Datacenter services to SFDCserv@xxxxxxx
Remember, I can't provide a precise answer to a vague question.
--
Douglas Hart - Principal Consultant
Level 3 - System i (AS/400) Technical Support ITT Corporation -
Enterprise Infrastructure (EI) Americas East Data Center - Seneca
Falls, NY
Voice: 315-568-7568 Doug.Hart@xxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, August 12, 2008 12:17 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Profile Swap API
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)
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the
sender.
Please note that any views or opinions presented in this e-mail are
solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments
for the presence of viruses. ITT accepts no liability for any damage
caused by any virus transmitted by this e-mail.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
