RE: How to debug client server applications? -- MIDRANGE-L

Well IF you were writing your own server, you could log the connect reqeust
to the server with the client IP, Computer Name, User Profile, Date/Time
Stamp, Job Name/Number/User processing the request.  You can then query the
file to find the current locked request and work with that job.  Perhaps a
direct socks application to perform the SQL statement and return the data
instead of OBDC.  AS far as tracking IBM server for processing OBDC request,
see if there is an exit point that can trap and log the necessary available
data.

Christopher K. Bipes     mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst   mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.         http://www.cross-check.com
6119 State Farm Drive    Phone: 707 586-0551 x 1102
Rohnert Park CA  94928 Fax: 707 586-1884

If consistency is the hobgoblin of little minds, only geniuses work here.
Karen Herbelin - Readers Digest 3/2000


-----Original Message-----
From: Buck Calabro [mailto:buck.calabro@aptissoftware.com]
Sent: Friday, May 05, 2000 9:42 AM
To: MIDRANGE-L@midrange.com
Subject: How to debug client server applications?


Hello all!
We had a bizarre problem with a Delphi PC application that uses ODBC.  The
app was working great for years, then fell over Thursday.  No changes to the
app, the database or the AS/400.  No QSYSOPR messages, no object locks,
nothing unusual.  The app creates SQL statements to get info from the
AS/400.  The 400 services these requests in the QSERVER subsystem with one
of many QZDASOINIT jobs.  The job logs have messages similar to these:

CPIAD02 Servicing user profile XXXXXX.                         
CPIAD12 Servicing user profile XXXXXX from client xxx.xxx.xxx.xxx.
SQL7917 Access plan not updated.                                

These messages occur when the app works as when as when it fails.

The biggest hassle was trying to locate which server-side job is servicing
the particular client requests.  This is because all the QZD... jobs show up
in WRKACTJOB as QUSER, but internally they switch user profiles to match the
user ID of the client requester.

Ultimately, we spent hours displaying each of these QZDASOINIT jobs (there
are hundreds of them) to look for the user which was complaining of a locked
job.  The hassle is because there are _other_ Delphi apps that use these
server side prestart jobs, and they were running fine.  What a pain! 

Is there an easy way to find out what server jobs are servicing a particular
user profile?  WRKUSRJOB is useless as is WRKACTJOB.  I could use QUSLJOB
and QUSRJOBI and brute force search each job (which is what I'm starting on
now.) <grrrrr>

Buck Calabro
Aptis; Albany, NY
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---