John, Just curious, are you sure they mean "authority of" and not that their audit stamps say "QUSER"??? All the "classic" methods of retrieving the user id (RTVJOB, RPG PSDS, etc.) will show QUSER not the profile from the swap. ------------ Walden H Leverich III President Tech Software (516)627-3800 x11 WaldenL@TechSoftInc.com http://www.TechSoftInc.com -----Original Message----- From: John Earl [mailto:firstname.lastname@example.org] Sent: Thursday, December 13, 2001 14:38 To: MIDRANGE-L@midrange.com Subject: QUSER on ODBC requests This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] We have a customer who is having a problem when they issue Client Access ODBC requests. It seems all of the transactions run under the authority of user profile QUSER. This is odd because even though the QZDASOINIT jobs start as QUSER, every time one of these prestart jobs receives an *SQLSRV request the job is supposed to swap the job's "Current User" to the user id that logged on to CAE. In every other implementation of CAE that I have ever seen, when a QZDASOINIT job gets an incoming ODBC request, it will swap the current user and proceed with the request. This site seems to leave the current user at "QUSER". I'm guessing it is a configuration problem. Does anyone know of an OS/400, ODBC or CAE configuration option that might cause all ODBC request to run under QUSER? It must have got preset somewhere???? The customer is using the Client Access Express, OS/400 V4R5 and Windows XP. Any thoughts? jte -- John Earl email@example.com The Powertech Group www.powertechgroup.com Kent, Washington, USA +1 253-872-7788 -- _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-Lfirstname.lastname@example.org Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.