× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. December 2001

RE: QUSER on ODBC requests

Rob,

I'd sure like to see an acceptable solution to this one, myself...

Hardcode passwords in code..: no good at all...!  But have password keyed in
on every batch FTP and Domino app use...:  AIN'T GONNA HAPPEN...!

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of rob@dekko.com
| Sent: Friday, December 14, 2001 1:51 PM
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
|
|
|
| Everyone may rant on how hard coding user id's and passwords are
| a bad idea
| but there are some applications where this is a necessity.  Well,
| I suppose
| you could put them in a dataarea or some such animal but you get the same
| results.
|
| For example, you want to do some batch ftp between one system and another.
| Remember I said batch.  And you get this EDI process that runs unattended.
| I have no urge to hire someone to key in a userid and password.  If I did,
| I'd make the poor bugger click on icons or some other worthless
| application
| to look busy.
|
| Again,  I have a Domino application which gets data from the 400.  The
| people running this application sometimes don't even have iSeries
| passwords.  Are you saying that instead of just clicking on a button to
| retrieve the data, that now I should also pop up a box that prompts them
| for an iSeries user id and password?  Ludicrous!
|
| Rob Berendt
|
| ==================
| "They that can give up essential liberty to obtain a little temporary
| safety deserve neither liberty nor safety."
| Benjamin Franklin
|
|
|
|                     "Gary Monnier"
|                     <garymon@powertechg       To:
| <midrange-l@midrange.com>
|                     roup.com>                 cc:
|                     Sent by:                  Fax to:
|                     midrange-l-admin@mi       Subject:     RE:
| QUSER on ODBC requests
|                     drange.com
|
|
|                     12/14/2001 01:38 PM
|                     Please respond to
|                     midrange-l
|
|
|
|
|
|
| At least the hard coded user profile isn't set to expire.  Hard
| coding user
| profiles and passwords is a REALLY BAD IDEA.  Just think of all
| the special
| coding that could be done by hard coding user id and password.
|
| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of alan shore
| Sent: Friday, December 14, 2001 10:17 AM
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
|
|
| Something else I have just realized. If there are any applications with
| hard-coded user profiles and passwords, that means the system is
| set up NOT
| to expire passwords after a number of days. Yet another bad idea.
| Passwords
| SHOULD be set to expire after a number of days (we use 30) and to
| force the
| profile into an inactive state once 3 concurrent invalid attemps are made.
|
| >>> "Gary Monnier" <garymon@powertechgroup.com> 12/14/01 12:36PM >>>
| GOOD IDEA!  My experience has been that administrators, not to mention
| managers, want to know if applications have hardcoded passwords.
|
| --
| Gary Monnier               garymon@powertechgroup.com
| The PowerTech Group        www.powertechgroup.com
| 19426 68th Avenue South
| Kent, WA 98032
| Phone  253.872.7788
| Fax    253.872.7904
|
|
|
| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Kurt Goolsbee
| Sent: Friday, December 14, 2001 8:47 AM
| To: midrange-l@midrange.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:         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.
|
|
| _______________________________________________
| 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.
|
|
| _______________________________________________
| 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.
|

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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