IBM Mainframe Forum

Hi,

In my recent execution of a cobol program I found that there is a never-ending loop in the cobol program.

I checked it manually but I'm confused in the middle.

Is it possible to check the cobol source code step-by-step just like in "C language" ??
Which tool can be used for effective working ??
And also...
Is there any trick and tip to find the infinite loop just like that ???

please post the tutorial link for this.

Thanks,
Raju.

There are some debuggers, such as Debug Tool from IBM or Xpediter from Compuware, that allow you to execute a COBOL program statement by statement. However, whether or not your site has any such product installed is not something we can tell you. You need to talk to your site support group, team leader, or coworkers to find out what, if any, debugger is installed at your site. In the absence of a debugger, finding an infinite loop is usually done by setting a low CPU limit, altering the code to include displays at appropriate points, and running the code to see where the loop starts.

Ashok Raju wrote:Hi,

In my recent execution of a cobol program I found that there is a never-ending loop in the cobol program.

I checked it manually but I'm confused in the middle.

Is it possible to check the cobol source code step-by-step just like in "C language" ??
Which tool can be used for effective working ??
And also...
Is there any trick and tip to find the infinite loop just like that ???

please post the tutorial link for this.

Thanks,
Raju.

There are a host of mainframe debugging tools; Binging that phrase results in 746,000 hits (of course, not every reference is to a separate tool).

To the best of my knowledge, however, all are proprietary, pay-for-play items. If those cheap sons-of-fifty-fathers that you have the misfortune to work for provide neither a debugging tool nor training in using one, you have unlikely to find them on your own save at ruinous cost.

Robert,

We have Xpediter.
Thank you. I'll search for the manual.

Akatsukami,

We have perfect mainframe system with all tools available.
I'm a project trainee now.

Ashok Raju wrote:Akatsukami,

We have perfect mainframe system with all tools available.
I'm a project trainee now.

That being the case, oughtn't you to get your training from the project or your employer?

We have perfect mainframe system with all tools available.

Employer might be reading...

Usually looking at the program will reveal the possible places for infinite loops. Any loop you have coded (or someone else has if you are on maintenance/support). Look at the conditions that allow these loops to exit. Ensure that the loop-control variables are changing how the loop expects them to, including that nothing is changing them in a paragraph'/section that is being performed. Looking for all occurences of the loop-control variables in the editor or on the compiler listing will help out there.

Setting the CPU limit low, as Robert suggested, is a good idea. As the loop is likely to be entered almost immediately, try with one second first. You'll get the dump, and should be able to work out from the PSW whereabouts in the program it ran out of CPU time. In the unlikely event of that not being inside a loop, increase the CPU limit. If you put DISPLAYs in, showing loop-control variables for instance, also ensure you have an output limit on the jobstep.

Loops that are caused by the data, rather than a looping-structure being coded incorrectly, are trickier as it might take more time before the loop is entered. Here the OPS can help you out. If you have access an enquiry-only JES console, you can watch the CPU on the job. When it shoots up, ask the OPS to cancel it with a dump. If you don't have access to a console yourself, explain to the OPS that you are trying to debug a loop and ask them if they can keep an eye on it and cancel it with a dump when the CPU usage goes up.

Loops are usually simple to find. You've already tried with the source/listing but it is worth trying again. Then add the DISPLAYs and cut the time down/limit the LINES.

There are some varieties of tricky loops. These sort of things are usually caused by GO TOing out of a PERFORMed paragraph/section, or othewise "dropping through" the program in some way. PERFORMs cannot be "recursive", so if you have PERFORM A, which PERFORMs B, which PERFORMs C, which PERFORMS A or B or C, you have a loop. If you have a paragraph/section which is PERFORMed multiple times from the same PERFORM (PERFORM n TIMES, PERFORM UNTIL) and you have a GO TO in the paragraph/section then you may well get a loop. If you think that you can alter some loop-control variable (like n TIMES and other such) and are relying on that, then you will have a loop. There are many more possibilities.

Many (even all) of the ways to create an infinite-loop are beginers' mistakes. It is good in that it gives you lots of practice, but you must learn from them each time so as not to repeat them. This is the main reason that it is best if you can find it yourself (which you are trying to do). Once you have more experience, you should have no fear of a loop which brings down production.

Once you've cracked a few loops, try the next one just from the dump, with no displays added. All the information you need is there. It is a good way to find out what all that stuff at the back of the compile listing means

Good luck, and let us know how you get on.

If you are still stuck, post what you think are the most likely parts of the code and we can see what we can do.

BillyBoyo,

Thank you very much,
As suggested I coded DISPLAY statements before and after, start and end of each paragraph.

Got it finally..

Coding DISPLAY statements is very good way to find infinite loops.

Thank you all for giving suggestions.

Regards,
RAju.

Thanks for letting us know. Glad you got it.

Robert Sample wrote:[,,,] In the absence of a debugger, finding an infinite loop is usually done by setting a low CPU limit, altering the code to include displays at appropriate points, and running the code to see where the loop starts.

Robert suggested it first, so thanks to him as well. We also agree on the "appropriate points". There is no need to put displays "everywhere", just where you have the looping-constructs (at least initially).

If you use the PSW from the abend in the same was as you would for, for instance, a S0C7, then you can pretty-much "home-in" on the suspect area.

What sort of loop was it? It'll be one to "tick off the list", but there are other types. Just don't do the same again without kicking yourself, and don't do twice again at all...