On Tue, 9 Oct 2007 11:26:51 -0500 Rick Fochtman <[EMAIL PROTECTED]> wrote:
:>>:>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.) So why doesn't the very straightforward solution of a DEBUG parm and calls to debug logic in the code work? You can have multiple debug flags (routine entry exit, record read, etc.). -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
