----------------------<snip>-------------------
Dude... check out the GTRACE macro, <http://preview.tinyurl.com/2wfyrk>
GTRACE is the GTF interface and even though it is documented in the Auth
guides, the MC interface does not require authorization AT ALL.
The down side is that all other aspects of GTF require some local
authority, to start GTF traces, and to get access to the trace dataset
and/or IPCS to process the output. In a lot of places those are
practically impossible for application people to get, but that's a site
choice. If you had a gnarly problem you might be allowed access.
But if you just want first class real time debugging and you don't have
your own VM sandbox... Dave Cole's XDC is the only game in town.
--------------------<unsnip>-----------------------
I'm very familiar with GTRACE, having used it, and imbedded it within
various SMF exits that I've written and installed. But I don't believe
that a user (That's a four-letter word, I know.) should have to have the
authority to use such tools to debug what is essentially an application
program. I've looked at XDC, but it doesn't seem to lend itself easily
to imbedding in an application that might very well be a "OEM Software
Product". It appears to be a great debugging tool, but I question the
advisability of imbedding it in a fee-based product.
If I execute a GTRACE macro in a product and GTF isn't active, it
returnes directly to the code that executed it. I'd like to see a way to
"redirect" it to my code, with a parm list similar (not necessarily
exactly the same, but along the lines) to a SPIE/ESPIE exit, where I can
examine the instruction and the code immediately after it and from that
determine what storage areas may need to be displayed, etc.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
