A problem in InterTest Batch is that you can only start a test with a program name, either via the Foreground execution control panel or a step executed by a batch job. This makes it difficult and in some cases impossible to debug programs that are executed in TSO and ISPF, such as ISPF dialogs, programs that are part of CLIST or REXX functions, etc. The only way to test such a program is to find some way to execute it starting with a program.
This is because you have to already be in ISPF to start InterTest, and the program under test has to be a subtask of InterTest:
MVS -> TSO -> ISPF -> InterTest -> invoked program -> other programs
For example, let's say you have an ISPF application that is normally invoked from some series of menu choices starting with the ISPF primary option menu. InterTest doesn't have a way to select an ISPF menu, so to start the application you need to figure out a way to get it called from a program.
Similarly, if you have a program that is normally invoked from an exec, you need to find a way to invoke it directly with all of its normal execution state intact.
In some cases it is impossible to work around the problem. One case is if you want to debug a Browse, View or Edit Interface (e.g. EDIF) program. This doesn't work because since ISPF is already started, the Edit task that invokes your program was already started before InterTest. It can't intercept the call to your program.
What we need is support for testing ISPF dialogs. There are several approaches that could be taken:
- Provide a way to start InterTest before ISPF. (MVS -> TSO -> InterTest -> ISPF). The advantage here is that since InterTest starts first, anything that runs in ISPF should be able to be debugged.
- Provide a Foreground execution panel that allows specification of ISPF selection panels and Commands, similar to the ISPF Dialog Test Functions invocation panel. While this won't solve the EDIF problem, it has the advantage that it would be user friendly.
- Provide a special InterTest program that when entered in the Foreground program name, would then invoke a panel to allow specification of ISPF menus and commands. This is similar to #2 but not as user friendly; you'd have to know the special program.
- Provide a completely different InterTest Batch invocation clist (e.g. in place of MRxxCLST) that supports ISPF dialog debugging.
Note: What I'm describing here are features of competitive debuggers.
[Note: See also issue 21961826 01 - EDIF NOT INTERCEPTED; I can't view it anymore so I don't remember what was said there.]
(Edit 10/11/2018: bad grammar)