how to debug QZDASOINIT job ?
Grzegorz Goryszewski
I want to get more info about odbc jobs running on my as400 (V4R4 with
cum 00147). I mean for example SQL query string and so.
I've tried to look into QZDASOINIT joblog but there was not enought info for
me (only start time, usrprofile and client IP).
I've tried to debug job with STRSVRJOB (QZDASOINIT JOB) and then STRDBG ,
but I don't know what next ? Set brkpoint or something ? Can anyone please
tell me how to debug ODBC jobs running with QZDASOINIT ?
The last thing I had was PRTSQLINF for *SQLPKG object witch showed me option
12 WRKJOB cmd's.
The spoolfile which I've got includes appropriated info but that info was
not current for the actually running ODBC job, I mean it was for earlier
query (somekind of cache or what)?
Any ideas? Regards.
Grzegorz Goryszewski
--
Grzegorz Goryszewski
s...@domar-sc.com.pl
Thoma...@worldnet.att.net
cause an increase in the logging level, but if that isn't enough detail
for you, it's not likely you could debug the IBM ODBC processing jobs.
You can debug specific programs, etc., using STRSRVJOB and STRDBG, but
this is usually used in order to debug a user-written AS/400 program
running on the 400 exclusively.
The next place I would go would be an ODBC log function on the PC, in
order to see what is passed between the PC and AS/400. This can be
helpful. You can start logging (or tracing) using the ODBC Data Source
Administrator on the PC. After that, perhaps a communications trace on
the AS/400, but they're really detailed, quite long, and nasty to try
and read. I've not found them particularly helpful in most problem
debugging.
On the PRTSQLINF, it is a sort of cache. It will show you the access
plans for queries executed through a specific app from the PC (or
AS/400 program), but it won't help much for purely ad-hoc queries off
the PC. For PC applications, it is controlled through the extended
dynamic support setting on the IBM ODBC driver. It is used in order to
speed subsequent executions of the same query with different
parameters, sort of if you had prepared an embedded SQL statement using
parameter markers.
Thomas Kine
In article <9343kj$lok$1...@news.tpi.pl>,
Sent via Deja.com
http://www.deja.com/
Karl Hanson
The QZDASOINIT jobs are prestart jobs, so they are normally
recycled/reused. You could (temporarily) use CHGPJE MAXUSE(1) so each
job is only used once. STRSRVJOB/STRDBG will cause DB2/SQL to log
additional information messages in the job log, that may (?) help you
understand the processing. This happens w/o additional debug commands
(breakpoint/trace). Note that afterwards you likely want to revert back
to previous MAXUSE value for the PJE, to get the benefit of reusing jobs
again.
--
Karl Hanson
Thoma...@worldnet.att.net
What I normally do is:
1) connect to AS/400 w/ODBC
2) on AS/400 WRKOBJLCK XXX *USRPRF where XXX is the user profile name
being used in ODBC
3) Look for the locked QZDASOINIT job shown on the display above
4) STRSRVJOB and STRDBG on the QZDASOINIT job
5) Run the ODBC SQL statement(s) in question
6) Display the job log (option 10 on the WRKJOB display) for the
QZDASOINIT job (while the ODBC sesssion is still attached). There will
be detailed information about the SQL executed.
Alternatively, you can send in the STRDBG command through ODBC, but you
may need to also send in a CHGJOB LOG(4 00 *MSG) LOGCLCMD(*YES) in
order to get a detailed job log output. You would send in these
commands through a call to stored procedure QCMDEXC. If you need an
example of call QCMDEXC through ODBC, you can find it in the AS/400
Client Access for Windows 95/NT ODBC User's Guide (search for 'qcmdexc'
in this book). This technique avoids the need to STRSRVJOB and the
need to catch the job while it is executing on the AS/400.
Karl Hanson
>
> Alternatively, you can send in the STRDBG command through ODBC, but you
> may need to also send in a CHGJOB LOG(4 00 *MSG) LOGCLCMD(*YES) in
> order to get a detailed job log output.
You will get more detail (for each message) using LOG(4 00 *SECLVL).
This is useful in a printed job log (ie it does not affect WRKJOB option
10).
--
Karl Hanson
Richard P. Klein
Read the manual for this, an outfile will be created and you can place a
nice LF on it to get a view of all the SQL statements.
If you want to have the LF feel free to contact me
Richard
"Grzegorz Goryszewski" <gre...@pharmag.com.pl> wrote in message
news:9343kj$lok$1...@news.tpi.pl...
Thomas
If you need specific details such as the actual SQL string, you might
need to register an exit program against the server. Most available
details for this are in the Host Servers guide. Debug and STRDBMON are
decent alternatives for specific needs.
Or maybe you can download and install our free PowerLock/SE Intrusion
Detection package ( http://www.400security.com ) that tracks ODBC
requests (among others). The exit programs provided with it will log the
SQL strings and you can examine them later. This would be more helpful
on an ongoing basis.
Tom Liotta
In article <9343kj$lok$1...@news.tpi.pl>,
"Grzegorz Goryszewski" <gre...@pharmag.com.pl> wrote:
--
Tom Liotta, AS/400 Systems Programmer
The PowerTech Group, Inc.; http://www.400security.com
...and for you auto-things out there (NOT for people):
<a href="http://www.monkeys.com/cgi-bin/wpoison/wpoison.cgi">look!</a>