Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
TRACE OF COBOL CODE ON MAINFRAME 2
- Thread starter sreesmart
- Start date
-
1
- #2
Hi Sreesmart,
The most common way I've seen of doing this is:
Set an area in working storage to contain the trace of say 500 bytes.
Decide how many characters you will need to identify each section or paragraph, for sake of argument let's say 10 chars. This will give you a trace of the last 50 entered. You can define this less or more according to your requirements.
On entering each section or paragraph move bytes 1-490 to position 11-500 and overwrite the first 10 bytes with the 1st 9 bytes of the section or paragraph name and a '/' making it easier to read. This can be done in a common section.
On abending, you can display the 500 bytes to the sysout and you will then have a reasonable trace.
Hope this helps
Marc
The most common way I've seen of doing this is:
Set an area in working storage to contain the trace of say 500 bytes.
Decide how many characters you will need to identify each section or paragraph, for sake of argument let's say 10 chars. This will give you a trace of the last 50 entered. You can define this less or more according to your requirements.
On entering each section or paragraph move bytes 1-490 to position 11-500 and overwrite the first 10 bytes with the 1st 9 bytes of the section or paragraph name and a '/' making it easier to read. This can be done in a common section.
On abending, you can display the 500 bytes to the sysout and you will then have a reasonable trace.
Hope this helps
Marc
-
1
- #3
Sree,
Marc's suggestion works great for an abend situation, but if what you want is a sense of where the program is going when it doesn't abend (i.e. test/development mode) try one of the following:
1) checkout COBTEST in the IBM Cobol User's Guide manual. There is both an interactive and batch version. Most likely you won't be able to use the interactive version (too many restrictions to overcome, uses too many resources), but the batch version can be quite powerful.
2) Set up a global declarative for entry to all paragraphs and in that display the "DEBUG-ENTRY" item (an IBM extension). This also requires a "WITH DEBUGGING MODE" on your SOURCE-COMPUTER clause. Just don't forget to remove this extra code when you release your program for production.
Good luck,
"Code what you mean,
and mean what you code"
Razalas
Marc's suggestion works great for an abend situation, but if what you want is a sense of where the program is going when it doesn't abend (i.e. test/development mode) try one of the following:
1) checkout COBTEST in the IBM Cobol User's Guide manual. There is both an interactive and batch version. Most likely you won't be able to use the interactive version (too many restrictions to overcome, uses too many resources), but the batch version can be quite powerful.
2) Set up a global declarative for entry to all paragraphs and in that display the "DEBUG-ENTRY" item (an IBM extension). This also requires a "WITH DEBUGGING MODE" on your SOURCE-COMPUTER clause. Just don't forget to remove this extra code when you release your program for production.
Good luck,
"Code what you mean,
and mean what you code"
Razalas
If you could persuade your management to invest in a product called Xpediter from Compuware you would be a happy programmer, as this allows you to run interactively displaying the source code and enabling you to interrogate variables, change flow etc. I think there's a similar product called Intertest, but it's too many years since I used that last and I can't remember who made/markets it.
Sree,
Marc's suggestion reminds me that my post is really only practical for a batch program.
Xpediter is really great if your shop has the money to license it, especially for a CICS programs, but COBTEST is part of the IBM cobol compiler package. So chances are you may already have it. "Code what you mean,
and mean what you code"
Razalas
Marc's suggestion reminds me that my post is really only practical for a batch program.
Xpediter is really great if your shop has the money to license it, especially for a CICS programs, but COBTEST is part of the IBM cobol compiler package. So chances are you may already have it. "Code what you mean,
and mean what you code"
Razalas
- Thread starter
- #6
Hi all,
Thanz a lot for ur suggestions, but I am not sure all of them were helpful. I'll need to make my requirement more clear.
I need to generate a Trace file ie A file containing all statements executed for a given set of inputs.
So Debug tools won't be of any help since they provide runtime debugging options.
Marc...ur suggestion looks the one that might be useful for me. Will it be applicable to generate a statement-by-statement trace?
--sree
Thanz a lot for ur suggestions, but I am not sure all of them were helpful. I'll need to make my requirement more clear.
I need to generate a Trace file ie A file containing all statements executed for a given set of inputs.
So Debug tools won't be of any help since they provide runtime debugging options.
Marc...ur suggestion looks the one that might be useful for me. Will it be applicable to generate a statement-by-statement trace?
--sree
Hi sree,
You can tailor the level of the output for however detailed you wish it to be. If you want a really in depth trace, then you will need to increase the size of the working storage variable in order to acter for the extra amount.
I must admit, that this method is only really used in an abend situation where you wish to see what happened leading up to the error. If you are wishing to see exactly what happened on a run, on a line by line basis, then I would imagine that the variable will blow it's size pretty quickly.
The sort of trace you are describing is only usually necessary if you have problems. What you might wish to consider is judicious use of the DISPLAY verb which will write messages to the job log. You could use this sparingly to determine the path a program takes eg:
IF WS-FIELD = 'A'
DISPLAY 'WS-FIELD VALUE WAS A'
PERFORM ........
ELSE
DISPLAy 'WS-FIELD VALUE WAS NOT = TO A'
PERFORM ........
END-IF
This, tho, is a little bit of hammer to crack a nut, and I personally would question whether you really need the level of trace that you are describing.
HTH
Marc
You can tailor the level of the output for however detailed you wish it to be. If you want a really in depth trace, then you will need to increase the size of the working storage variable in order to acter for the extra amount.
I must admit, that this method is only really used in an abend situation where you wish to see what happened leading up to the error. If you are wishing to see exactly what happened on a run, on a line by line basis, then I would imagine that the variable will blow it's size pretty quickly.
The sort of trace you are describing is only usually necessary if you have problems. What you might wish to consider is judicious use of the DISPLAY verb which will write messages to the job log. You could use this sparingly to determine the path a program takes eg:
IF WS-FIELD = 'A'
DISPLAY 'WS-FIELD VALUE WAS A'
PERFORM ........
ELSE
DISPLAy 'WS-FIELD VALUE WAS NOT = TO A'
PERFORM ........
END-IF
This, tho, is a little bit of hammer to crack a nut, and I personally would question whether you really need the level of trace that you are describing.
HTH
Marc
- Thread starter
- #8
Marc u still haven't understood my requirement. I am not using it to debug my cobol application. This trace file generated is required for another application.
I need a way to generate a line by line exec trace..ie the control flow. every statement executed should be part of my trace file.
I cannot modify this cobol code. Given a cobol code ....however big it is i need to generate this trace file.
cobol compiler has a TEST option....i know this is the way to go about it...but not sure how to...
if anybody's already done sth similar plz let me know
I need a way to generate a line by line exec trace..ie the control flow. every statement executed should be part of my trace file.
I cannot modify this cobol code. Given a cobol code ....however big it is i need to generate this trace file.
cobol compiler has a TEST option....i know this is the way to go about it...but not sure how to...
if anybody's already done sth similar plz let me know
Hi sree,
OK, now I know what you require, I would suggest that razalas use of COBTEST is going to be the option you need. Have a look at the FLOW and TRACE options of this, and see if they will be able to give you what you require (ie. a trace of a program, without changing the code)
Marc
OK, now I know what you require, I would suggest that razalas use of COBTEST is going to be the option you need. Have a look at the FLOW and TRACE options of this, and see if they will be able to give you what you require (ie. a trace of a program, without changing the code)
Marc
FWIW, when IBM announced their intention of getting rid of READY TRACE (they haven't yet) I wrote an ISPF Macro to insert DISPLAYs of each pgraph/sect name (including exit pgraphs) in each pgraph in the program.
When the program runs, each pgraph entered during program execution is displayed in the SYSOUT listing - a poor man's ready trace. Three ISPF commands are used to delete the displays from the program when no longer needed.
Regards, Jack.
When the program runs, each pgraph entered during program execution is displayed in the SYSOUT listing - a poor man's ready trace. Three ISPF commands are used to delete the displays from the program when no longer needed.
Regards, Jack.
- Thread starter
- #11
Hi slade...,
Would you mind sharing that utility- A poor man's ready trace. I would be grateful if you could do that.
As Marc suggested I'm trying out the compile and run-time TEST option to generate trace. But I still haven't got about getting it done.
Thanks a lot all you guys...,
--sree
Would you mind sharing that utility- A poor man's ready trace. I would be grateful if you could do that.
As Marc suggested I'm trying out the compile and run-time TEST option to generate trace. But I still haven't got about getting it done.
Thanks a lot all you guys...,
--sree
Hi Sree,
I see that you need a TRACE of each stmt executed. Neither readt trace or my command will provide that. They oly trace pgraph/section names.
My advice is try Look for the "Ask the experts" section on the home page.
Click on "MORE CATEGORIES", then look for "> Programming--COBOL, PL/I and LE for S/390" then click on "( Pose a Question)".
The expert is Tom Ross from IBM. Be specific about what you've done or you'll get an answer like "try COBTEST". Tell him that you've done "this" and gotten "that" error msg or "the other" abend code, what did I do wrong?, etc.
Regards, Jack.
I see that you need a TRACE of each stmt executed. Neither readt trace or my command will provide that. They oly trace pgraph/section names.
My advice is try Look for the "Ask the experts" section on the home page.
Click on "MORE CATEGORIES", then look for "> Programming--COBOL, PL/I and LE for S/390" then click on "( Pose a Question)".
The expert is Tom Ross from IBM. Be specific about what you've done or you'll get an answer like "try COBTEST". Tell him that you've done "this" and gotten "that" error msg or "the other" abend code, what did I do wrong?, etc.
Regards, Jack.
- Status
Similar threads
- Locked
- Question
- Locked
- Helpful tip