Hi,
I have a very long list of natural source files and I need to identify which of them is in Report mode, and which are not. Is there any way to find out by just looking at the code?
I guess I could look at IFs with DO DOEND instead of END-IF, but that doesn’t sound right. Is there any cleaner way? How does the editor know?
Regards & thx in advance
AB
There are several syntactical differences. You cited one, Report Mode has DO…DOEND. This does not exist in Structured Mode. Instead, as you noted, you have syntax like END-IF, END-BREAK, etc.
In Report Mode, all loops end with LOOP (or CLOSE LOOP). In Structured Mode, you have loops ending with END-READ, END-FIND, END-FOR etc.
In Report Mode, you declare variables at the first physical appearance of the variable. This is not allowed in Structured Mode which requires a DEFINE DATA clause. Thus MOVE ‘ABC’ to #A (A5) must be Report Mode
If you list programs (via LIST * * for example), Natural will tell you whether a program is Structured or Report Mode.
In the editor you can type SET SIZE ON which will show what mode you are in in the top right of the screen. You can change this by typing SET GLOBALS SM=ON (or OFF)
steve
There is also the USR2018N subprogram in the SYSEXT library that will return the directory information, including the mode, if you are trying to do this from a program.
L * MODE=Rwill list all modules that Natural thinks are in report mode. I say “thinks” because copycode and maps may show up that aren’t really report mode.
Ok thanks. I am reading the source files and I was wondering if there was any way I could figure out this data by reading some of the first files. At first we thought that Report programs did not have DEFINE DATA on them, but this proved to be wrong.
I guess this is the only way to go now, but at least I don’t have to parse the files to find out (Natural will do that for me).
Cheers
AB
You have “discovered” what I call “mixed mode” (I believe the official name is structured data mode). This is nothing more than the old Report Mode, BUT, with the requirement that there be a DEFINE DATA clause with all the file views and variables definitions.
However, just by looking for LOOP (or CLOSE LOOP) and DO…DOENDS you should be able to identify Report Mode code fairly quickly. Virtually every program has a loop of some sort so LOOP may be your best identifier.
Why are you reading the programs? Unless you have only printed listings, L * * would be the easiest way to separate programs by Mode.
steve
“Advertisment” 
BTW - are you aware that there is a product called Natural Engineer that (among a lot of other things) can convert reporting mode programs to structured mode ?
Finn
“Advertisment”
BTW - are you aware that there is a product called Natural Engineer that (among a lot of other things) can convert reporting mode programs to structured mode ?
Finn
I am aware that Natural Engineer exists, and I’ve used it. And after using it I have no confidence on it at all. I think they should be ashamed to have a product that does not even recognize which DDM a STORE / UPDATE /DELETE operation is using when it references a line number, or label.
I will do the L * * thingy to get a list of all report programs and compare against it. I am analyzing code to get some statistics and potential problems when migrating to a Unix platform; AND because Natural Engineer is not to be trusted 
Thanks to all for the responses. I have another doubt regarding migration from Mainframe to Unix that I’ve posted on the Adabas site (but it is a mix of Natural and Adabas). Maybe you could shed come light onto it? I am not actuall y a Natural developer, but just part of a team to migrate from mainframe to unix.
Thanks again guys (and girls)
Regards
AB
Sorry, forgot to add the link to the other post. thanks.
http://tech.forums.softwareag.com/viewtopic.php?t=13881&C=11,7,8,9,12
Sorry to hear that you have had a bad experience with Nat Eng.
My impression is that it does what it says it can do (eventhough the userinterface in the older versions was a bit odd - to put it mildly
The DDM Store/update etc. sounds more like a Predict feature than a Nat Eng. ?!
Could you restate what the ada/nat problem in the linked post is ?