GOOD IDEA! My experience has been that administrators, not to mention managers, want to know if applications have hardcoded passwords. -- Gary Monnier firstname.lastname@example.org The PowerTech Group www.powertechgroup.com 19426 68th Avenue South Kent, WA 98032 Phone 253.872.7788 Fax 253.872.7904 -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Kurt Goolsbee Sent: Friday, December 14, 2001 8:47 AM To: email@example.com 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: firstname.lastname@example.org [SMTP:email@example.com] > Sent: Friday, December 14, 2001 6:16 AM > To: firstname.lastname@example.org > 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: > <email@example.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 > firstname.lastname@example.org > The Powertech Group www.powertechgroup.com > Kent, Washington, USA +1 253-872-7788 > > > ----- Original Message ----- > From: Walden H. Leverich <WaldenL@TechSoftInc.com> > To: <email@example.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: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. _______________________________________________ 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-Lemail@example.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.