Solved

ODBC "Connections" and Submintting Jobs from a PC

Posted on 2004-03-26
5
655 Views
Last Modified: 2011-04-14
I have been useing ODBC Connections for a long time.  One thing that has always buged me is the "UserName" is always QUSER.

Well I have lived with it.  Until now.
Today I started calling AS/400 Programs from inside MS Acess.
Basicly I call a CL that submits a RPG program.
My issue is that the "Username" the job is running under is QUSER and not the person who signed in to the AS/400 when prompted to run the job.

Is there any way to change this??
0
Comment
Question by:ScottParker
  • 3
5 Comments
 
LVL 33

Expert Comment

by:shalomc
ID: 10696527
Are you concerned about security, or does your application need the actual user name?
0
 
LVL 14

Expert Comment

by:daveslater
ID: 10697993
Hi

the easy way is to pass the user id as a parm to the cl, then use the user id parm on the smbjob command.

Dave
0
 
LVL 33

Accepted Solution

by:
shalomc earned 500 total points
ID: 10698067
Hey,
try

DCL VAR(&CURUSER) TYPE(*CHAR) LEN(10)
RTVJOBA CURUSER(&CURUSER)

to find who the real user is.

ShalomC
0
 
LVL 6

Expert Comment

by:dedy_djajapermana
ID: 10703547
Hi,

AFAIK, the job name is always under QUSER, however, inside the job, there's a step that call some API to "change" the job state to run under the submitting user (although it still appear as running under QUSER job).
I may be wrong, i haven't tested it, but if you want to make sure, try to explicitly exclude QUSER from the file that your RPG program referring to (i think it will run successfully), and try to explicitly exclude the submitting user from the file and run it again (this time it should fail).
Sorry that i didn't have time to test it, I'll test it tomorrow if you're willing to wait.

regards,
dd
0
 
LVL 33

Expert Comment

by:shalomc
ID: 10705858
Hey,
Although the job name in wrkactjob is QUSER, the job actually runs under all the privileges and authorizations of the logged in user. If you look at the system data structure in RPG, you will see the logged in user rather than QUSER.

In a CL, you should check the CURUSER attribute of a job (like I indicated previously).

Therefore, there is no security breach And there is a way for the application to find out who the logged in user is.

ShalomC
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Ruby - Rails - iSeries 3 246
3-hosted iSeries client partitions - how to backup to single tape libaray 2 59
Reading variable length EBCDIC in SAS 9 96
Monitor SQL Insert 8 39
What does UTC stand for?  “Coordinated Universal Time” – Think of this as the true time on Planet Earth that never changes with the exception of minor leap seconds here and there to account for the changes in the planet's rotation.   What does th…
If your vDisk VHD file gets deleted from the image store accidentally or on purpose, you won't be able to remove the vDisk from the PVS console. There is a known workaround that is solid.
This tutorial demonstrates a quick way of adding group price to multiple Magento products.
This is a video describing the growing solar energy use in Utah. This is a topic that greatly interests me and so I decided to produce a video about it.

932 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now