Re: QUSER on ODBC requests -- MIDRANGE-L

The Get and Set Password API's would help here - but thanks for
the warning.   Just changing the password could really make a
mess.

jte

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


----- Original Message -----
From: Kurt Goolsbee <K.goolsbee@pentasafe.com>
To: <midrange-l@midrange.com>
Sent: Friday, December 14, 2001 08:47 AM
Subject: RE: QUSER on ODBC requests


> This message is in MIME format. Since your mail reader does not
understand
> this format, some or all of this message may not be legible.
> --
> [ Picked text/plain from multipart/alternative ]
> BAD IDEA.  If you change the password for QUSER and there are
applications
> with user and password hardcoded then they will stop working.
Clearly you
> don't know if this is the case so how are you going to set the
password
> back?
>
> > -----Original Message-----
> > From: bdietz@3x.com [SMTP:bdietz@3x.com]
> > Sent: Friday, December 14, 2001 6:16 AM
> > To: midrange-l@midrange.com
> > Subject: Re: QUSER on ODBC requests
> >
> >
> > 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
> > >
> > >
> > > --
> > >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> _______________________________________________
> 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-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>