This topic has been locked.
4 replies Latest Post - 2013-01-24T18:44:48Z by zdebug
Pinned topic RDZ 7.6 COBOL Source File Look Up Question
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
When debugging my COBOL program in RDZ, If the program that I specify in CICS DTCN command is not in the test libraries then it doesn't trap the program. Where and how do I specify the libraries in RDZ so that COBOL source is retrieved from the UNIT or PROD libraries? Please help. Thank You.
Updated on 2013-01-24T18:44:48Z at 2013-01-24T18:44:48Z by zdebug
Re: RDZ 7.6 COBOL Source File Look Up Question2013-01-22T09:50:45Z in response to SystemAdminI understand that you do not get the source program when the program is launch for debugging.
For debugging a program we need to prepare it for Debug Tool, meaning the TEST compile option and keep the sidefile or listing file produced in the compile step.
If the program has not been compiled for debugging or the listing or sidefile is not found then we will not get the cobol source in the source window. If the file is not found RDz prompts you to specify the place where the listing or sidefile is located.
When compiled for debugging you will have in the load module the pointer to the file.
Re: RDZ 7.6 COBOL Source File Look Up Question2013-01-22T15:48:10Z in response to SystemAdminAfter I setup DTCN in CICS to trap a Production version of the program which is compiled with the TEST (debugging) option, then how do I tell RDZ to pick up the production source. If the program is compiled in the test region then RDZ picks it up, but if the program is not in test library then RDZ doesn't trap that program at all. Please help! Thank you.
Re: RDZ 7.6 COBOL Source File Look Up Question2013-01-22T17:00:21Z in response to SystemAdminWhen you have compiled with the TEST compiler option, we also need to keep the SYSDEBUG file or the LISTING file.
If you are using Enterprise COBOL V4, we have the TEST(HOOK|NOHOOK,SEP/NOSEP,EJPD/NOEJPD) suboptions.
If we have specified the SEParate suboption then we a DD card in the compile step with DDNAME SYSDEBUG has to be specified, and the symbolic information for the debugging is written into the file.
If we have set the NOSEParate suboption then we need to code the SYSPRINT ddname to a permanent file.
When the load module is produced we have a pointer inside the load module pointing to a file.
When debug starts, it will read from load module this file and if found it will show the source program, if the file is not found then RDz will prompt you for designating the file name.
For example I have like the compile like this :
//RECH1234 EXEC PGM=IGYCRCTL,
//STEPLIB DD DISP=SHR,DSNAME=COBOL.V4R2.SIGYCOMP
//SYSIN DD DISP=SHR,DSNAME=SYS028.FANAL.SOURCE(COBCALC)
//SYSDEBUG DD DISP=SHR,DSNAME=SYS028.FANAL.SYSDEBUG(COBCALC)
as I have SEPARATE the SYSDEBUG is coded there. In the load module I will have a pointer pointing to SYS028.FANAL.SYSDEBUG(COBCALC)
Now I rename this SYS028.FANAL.SYSDEBUG(COBCALC) to SYS028.FANAL.SYSDEBUG(COBRRRR) and when the debug session starts
it does not find the file being pointed in the load module, so in the window I will type the new name
and I have the source in my debugging session.
Notice that you need the file.
I attach a small document, hope it helps.
zdebug 2700016UJX30 PostsACCEPTED ANSWER
Re: RDZ 7.6 COBOL Source File Look Up Question2013-01-24T18:44:48Z in response to SystemAdminSince we're talking about debugging in the production system, can you get Debug Tool up properly for any other transaction or other subsystems? Couple of things I'd check:
1) Can you get a simple batch debug job going with Debug Tool?
2) CEMT INQ SYSTEM should show the value of DEBUGTOOL as NODEBUG. I know it sounds backwards but DEBUG indicates CADP while NODEBUG is for DTCN.
3) Can you start a Debug Tool session for any transaction in the production environment?
Even if you can get the Debug Tool session up, you could enter SET DEFAULT LISTINGS command to specify the dataset that contains the production source. I'm assuming as you had already pointed out that you have the correct TEST compiler option with either the SYSDEBUG DD card or if not, the LISTING being saved in a permanent dataset, just as you were doing in the TEST environment.
Let us know how these steps work out.