Hi,
Please help me to understand the difference between Structured mode and reporting mode in Natural programming.
Thanks
The difference is mainly syntactical with the goal of “structured” mode to make code be less ambiguous and easier to understand. Before structured mode was introduced, troubleshooting and debugging code took more effort. One trouble-spot was that variables could be defined anywhere in the code, and even defined implicitly as undeclared formatting of new variables defaulted to (N7). Another is that all looping blocks of code were blocked with LOOP instead of END-READ, END-FIND, END-REPEAT, etc. Another is that IF statements had no requirement to have an equivalent END-IF (if multiple statements were to be executed for a condition, they were placed between DO/DOEND markings). It was definitely an improvement to Natural!
Instead of just changing Natural, Software AG decided to support the old syntax (most of it, anyway) and call it “reporting mode”. This allowed customers to not have to completely remediate their code if it was too much of an effort, in order to upgrade to Natural v2. It also made some programmers happy who preferred to use the old syntax or who wanted to write simpler code for quick-and-dirty programs.
I don’t know of any good reason today to use “reporting mode” except as a product administrator when code is supplied by a vendor using this mode. Maybe there are a handful of people out there still using it, but all shops by now should have made sure all enterprise applications are coded in structured mode.
Just to add to Brian’s comments.
There were several statements that exist in Report Mode that do not exist in Structured Mode. I use the term “idiot proof” to describe Structured Mode. By this I mean that in the transition to Structured Mode, SAG took out statements from Report Mode that could result in problems/bugs.
For example, FIND FIRST and FIND UNIQUE, which exist in Report Mode do not exist in Structured Mode. Neither of these FINDs start processing loops, which could often result in a programmer writing code that did not work the way they thought it would.
The OBTAIN statement (which is a “message” to the compiler, not an executable statement) is used in Report Mode to specify ranges of MUs or PEs to be read by Adabas. That is, OBTAIN adds to the Format Buffer for READs and FINDs. In Structured Mode, file Views (which do not exist in Report Mode) are used to create Format Buffers. In Report Mode, the compiler, with the help of OBTAIN scans a FIND or READ to construct format buffers. For FIND FIRST and FIND UNIQUE, line/label references are used when necessary.
Then, there is MOVE INDEXED. Before Natural had array structures, the MOVE INDEXED provided a means to establish the equivalent of arrays. Many programmers did not understand how MOVE INDEXED actually worked, leading to some very strange results.
Without any proof that the following is true, I would guess there is still a lot of Report Mode code within the Natural community. This would mainly be code that has never changed, and is unlikely to ever change. For example, a subprogram that was written for some purpose specific to a company/industry, many years ago. For example, I recall code to compute the number of “work” days between two dates. The code was very company specific. It was not just code that ignored weekends and specific holidays.
All the above said, I agree with Brian that there is probably very little new code being written in Report Mode.
I use reporting mode fairly often, but only for ad-hoc reports used for data discovery. It is a quick way to investigate data problems or just find records meeting criteria. I would never use reporting mode in a user-facing application.
Consider the explanations mentioned, I see that you are starting the NATURAL programming, the Report mode is history and should no longer be used is the time of the 80’s, there are customers who do not allow it.
My recommendation is not to use the report mode
Kind regards
Angel