Idea Details

Debugging two CSECTs with the same name

Last activity 06-08-2018 10:26 AM
michael.schmitt's profile image
11-10-2016 10:35 AM

[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.


06-08-2018 10:26 AM

In my application the vast majority of cases where we run into this problem are with COBOL programs.

06-08-2018 01:36 AM

Hello Michael,


another good idea to improve debugging experience. When discussed with the development team, we realized this kind of enhancement would required significant code change. If I compare it with the immediate benefit, I would rather invest the time of InterTest developers into something with bigger additional value.


For example we work on a feature that should make this possible at least for COBOL programs as a "side effect". The feature it self should make the debugging experience better. If you would want to hear more, please do not hesitate to reach back.


Kind regards, petr

11-14-2016 11:15 AM

That won't work in our environment, because the program that calls Prog2 is Prog1.

11-10-2016 07:10 PM

Michael, I may have a workaround that would give you the ability to debug your duplicately-named program.  I'm wondering if it's possible for you to also monitor the program that calls your duplicately-named csect?  If so, then I have a suggestion that might just work for you. 


When setting up the session, don't ask to monitor the program with the duplicate name.  Instead, ask to monitor the program that calls it.  Then set a breakpoint on the statement that calls the program you really want to debug.  When you get to that breakpoint, type Q program-name where program-name is the name of the program you want to debug, the one that you're about to call.  The Q (or Qualify) command will establish monitoring for that program.  It will display a choice of listings to choose from, just choose the one that matches your program.  Then type CS to position the display back to the calling statement and type NEXT to single step into your subroutine.  I think you should be able to debug the duplicately-named subroutine this way.


I agree that being able to qualify a monitor request by load module name would make this easier.  I'm wondering if other InterTest customers might benefit from the same type of enhancement.  But meanwhile I'm hoping this suggestion will enable you to debug your application.