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
Tech Software
(516)627-3800 x11

-----Original Message-----
From: John Earl []
Sent: Thursday, December 13, 2001 14:38
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

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?


John Earl                    
The Powertech Group
Kent, Washington, USA       +1 253-872-7788


This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: To subscribe, unsubscribe,
or change list options,
or email:
Before posting, please take a moment to review the archives

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.