× 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.



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 ]
Is this from an application that is specifying user and password on the ODBC
connect strings?  It is possible to assign QUSER a password and use it to
sign on.  I tried it and got the following in the QZDASOINIT joblog.

Job 773172/QUSER/QZDASOINIT started on 12/13/01 at 14:49:48 in subsystem
  QSERVER in QSYS. Job entered system on 12/13/01 at 14:49:48.
ACGDTA for 773172/QUSER/QZDASOINIT not journaled; reason 1.
Servicing user profile QUSER.
Servicing user profile QUSER from client 172.16.150.195.

I was able to retrieve table information but was not able to view the
records and got these nasty entries in the joblog:
Error occurred in the OS/400 database server code.
Error occurred in the OS/400 database server code.
Error occurred in the OS/400 database server code.

What user does your exit programs see coming in?

Kurt

> -----Original Message-----
> From: John Earl [SMTP:johnearl@powertechgroup.com]
> Sent: Thursday, December 13, 2001 1:38 PM
> 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.