---------------------<snip>--------------------
:>I write
:>almost all my code in Assembler and the lack of debugging tools that I
:>can imbed into a product is one of my "pet peeves".
How would you like to imbed it?
-----------------------<unsnip>-------------------------
I don't really care whether it's via SPIE/ESPIE, STAE/ESTAE, or some PC
mechanism, as long as it's a reasonably fast mechanism. I suggested a
"fast path" via SPIE/ESPIE simply because I figure that a PC interrupt
should be fairly easy to trap through the SPIE/ESPIE mechanism in
Program Interrupt FLIH. It should NOT be a mechanism that requires
program authorization via the classic mechanism, thus available to the
"general case" application programmer. Even using the TRAP instructions
wouild be acceptable, if there's a mechanism to examine registers and/or
inline parameter lists and make approproate return adjustments to bypass it.
----------------------------------<snip>---------------------------
How would you expect that the end user would enable it?
--------------------------------<unsnip>---------------------------
A PARM field, a control statement, or the inclusion of a special DD
statement; to me, any one of these would be acceptable. Obviously, each
has advantages and drawbacks but these can be taken into consideration
during the code development/generation process.
I'm currently working on a new version of the ARCHIVER (CBT File 147)
and because of the "nature of the beast", I can't always visualze all
the possibilities that might lead to abends. But if someone is using it
and encounters a problem, being able to have him turn on a "trace/debug"
mechanism and recreate the problem would be of great advantage in
solving problems and improving the product.
I'm also working on tools for RACF reporting which I hope to market for
a very modest fee, and tools that help me debug newly-encountered
conditions would be of inestimable value, to me and to my prospective
customers. And let's face it, security is going to be a major concern in
computing for the foreseeable future, both in maintenance and auditing.
In my experience, (which I grant freely is NOT all-encompassing,)
reporting and auditing tools in this area are not optimal, to say the
least. (I remind the list of a previous post concerning a RACF auditor,
unnamed, who bought me a number of steak lunches, because of his lack of
experience and IMHO adequate training. Not his fault, but rather a
reflection of industry's attidute toward security at the time.)
----------------------------------------------------------------------
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
