That’s not entirely true. You can use ‘Job user’, but the user will usually be QUSER and the results will include everybody running ODBC/JDBC jobs — and possibly more.

Tom

Please clarify. Could not find the statements? …or could not find a way to see the statements? Were any statements shown at all for you?

Note that for ODBC/JDBC, the monitor must track ‘Current user’. The ‘Job user’ will not work. Also, any filters may cause statements to be excluded from the list.

I also tried running the below command which creates a dump of the SQL Statements run through a Particular ID.

That is only used by interactive SQL, the STRSQL command. It’s used just for STRSQL to be able to show you where you left off in previous uses of the command. If you don’t save your session when you exit, the command won’t store anything there.

But the SQL monitor will capture the statements even if you don’t save your STRSQL session.

Tom

I also tried running the below command which creates a dump of the SQL Statements run through a Particular ID.

DMPSYSOBJ OBJ(ISQLSTQLIKVIEW*) CONTEXT(QRECOVERY) TYPE(19) SUBTYPE(EE)
Command failed with error as No objects printed because no objects found.

You might create a new library just to hold the collected data. Specify that library for ‘Schema for data:’. You probably want a ‘Detailed’ collection. Shouldn’t be a need to collect anything but ‘User’ actions, but there’s no way to know from here.

Regardless, set one up for yourself first, just to get a feel for it. After it starts, use Navigator to view the content of a table or two, try ‘Run SQL scripts’ to run a query or two.

Then end the monitor and select it for analysis. Look at what it gives you so you’ll have an idea if it suits your need.

Tom