I am looking at a very in-tuh-rhes-tingu report where the output is seven summary reports, two per page. The current design first extracts A SINGLE RECORD with a zillion fields into which said extract program has placed all the summary line totals for each report. The ‘report’ program writes the headings and summary lines for each report after calculating cross and report totals for each report.
Please note that all reports on this site are done in ‘structured mode’ not ‘report mode’ - for whatever reason.
My question: If I have to update this report - which means I will rewrite it if I can - assuming I can create DETAIL records with a different format for each report by using a report-type field and redefining the record, will I be able to generate multiple SUMMARY reports on the same page from these records USING Natural’s REPORT features (in Structured Mode) to do summary, cross and report totals ?
As with others who have become a fixture here, after 8 weeks it is time to pester management for a Natural class. What you are trying to do is akin to communicating in a language you do not know using only a “crib sheet” with 50 words.
Example. You use the terms “Report Mode” and “Structured Mode” in a manner that suggests they are in someway related to whether you are preparing reports. While such a view is good for a chuckle at the end of a long day, it has nothing to do with the reality of the terms.
Basically, Natural does not have “Report features”. Unless, of course, you want to include System Functions used in AT END OF PAGE clauses, AT BREAKS, etc . These features do not differ between Report and Structured Modes (except for the syntax).
You can (in both modes) WRITE, PRINT, or DISPLAY anything you want.
The answer is: Yes, it is possible to create the report(s) you want. But, this requires you have understood the reporting facilities Natural provides. Thus, it is nothing for an unexperienced noob, because he/she will not understand the explanation.
BTW. Once upon a time a company named SOFTWARE AG invented a database named ADABAS and a query language for this database, named NATURAL. This query language was designed for non-it-staff to easily create simple database reports. It provided statements for creating report headers, footers, group/total sums, mins. maxs and so on. All in a natural language. IT-people grabbed this language and said: fine, we use it to write programs, as it is easy to use. When they used it, they wanted more and more features. So SOFTWARE AG increased the syntax to enable structured programming (IF/END-IF, FIND/END-FIND and so on; before this it only contained DO/DOEND, FIND,READ,HISTOGRAM/LOOP as structure elements). To be compatible to older programs, they invented two modes: the “report mode” for these “old” programs not containing structured syntax and the “structured mode” for “new” programs containing structured syntax. Semantically, both modes are the same.
To clarify, I am a noob in Natural but have over 20 years programming experience mostly with COBOL (includes a great report writer function)/CICS, and about 3 other report writers.
I am learning NATURAL by doing. But whenever I come to a new area (I have been working on online programs to date) - now batch reports, sometimes I have a question that I hope I can get a quick answer to on the forum.
From some of the syntax I have seen, I had assumed that NATURAL incorporated a Report Writer function. But report writers have differing limitations e.g Easytrieve+ allows only one line group (cobol allows multiple).
From your knowledge of report writers in general, please describe the limitations of NATURAL report writing facilities.
I’m not overly clear on what your specific report needs to do, but here are some general tips:
A useful arrangement for a Natural report program - organize the code somewhat the order it would be laid out on a page:
write title/footer - common page elements (page numbering, date, corporate name, etc)
extract data (find/read/read work/etc)
sort highest to lowest fields
at start of data - initialize and first “subheadings”
at top of page - page heading
if break of highest field - subheading
if break of next field - subheading (repeat as needed)
detail lines
at break of lowest field - subtotals (use OLD, COUNT, SUM functions)
at break of otherfields - more subtotals
at break of highestfield - subtotal for highest break
at end of data - report summary totals
Some notes:
you can write a number of reports by using the (n) notation against each WRITE/DISPLAY/PRINT statement. So, you could output detail report to (1), summary report(s) to (2), (3), etc. in same pass of the data.
DISPLAY statement includes automatic headers. The first DISPLAY statement for the report (n) present in the code (not the first executed DISPLAY) sets the columns and column headings. Typically the DISPLAY is used to produce the detail lines.
use T* notation from WRITE statements to line them up under the DISPLAY columns. Useful from the subtotal AT BREAK / AT END OF DATA sections to line up tallys under the appropriate columns without counting spaces.
The problem is that without some sort of Natural class, you really cannot effectively read Natural code, let alone write Natural code.
Doug did an excellent job of outlining some of the facilities Natural has to provide breaks, sub totals, etc. It is important you understand that these supplement the basic logic of Natural code. First, Natural is NOT a report writer in any sense of the term. It is a procedural programming language, albeit with a sprinkling of non procedural clauses. Then there are all the powerful % commands (Terminal commands), USR routines, a Debugger, data area editors, the list goes on and on.
All that said;
Basic Natural logic usually follows something like:
READ (or FIND) an Adabas record (or a work file record)
::
process the record (includes WRITE, DISPLAY, or PRINT of data from the record)
::
end the processing loop
As Doug noted, this is supplemented by clauses like AT BREAK which provides subtotals/statistics and AT END OF DATA which can provide overall statistics. Of course, processing loops can be nested, and there are a host of “object types” (subprograms, subroutines, helproutines, maps…) which complicate the basic loop just described.
HOWEVER, this is just a tiny part of Natural’s capabilities. Without any sort of education, or local gurus to draw upon, you will continually struggle to make sense of even simple programs.
I think the problem is that there’s too less literature. For other programming/scripting languages, there are tons of books only for learning purposes (e.g. the famous “Lama-book” to learn perl). But for Adabas/Natural I don’t know such books.
Maybe a beginner can use the Natural Programming Guide. But I’m not sure, if it is good for learning…
You can create up to 32 reports (0 to 31) simultaneously by using the report number (or a symbolic name for the report number) in the report statement (AT TOP/END OF PAGE(r), WRITE(r), PRINT(r), DISPLAY(r)). If you omit the report number, it is routed to report (0). Unless you specify it yourself, default page headers are printed for each report.
Each report statement creates one or more lines. The elements are printed from left to right (PM=I: right to left) and are separated by a space. Positioning backwards is not possible!
You can use the map editor to paint the “pieces” of the report, i.e. report header/footer (AT START/END OF DATA), page header (AT TOP/END OF PAGE), group header/footer and detail lines (WRITE, PRINT, DISPLAY). You have to set up the map editor to generate a WRITE statement. The generated code is independent from a report number, so that the “pieces” can be used in different reports.
WRITE(r) USING FORM "myform"
Common errors:
AT TOP OF PAGE(2)
WRITE *PAGE-NUMBER /* correct: WRITE *PAGE-NUMBER(2)
END-TOPPAGE
You should always provide the report number with report specific system variables e.g. *PAGE-NUMBER(r), *LINE-COUNT(r) and so on.
In the JCL a DD-card is used for each report. The default is CMPRTnn, where nn is the two digit report number. You can override this DD-Name with a DEFINE PRINTER (r) OUTPUT “new-dd”. In this case, the printer must be defined with AM=STD (see the PRINT-profile parameter for details). You can mix reports by routing them to the same printer (i.e. DD-card). In this case you have to take care of page headers/footers, line count and so on yourself.
Steve: I most respectfully disagree: Natural is a great report writer. A user can focus on the features I outlined in my previous note and be a very productive report writer. SORT, the AT-blocks and the associated functions provide significant non-procedural processing needed for report writing and the resulting code will make great sense to even a beginning Natural programmer - particularly one with prior procedural programming experience.
Yes, Natural includes a host of other features that have little to do with report writing, but that’s like saying COBOL is not a report writer because it has a host of procedural features outside the “report writer”.
Steve, you are right to suggest a NATURAL class but that’s not always available. Fortunately, I am an ace using reference manuals and user guides and have become fairly proficient with the online debugger. NATURAL’s English-like syntax makes it fairly easy to pick up. I would say it’s a mix of 2nd, 3rd and 4th generation instructions, methods and tools - overall above 3rd - first impressions :-).
It’s always helpful when design approaches and best practices are described for the noob and I thank you all again.
Douglas, I have to disagree. The word “great” is misplaced, it should read “simple”. If it really was great, there wouldn’t be the need for such a product like “Natural Reporter” on windows.
What is missing to be “great”?
Group headings (you have to work around with AT START, IF BREAK)
Printing in columns (PRINT/WRITE/DISPLAY with specified boundaries)
Printing of elements, not only a whole line.
A report editor (Map editor is limited to pieces of report only), also on mainframe.
Support for proportional fonts.
and much more.
The capabilities available up to now have already been available in the very first versions of Natural (Nat 1) and have not been changed/extended since then. :?
Interestingly enough, in the phrase “great report writer”, what I disagree somewhat with is the “report writer” part, not the “great” (although simple certainly also applies.
Way back when I went looking for a set of tiny screwdrivers for my first do it yourself micro-computer (PC was not in the lexicon yet). They were all but impossible to find (eventually got mine from a friend of the family who was an optomitrist). I found an old nail file in a drawer with the tip broken off. That became my first PC screwdriver. I still have it. It is still a nail file, not a screwdriver. Functionally, however, it works quite well as a screwdriver.
When you use the term “report writer” many people have a very fixed idea of what sort of software you are talking about. Natural does not fall into this category. HOWEVER, Natural is really “great & simple” for writing reports, especially those we use Natural for.
By contrast, as noted, Natural Reporter is a report writer. No one would ever confuse Natural Reporter with Natural however, although they share some capabilities.
Doug, the only reason I may have seemed “heavy handed” by my declaration that Natural is not a report writer is that is sounded like the original posting by Thespin (Ralph, I now agree with you, names are better than fanciful “handles”) indicated they were searching for the Report Writer “stuff” in Natural. It is not there per se. What is there are facilities that make it easy to create reports. Not the same thing.
Okay far too many words about a simple distinction. Back to coding in Natural, whatever it is.
In a previous incarnation, I used Easytrieve for several years which may or may not qualify formally as a Report Writer. I have also used Cobol’s Report Writer (does this qualify?) and Dyal.
After using Natural for a few reports, I must say that I find Natural’s report capabilities easy to learn, easy to code, very flexible, and very powerful. I am particularly impressed with DISPLAY with the VERT and HORIZ options.
None of the ‘report writers’ I used in the past had ALL these pluses.
Great job, SAG!
Edit: The only negative, and it’s a biggie, is the lack of ease in sorting the data for one or multiple reports.
I didn’t know. Are core arrays counted in the program size limit of 64K ? Can one execute SORT more than once if sorting a core array (I know how to sort multiple sequences using one sort) ? Is the coding structure different when coding SORT for a core array ?
Here is a simple program which demonstrates sorting an array
0010 DEFINE DATA LOCAL
0020 1 MYVIEW VIEW OF EMPLOYEES
0030 2 NAME
0040 1 #NAMES (A20/1:25)
0050 1 #LOOP (N2)
0060 1 #NAME (A20)
0070 END-DEFINE
0080 *
0090 INCLUDE AATITLER
0100 *
0110 READ (25) MYVIEW
0120 ADD 1 TO #LOOP
0130 MOVE NAME TO #NAMES (#LOOP)
0140 END-READ
0150 *
0160 FOR #LOOP = 1 TO 25
0170 MOVE #NAMES (#LOOP) TO #NAME
0180 END-ALL
0190 SORT BY #NAME USING KEYS
0200 WRITE #NAME
0210 END-SORT
0220 END
The READ loop is just to populate the array #NAMES. The SORT loop below sorts this array. Please note, although not shown in the code, after the SORT BY, I could have repopulated #NAMES from the values of #NAME.
