Hello all. In batch I need to list how a program is executed line by line, from start to finish. I’ll extract that to a work file to read and/or print. I imagine it involves Test Mode. Allocating a work file and running it in real time would work too.
Also, isn’t there a way to show the SQL that Find and Read statements generated? Online or batch would work.
TIA
Hi Robert,
If by “Test Mode” you are thinking about “TEST DBLOG” , that utility only traces Adabas commands. To trace Natural program execution and events, try the Natural Profiler utility. It can run on mainframes in batch or online. You may need to check with your DBA if it is set up and how it works. There are buffer sizes that need to be expanded for large programs that create a lot of statistics. If you have NaturalONE there is a way to create a Resource file on the mainframe that can be read and displayed by NaturalONE.
The Profiler documentation is at:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat911mf/utis/profiler.htm[/url]
Assuming you are using Natural for DB2, and have Natural Tools for SQl installed, it looks like there is a LISTSQL system command.
You can read all about it at:
Also other Natural for DB2 at [url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat911mf/dbms/db2-over.htm#db2-over[/url]
Natural for Mainframes 9.1.1 -System Commands LISTSQL
LISTSQL
This command is only available with Natural for DB2, Natural SQL Gateway and Natural for SQL/DS. There are minor differences depending on whether the command is used with Natural for DB2, Natural SQL Gateway, or Natural for SQL/DS. These differences are marked accordingly in the following description.
LISTSQL object-name or [ALL]
This command generates a list of those Natural statements in the source code of an object which are associated with a database access. Also, it displays the corresponding SQL commands these Natural statements have been translated into. This enables you to view the generated SQLCODE before executing a Natural program which accesses an SQL table.
Good luck,
George
Take a look at Code Coverage of Natural Applications (within the Profiler documentation). It may provide what you want.
Also, you can debug a mainframe batch process with the on-line Debugger (in Natural for Windows or NaturalONE) via the Debug Attach Server.
Hi George and Ralph,
Thank you for your quick responses and links!
I don’t think I give enough details: I was referring to TEST mode aka DEBUG. With it you can set Breakpoints for a program. When you execute the program and hit a breakpoint you have the option to List Break. Choose that then you can use Step Mode to go through each line of the program. That’s what I want to do in batch, show the line by line execution.
I see some documentation in the links you sent about running it in batch, will try and make that work.
LISTSQL works, very helpful. We do use DB2. We do not have Natural anywhere but on the mainframe.
It appears Profiler offers even more detail. I just tried it and don’t have security rights, hopefully our support center can give me access. If it can display the SQL the program generates that would be extremely helpful.
Will keep you posted.
Thanks again,
Bob
Update: We do not have Profiler.
There is/was a 3rd-party product of the same name that condensed data from Natural’s Remote Data Collector, but George and I are referring to the utility that’s been part of Natural since v8.2.4 (October 2014), perhaps earlier.
Natural for Mainframes → Development Environment → Utilities → Natural Profiler (or just Profiler, in earlier releases)
Perhaps your Natural Administrator is keeping it from you.
You are correct Ralph. I don’t have access to Natural’s, security error. They’re working on that.
Appreciate it,
Bob
Robert,
My apologies. I forgot the TEST command by itself invokes the mainframe Natural debugger menu. There are 2 options there to track statistics of module calls and statements executed, and to display counts by statement line. Kind of gives you statement coverage, and there are also options to count statements not executed. But I believe the only way to track actual program statement flow/sequencing with the debugger is by stepping through line at a time. Hence the development of the Natural Profiler.
Ralph was close. I found the release notes for Natural 8.2.2 when SAG added the Profiler, January 2012.
Just saw your reply, waiting for admins to give you access to the Profiler. Hope that gives you what you need.
George
Thanks George.
The admins are working on it. I’m probably the first person to ask for it.
Bob
That last message was posted later than an early one. For some reason needed a moderator approval on in. Thanks, Bob
OK, no NaturalONE. So what mainframe Natural version are you on?
If the Debugger is what you want to use, here’s a link to the manual page (Ver 9.1), that talks about starting it in batch. The example shows running a program and printing out statistics for number of modules called. That makes sense to me, but I don’t know how you would use it to set break points or watch points and print out all the lines executed as if you were stepping through it online. I mean, when you hit a breakpoint in batch, what tells the debugger to resume execution? Oh well, can’t hurt to try while you’re waiting for access to the Profiler.
The Profiler can measure and count a lot of different types of events, like DB/DA before/after Adabas calls, before/after terminal I/O, and others. If you just ask for NS events, (Natural Statements) I think that may give you what you want. You can experiment online with the parameters to make sure you are getting what you want with a small program, before switching over to batch mode.
Good luck,
George
Hey George,
I want to use whatever gives me the best results. Luckily my worst case scenario isn’t too bad-there’s only 5 reports and I can copy/paste Step mode results into Word, line by line. I’ll try batch mode first.
We’re on Natural 8.2.
Thanks for the tips and link. No word on Profiler availability yet.
Bob
OK Bob,
Sounds like you’ve got what you need. Just hope there aren’t too many long running FOR or REPEAT loops. ;-(
These must be the last 5 orphan programs you were thinking of running under NaturalONE back in July.
Cheers,
George
Hey George
Yes, it’s the same 5 reports. I had to work on another project for a while, now I’m back to getting them off the mainframe.
Very good point about FOR and REPEAT loops. READs and FINDs would have the same issue. Online I can get out of the loops (using TEST), I highly doubt I can do that in batch.
Maybe Profiler will let me, still waiting for that.
Ciao,
Bob
Still no word on Profiler. Debug in batch seems impossible, even SAG states that.
So I’m using Debug online, wish I still had the manual from the class I took a LONG time ago.
The Escape Bottom command would make Debug usable, except it just stops Debug instead of getting out of the FOR or FIND loops. Am I missing something? TIA
Forgot to mention I can’t find a tutorial anywhere. The only ones I can find use NaturalOne. TIA
Hi Robert,
Still at it, eh? I guess getting you Profiler access for the last 5 reports running on the mainframe isn’t near the top of your DBA/Natural admin’s priority list.
You said you were on Natural 8.2. There are links to documentation for Natural 8.2.4 - 8.2.7 here:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/a_natural_mf/natural_mf_vers.htm[/url]
Pick the version closest to yours, since there were actually enhancements being made to the debugger during that time frame, although mostly to Display data commands, if I remember right. From the whole menu, pick Debugger on the upper right corner under Development Environment.
That takes you to the Debugger doc, like this for 8.2.4:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat824mf/debug_mf/debug_mf-over.htm[/url]
Top heading is the Tutorial. Sorry it’s old school, printed with examples, no YouTube. Only NatONE gets YouTube. ;-(
If you want to skip to the end of a loop and continue Stepping there, and screen printing I assume, then you can scroll down in the program listing and set a break point at the first line of code after the end of the loop. Then type GO and execution will continue until all loop iterations are complete and the debugger will stop again at your break point. You can continue single-stepping (PF2’ing) from there.
ESCAPE BOTTOM sort of does the same as GO, but you still need to set the break point to stop at after the loop. It doesn’t actually cause you to exit the Debugger, unless you have no break point to stop at. The other thing it does different is that it immediately exits the loop, without performing the normal number of iterations. Good if you are debugging an infinite loop, but otherwise you wouldn’t get the same calculation result as GO would.
ESCAPE ROUTINE works the same, immediately exiting the routine without finishing it, returning to the calling module.
Something else new since the old days that might prove useful is the STEP SKIPSUBLEVEL command. By itself it skips over a a call to an external subroutine or subprogram. The external routine gets executed, you just don’t have to step through it. I think this may default to PF5 or PF6…
Also helpful, STEP SKIPSUBLEVEL [n], where n is an execution level above your current level. Ie., you can return back up to a calling program without having to STEP all the way back. OBCHAIN shows you what level you are at and where you came from. Note that n would always be smaller than your current level. You can’t give a bigger number to go down further in the chain.
Hope that helps.
George
George, I can’t thank you enough! Setting the Breakpoint at the end of the loop and tying Go did the trick! THANK YOU THANK YOU THANK YOU!
(Yep, still working on Profiler)
You’re welcome. Glad that solved your problem, and hope it gets you through your project.
Cheers,
George
Hi George (or anyone else),
They got PROFILER working online. I use the TSO command NATTSO FI TEST PARM(‘RDCSIZE=3’) to get into NATURAL,and all is good (FI TEST is our TEST environment).
But, without even starting PROFILER if I run a very simple program using only 1 table I get this error message:
NAT3700 Error -924 with SQLSTATE 58006 from call to DB2.
I wrote a simple program:
0010 WRITE ‘HELLO WORLD’
0020 END
I can run and execute it, but when I try to STOW it I get the same NAT3700 message.
Even If I use NATTSO FI TEST PARM(‘RDCSIZE=2’) I get the same results.
Thoughts? Is it not DB2 compatible?
Thanks again!
Robert