[See also issue 13439629-1: TWO CSECTS WITH SAME NAME.]
We need to be able to debug cases where there are two different programs with the same CSECT name. Currently InterTest Batch can not handle this. If you try to monitor a program name, it assumes it is the first program that is executed with that name.
The specific situation is that we have two load modules: Module1 and Module2. Both modules contain a program "Prog". The CSECT name is the same in both cases (Prog), but they are completely different programs. For discussion purposes, we will call them Prog1 and Prog2.
Prog1 and Prog2 may be the same language or different languages. That is, they could be both Assembler, COBOL, or any combination. If they are the same language, they will be different sizes and compile dates.
In my situation, I only *need* to debug one of the two programs (specifically Prog2). That is, I do not *require* the ability to debug both Prog1 and Prog2 in the same session. I will have a PROTSYM member for Prog2.
So I need to be able to monitor Prog2, set breakpoints, etc. Prog2 may be the first monitored program encountered in the test.
When InterTest displays a source screen, there should not be any confusion about which program is being executed (Prog1 or Prog2). For example, if InterTest only supports debugging ONE of the two programs in a test, and my PROTSYM entry is for Prog2, then it should not display "Prog" source when the PSW is actually in Prog1.
This situation needs to be supported in all IMS environments (MPP, DLI, BMP) in both Foreground and Batch Link.
When I talked to CA about this in 2004, their idea was for a way to allow the user to assign an "alias" name for a MODULE:CSECT, and then the qual commands, breakpoints and UI displays would relate to the alias name. But I don't know how that would work if Prog2 is the only program you want to monitor -- you couldn't enter its name as the program to monitor, but neither could you enter the alias name, since you couldn't assign the alias until you got into the test session.
The only work-around we've found for this problem is to re-link the modules, renaming the Prog1 CSECT to something else. That isn't ideal, since a feature of InterTest is that you should be able to debug production code without modification.