Q. What languages does Metamon Live (ML) support?
A. All versions of COBOL and Assembler, and any program at the object code level.
Q. Will ML work for batch DB2?
A. ML will work with any job that runs in a TSO region, be it an IMS BMP, DB2 batch, in-stream JCL or Procedures.
Q. Will ML work with optimized code?
A. ML supports optimized code.
Q. Will ML work with self-modifying code?
A. ML supports self-modifying code.
Q. Is ML just another knock-off of something like XPEDITER?
A. ML is not an interactive debugger and is not like any other batch debugger available. It works only in a transparent background mode and provides debugging options not available to interactive debuggers. It has none of the setup issues and can easily provide information of what a program is doing without having to know anything about the program, and it can run on production without audit concerns.
Q. Why would I even think of using ML?
A. The answer is simple; if you have a debugger but find yourself adding debug code (DISPLAY, WTO etc.) then we guarantee ML is for you.
Q. Can ML replace our interactive debugger?
A. There is not a single tool that provides all the answers. ML is another tool you should have in your software toolbox. However if your site only has COBOL and Assembler then ML could provide a cheap solution for all your batch debugging needs.
Q. We like our interactive debugger and have no problem with what it costs, why would we want to buy ML?
A. Fundamentally ML provides a statement execution log that shows detailed information of the executed statements and variables referenced by those statements. This provides a means to locate data associated with statements, something not possible with interactive debuggers, and this provides alternative debugging options. Another strong reason to use ML is for research of large programs where you don’t know where to start. Single stepping thousands of statements is very time consuming, whereas ML can trace an entire program providing a complete execution log in a little over the normal run time.
Q. Will ML tie up an initiator?
A. ML runs as part of the same job that runs the target program and does not stop the job execution. When the job completes ML completes.
Q. What can ML do that our interactive debugger can’t do?
A1. DISPLAY and WTO are still used as much today as they have ever been even though most sites now have an interactive debugger. ML provides a simpler solution than a DISPLAY, so when you think DISPLAY you should think METAMON.
A2. ML can be safely run against your production jobs. This enables problems to be fixed in-situ, vital for serious production problems that can’t be replicated in a development environment.
Q. What is Travel mode?
A. Travel mode means no SVC was installed and that means ML runs as a normal batch load module. The advantage of this is that ML can be installed in only a few minutes (removed in a few seconds) by anyone with TSO access. This mode has minor deficiencies over the SVC mode, but these aren’t typically an issue.
Q. Can I debug a sub-task, or a statically called program?
A. Absolutely any program, no matter how it is executed within a job step, can be debugged with ML. You don't need to know how it gets called or what the sequence in the calling chain is, you just need to know the program name. Indeed you can concurrently debug all the programs that run as part of a job step.
Q. Do I need to recompile my program?
A. You don’t need to recompile your program. ML can work with any existing program listing and can automatically retrieve your program listing from any source management tool, even one-off proprietary source management tools.
Q. Do I need a program listing?
A. A program listing is not required but it’s recommended. ML works with or without source code and can debug any program at the object code level that is compiled or assembled.
Q. How hard is it to learn ML?
A. A user can be up and running with ML in a matter of minutes. This is because there is virtually no setup; you just have to make some basic JCL edits. The directives and directive options can be used in full or short-hand and they utilize keywords that mean what they say. The simplest command (FT or FULLTRACE) will get you a complete program execution trace. To be fully functioning with ML you just need to work through a few real world problems.
Q. What is code coverage?
A. Code coverage shows what statements are executed, or not, when a program is executed.
Q. Why would I use code coverage?
A1. When adding new lines of code it is vital that proof is obtained that the new lines of code were executed in testing, and code coverage will provide this evidence as an artifact.
A2. Code coverage enables system and quality assurance testing to maintain a high level of confidence that enough code is being executed to validate changes being tested. Put another way, code coverage enables regression testing test data to be monitored so that it can be identified when the test data is not executing enough of the code.
A3. If you’re re-engineering an application you must create test records that execute all the executable code. Code coverage enables the programmer to see what code is not being executed and to create test records to execute the unexecuted code, or to document the code as dead code.
Home | Mainframe Debugging Tool | Testing COBOL & Assembler | Mainframe Testing | Software Demos
Competitive Analysis | Software Case Studies | About Metamon | Links | FAQs | Contact Metamon | Site Map