Re: GENERATE_SQL(): Was: Learning SEU, Source members . . .

As to the job log - there is now a user-defined table function that gives you the job log in a table - it has ordinal numbers for each message - not sure you knew about this.

select * from table(qsys2.joblog_info('*')) a

will give you all the messages that the job log still has for your current job - replace the asterisk with a full job specification to get the log for another job.

As with any table, you can filter this in a WHERE clause for message type.

As to association with an action - if the action is from a command request, it might be in the log as a REQUEST type. If not, we usually go for the last ESCAPE message and maybe some diagnostics before that.

It might be possible - with a variation of an existing technique - to send a pair of bracketing messages, before and after whatever you are doing - messages have message keys - that can get a little complicated, and it seems you could easily over-engineer this stuff. As could I!

It appears the message key is not available through this UDTF.

But maybe this can be useful. Also, it's worth looking at the message=handling information in Work Management reference and Command Language reference, available in KnowledgeCenter.

Cheers
Vern

On 10/19/2015 12:08 PM, Justin Dearing wrote:

On Mon, Oct 19, 2015 at 12:33 PM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Personally, I'd just you iNav to right click on an object and Generate SQL.

IBM provides the API so that other tools, for instance my CMS system, has
access. But I don't see any advantage to manually calling the API vs.
having a UI of some sort call it.

I don't have client access installed, and I'd rather work with SQL
workbench at least at the moment.

Yes, I agree, the API is not good for adhoc calling. I'd like to write a
wrapepr around it that calls this API, checks the system catalog views to
ensure the object and source member exists and return any joblog messages
get created. This way I can write CREATE TABLE statements in my SQL exditor
of choice, and them "commit them" to the source member when I am ready.

So, that least me to a more generic version of my last question. If a SQL
statement fails, whats the best way to associate that with particular rows
in the joblob? Capturing timestamps before the message, or can i get the
rowid somehow?