Re: QUSER on ODBC requests

[bdietz@xxxxxx]

John one way to check and see if it is really QUSER, Change the password
for QUSER.  If QUSER is hardcoded into a DSN or some such thing this would
surley break it.  You should then be able to narrow down what is happening.


-------------------------
 Bryan Dietz
3X Corporation






                      "John Earl"
                      <johnearl@powertec        To:       
<midrange-l@midrange.com>
                      hgroup.com>               cc:
                      Sent by:                  Subject:  Re: QUSER on ODBC 
requests
                      midrange-l-admin@m
                      idrange.com


                      12/13/2001 04:01
                      PM
                      Please respond to
                      midrange-l






Walden,

Yeah, we checked this out.  All of our reports use the "Current
User" rather than the "Job User" to report on.  This customer is
having QUSER show up as the "Current User".  :(

jte

--
John Earl
johnearl@powertechgroup.com
The Powertech Group          www.powertechgroup.com
Kent, Washington, USA       +1 253-872-7788


----- Original Message -----
From: Walden H. Leverich <WaldenL@TechSoftInc.com>
To: <midrange-l@midrange.com>
Sent: Thursday, December 13, 2001 11:50 AM
Subject: RE: QUSER on ODBC requests


> 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:johnearl@powertechgroup.com]
> 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
johnearl@powertechgroup.com
> The Powertech Group          www.powertechgroup.com
> Kent, Washington, USA       +1 253-872-7788
>
>
> --
>