Logging in QRWTSRVR jobs

[Jonathan Ball]

We have a remote process (z/OS) trying to do a DB2 CONNECT to an IBM i
system (6.1). I can find instances of CPI3E34 ("DDM job
xxxxxx/QUSER/QRWTSRVR servicing user XXXXXXXXXX on ...") in the job log,
but there is nothing to show what statements the remote process tried to
run, and their results (failure).

Is there an easy way to change the logging level only for that user
profile to capture a job log and/or other useful information?

[CRPence]

On 23-Sep-2015 12:42 -0600, Jonathan Ball wrote:
> We have a remote process (z/OS) trying to do a DB2 CONNECT to an IBM
> i system (6.1). I can find instances of CPI3E34 ("DDM job
> xxxxxx/QUSER/QRWTSRVR servicing user XXXXXXXXXX on ...") in the job
> log, but there is nothing to show what statements the remote process
> tried to run, and their results (failure).
>

Joblogs may include CL-command-statements, but SQL-statements are not
logged; the application must log those. Otherwise the iNav Database
feature [for SQL statement cache, et al] can be used to review the
statements, or the Database Monitor feature can log the SQL statement
activity.

>
> Is there an easy way to change the logging level only for that user
> profile to capture a job log and/or other useful information?

The DDM exit point could be used; a user-exit coded to effect
whatever, to perhaps include Change Query Attributes (CHGQRYA), Start
Database Monitor (STRDBMON), Start Job Trace (STRJOBTRC), and\or
whatever else. I do not recall if there is a DRDA-specific exit.

IIRC the DDM Exit capability is part of [a parameter of] the Change
Network Attributes (CHGNETA) command. For more possibilities [including
use of the Database Open Exit QIBM_QDB_OPEN], use the Work With
Registration Information (WRKREGINF) to see what Exit Points might
relate; notably, if any QIBM_QRW* are listed.

If available, I generally have the DRDA requester\requesting-app
modified to call a stored procedure that sends and awaits a reply to an
inquiry so I can start debug and trace. Or Service Entry Point (SEP)
debug can be used for a program known to be invoked by the DRDA
requester; apparently that can be limited to a specific user name
[though I have never used that capability], according to the Debugger
help for the sbreak feature.

--
Regards, Chuck

[Rudy Canoza]

On 9/24/2015 1:48 PM, CRPence wrote:
> On 23-Sep-2015 12:42 -0600, Jonathan Ball wrote:
>> We have a remote process (z/OS) trying to do a DB2 CONNECT to an IBM
>> i system (6.1). I can find instances of CPI3E34 ("DDM job
>> xxxxxx/QUSER/QRWTSRVR servicing user XXXXXXXXXX on ...") in the job
>> log, but there is nothing to show what statements the remote process
>> tried to run, and their results (failure).
>>
>
> Joblogs may include CL-command-statements, but SQL-statements are not
> logged; the application must log those. Otherwise the iNav Database
> feature [for SQL statement cache, et al] can be used to review the
> statements, or the Database Monitor feature can log the SQL statement
> activity.

> [...]

The QRWOPTIONS data area provides just what I need:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1017342
http://www-01.ibm.com/support/docview.wss?uid=nas8N1011473

This is a 48-byte character data area created in QGPL that allows a
substantial amount of information to be captured. It can help
automatically get trace information, too, but that requires adding reply
list entries and stopping/restarting the prestart jobs, and I didn't
want to do all that.


--

Any serious look at the history of human beings over the millennia shows
that the species began in poverty. It is not poverty, but prosperity,
that needs explaining. Poverty is automatic, but prosperity requires
many things -- none of which is equally distributed around the world or
even within a given society.

Thomas Sowell