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

Check out the following looong url:

http://as400service.rochester.ibm.com/s_dir/slkbase.nsf/fd9885170ed46f758625680b00020373/06176cce7bd8d917862565c2007cc9b4?OpenDocument&Highlight=2,odbc

It is knowledge databse document #8021834

There is a sample CL program. Not to user friendly but the steps are there
to create a better one.

Bryan Dietz

Buck Calabro

<buck.calabro@aptissof To:
MIDRANGE-L@midrange.com
tware.com> cc:

Sent by: Subject: How to debug
client server applications?
owner-midrange-l@midra

nge.com

05/05/00 12:41 PM

Please respond to

MIDRANGE-L

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

ps. The problem turned out to be locks on the SQL package. We killed all
jobs holding a lock on the package and the "lock up" went away. We suspect
that the PC locked up requiring a re-boot at the exact moment the optimiser
was trying to update the access plan in the package. This apparently
corrupted the package AND left it locked so that the next user couldn't
update the (now corrupt) access plan. Because of the paucity of tools, we
can only hypothesize. :-(
+---
| 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
+---

+---
| 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
+---