Cobol - Problem With Cobol Report Writer

Author

Problem With Cobol Report Writer

Tracy

2005-04-15, 3:55 am

Hi everyone!

This is my first post to Google Groups - please be gentle! =)

Problem: I'm generating a report in Cobol 85 using the report writer,
and unfortunately I'm not so good at it. For some reason it appears
that only my last detail line is being printed in my report! I've
double checked all my line numbers to make sure I"m not overwriting
them. I displayed a portion of each detail on my display when I
compile and it shows that it is in fact reading all the records from
the infile, BUT it's reading the last line twice.

If would appreciate if anyone could take a p

at my code. Once I can
get the detail lines printing I'll be able to finish this program with
no problems. The code is VERY raw and I know that my calculations are
current incorrect, I only care about getting the detail lines to print.

Thank you VERY much in advance! Tracy

IDENTIFICATION DIVISION.
PROGRAM-ID. IRS-REPORT.
AUTHOR. TK.
DATE-WRITTEN. APRIL 15, 2005.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. VAX.
OBJECT-COMPUTER. VAX.

INPUT-OUTPUT SECTION.

FILE-CONTROL.
SELECT INFILE ASSIGN TO "data"
organization is line sequential.

SELECT WORK-FILE ASSIGN TO "Sort.tmp".

SELECT REPORT-FILE ASSIGN TO "Report".

DATA DIVISION.

FILE SECTION.

FD INFILE
LABEL RECORDS ARE STANDARD
DATA RECORD IS INPUT-REC.

01 INPUT-REC.
02 TAXPAYERNUM PIC 9(2).
02 STATE PIC 9.
02 REGION PIC 9.
02 NAME PIC X(10).
02 MONTHSPASTDUE PIC 9.
02 ORIGBAL PIC 9(5)V99.
02 PENALTY PIC X.

SD WORK-FILE
DATA RECORD IS WORK-REC.
01 WORK-REC.
02 TAXPAYERNUM-WR PIC 9(2).
02 STATE-WR PIC 9.
02 REGION-WR PIC 9.
02 NAME-WR PIC X(10).
02 MONTHSPASTDUE-WR PIC 9.
02 ORIGBAL-WR PIC 9(5)V99.
02 PENALTY-WR PIC X.

FD REPORT-FILE
LABEL RECORDS ARE OMITTED
REPORT IS TAXPAYERS-REPORT.

WORKING-STORAGE SECTION.
01 VARIABLES.
02 PAGE-TOTAL PIC 9(10) VALUE ZERO.
02 REGION-ORIGBAL-T PIC 9(5)V99 VALUE ZERO.
02 STATE-ORIGBAL-T PIC 9(5)V99 VALUE ZERO.

01 FLAGS.
02 EOF-FLAG PIC X(3) VALUE "NO".
88 END-OF-FILE VALUE "YES".
REPORT SECTION.

RD TAXPAYERS-REPORT
CONTROLS ARE FINAL

REGION
STATE
PAGE LIMIT IS 66 LINES
FIRST DETAIL 5
LAST DETAIL 25.

01 MAJOR-HEADING
TYPE IS REPORT HEADING NEXT GROUP NEXT PAGE.
02 LINE NUMBER IS 10.
03 COLUMN 44 PIC X(25) VALUE "INTERNAL REVENUE
SERVICES".
02 LINE NUMBER IS PLUS 2.
03 COLUMN 43 PIC X(28) VALUE "DELINQUENT TAX
PAYERS REPORT".
02 LINE NUMBER IS PLUS 2.
03 COLUMN 45 PIC X(22) VALUE "BY STATE WITHIN
REGION".

01 MAJOR-HEADING2
TYPE IS PAGE HEADING.
02 LINE NUMBER IS 1.
03 COLUMN 46 PIC X(21) VALUE "DELINQUENT TAX
PAYERS".
03 COLUMN 106 PIC X(4) VALUE "PAGE".
03 COLUMN 111 PIC ZZ SOURCE IS PAGE-COUNTER.

02 LINE NUMBER IS PLUS 2.
03 COLUMN 1 PIC X(8) VALUE "TAXPAYER".
03 COLUMN 12 PIC X(5) VALUE "STATE".
03 COLUMN 21 PIC X(6) VALUE "REGION".
03 COLUMN 44 PIC X(6) VALUE "MONTHS".
03 COLUMN 55 PIC X(8) VALUE "ORIGINAL".
03 COLUMN 68 PIC X(7) VALUE "PENALTY".

02 LINE NUMBER IS PLUS 1.
03 COLUMN 2 PIC X(6) VALUE "NUMBER".
03 COLUMN 12 PIC X(6) VALUE "NUMBER".
03 COLUMN 21 PIC X(6) VALUE "NUMBER".
03 COLUMN 32 PIC X(4) VALUE "NAME".
03 COLUMN 43 PIC X(8) VALUE "PAST DUE".
03 COLUMN 53 PIC X(11) VALUE "BALANCE DUE".
03 COLUMN 69 PIC X(4) VALUE "CODE".
03 COLUMN 78 PIC X(7) VALUE "PENALTY".
03 COLUMN 90 PIC X(8) VALUE "INTEREST".
03 COLUMN 103 PIC X(9) VALUE "GROSS DUE".

01 DETAIL-LINE
TYPE IS DETAIL
LINE NUMBER IS PLUS 2.
02 COLUMN 4 PIC 99 SOURCE IS TAXPAYERNUM-WR.
02 COLUMN 14 PIC 9 SOURCE IS STATE-WR.
02 COLUMN 23 PIC 9 SOURCE IS REGION-WR.
02 COLUMN 30 PIC X(10) SOURCE IS NAME-WR.
02 COLUMN 46 PIC 9 SOURCE IS MONTHSPASTDUE-WR.
02 COLUMN 54 PIC $ZZ,ZZZ.99 SOURCE IS ORIGBAL-WR.
02 COLUMN 70 PIC X SOURCE IS PENALTY-WR.

01 STATE-SUMMARY-LINE
TYPE IS CONTROL FOOTING STATE
LINE NUMBER IS PLUS 2.
02 COLUMN 37 PIC X(5) VALUE "STATE".
02 COLUMN 43 PIC 9 SOURCE IS STATE-WR.
02 COLUMN 45 PIC X(6) VALUE "TOTALS".
02 COLUMN 54 PIC $ZZ,ZZZ.99 SUM ORIGBAL-WR.
* 02 COLUMN 70 PIC X SOURCE IS PENALTY-WR.

01 REGION-SUMMARY-LINE
TYPE IS CONTROL FOOTING REGION
LINE NUMBER IS PLUS 2.
02 COLUMN 36 PIC X(6) VALUE "REGION".
02 COLUMN 43 PIC 9 SOURCE IS REGION-WR.
02 COLUMN 45 PIC X(6) VALUE "TOTALS".
02 COLUMN 54 PIC $ZZ,ZZZ.99 SOURCE IS REGION-ORIGBAL-T.

01 TYPE IS CONTROL FOOTING FINAL
LINE NUMBER IS PLUS 2.
02 COLUMN 39 PIC X(12) VALUE "GRAND TOTALS".

02 COLUMN 54 PIC $ZZ,ZZZ.99 SOURCE IS STATE-ORIGBAL-T.

PROCEDURE DIVISION.

1000-MAIN-LOGIC SECTION.
1001-MAIN-LOGIC.
SORT WORK-FILE
ON ASCENDING KEY REGION-WR
STATE-WR
TAXPAYERNUM-WR
USING INFILE
OUTPUT PROCEDURE IS 2000-PROCESS-OUT
STOP RUN.

2000-PROCESS-OUT SECTION.
2001-PROCESS-OUT.
PERFORM 3000-INITIALIZE-REPORT.
PERFORM 5000-PROCESS-RECORD
UNTIL END-OF-FILE.
PERFORM 6000-TERMINATE-REPORT.

3000-INITIALIZE-REPORT.
OPEN INPUT INFILE.
OPEN OUTPUT REPORT-FILE.
INITIATE TAXPAYERS-REPORT.
PERFORM 4000-READ-FILE.

4000-READ-FILE.
RETURN WORK-FILE
AT END MOVE "YES" TO EOF-FLAG.

5000-PROCESS-RECORD.
display "generate name " name-wr.
GENERATE DETAIL-LINE.
ADD ORIGBAL-WR TO STATE-ORIGBAL-T.
ADD ORIGBAL-WR TO REGION-ORIGBAL-T.
PERFORM 4000-READ-FILE.

6000-TERMINATE-REPORT.
TERMINATE TAXPAYERS-REPORT.
CLOSE INFILE.
CLOSE REPORT-FILE.

James J. Gavan

2005-04-15, 3:55 am

Tracy wrote:
> Hi everyone!
>
> This is my first post to Google Groups - please be gentle! =)

But of course :-). I've never written using R/W but go to University of
Limerick; some R/W examples there :-

http://www.csis.ul.ie/COBOL/examples/

I should point out the U of L. examples write to a disk-file and not
direct to the printer. If you search on COBOL and Report Writer you may
well find more examples at other universities.

Jimmy, Calgary AB

Richard

2005-04-15, 3:55 am

OUTPUT PROCEDURE IS 2000-PROCESS-OUT
STOP RUN.

2000-PROCESS-OUT SECTION.
2001-PROCESS-OUT.
PERFORM 3000-INITIALIZE-REPORT.
PERFORM 5000-PROCESS-RECORD
UNTIL END-OF-FILE.
PERFORM 6000-TERMINATE-REPORT.

3000-INITIALIZE-REPORT.

2000-Process-Out is a SECTION. The section will execute until it
reaches the next section header. It does 3000-Init.. then 5000-proc..
until EOF then 6000-term.. then drops through the label 3000-Init and
executes the statements there then drops through .... until it reaches
the statement GENERATE DETAIL-LINE then drops through until it gets to
the end of 6000-Terminate.. at which point the implicit perform of the
output procedure is complete.

With an ANS-85 compiler the output procedure can be a paragraph so
change this to 2001-Process-Out.

Tracy

2005-04-15, 3:55 am

THANK YOU SO MUCH!!!! You guys are amazing.

Keep up the great work. I can't thank you enough!

Tracy

Lueko Willms

2005-04-15, 3:55 pm

.. On 14.04.05
wrote tkartes@gmail.com (Tracy)
on /COMP/LANG/COBOL
in 1113522510.733754.207910@l41g2000cwc.googlegroups.com
about Problem With Cobol Report Writer

having all those paragraphs being performed ... one does not see
the wood for the trees.

t> 2000-PROCESS-OUT SECTION.
t> 2001-PROCESS-OUT.
t> PERFORM 3000-INITIALIZE-REPORT.
t> PERFORM 5000-PROCESS-RECORD
t> UNTIL END-OF-FILE.
t> PERFORM 6000-TERMINATE-REPORT.
t>
t> 3000-INITIALIZE-REPORT.
t> OPEN INPUT INFILE.
t> OPEN OUTPUT REPORT-FILE.
t> INITIATE TAXPAYERS-REPORT.
t> PERFORM 4000-READ-FILE.
t>
t> 4000-READ-FILE.
t> RETURN WORK-FILE
t> AT END MOVE "YES" TO EOF-FLAG.
t>
t> 5000-PROCESS-RECORD.
t> display "generate name " name-wr.
t> GENERATE DETAIL-LINE.
t> ADD ORIGBAL-WR TO STATE-ORIGBAL-T.
t> ADD ORIGBAL-WR TO REGION-ORIGBAL-T.
t> PERFORM 4000-READ-FILE.
t>
t> 6000-TERMINATE-REPORT.
t> TERMINATE TAXPAYERS-REPORT.
t> CLOSE INFILE.
t> CLOSE REPORT-FILE.

As has already been pointed out, after the first paragraph, the
program "falls thru" to the next paragraph, "INITIALIZE-REPORT", where
the report is again opened for output, and the REPORT is initiated
again. Then the program executes the remaining paragraphs, reading the
first two records, generating a DETAIL from the second record, and
then closing up.

BTW, the program does an OPEN INPUT INFILE in the section where the
RETURN from the sorted file is being processed, but never uses that
file in this process. Delete the OPEN and CLOSE of INFILE in that
part.

Next, these two lines:

t> ADD ORIGBAL-WR TO STATE-ORIGBAL-T.
t> ADD ORIGBAL-WR TO REGION-ORIGBAL-T.

are superflouus, you can accomplish that by the appropriate SUM
clauses in the CONTROL FOOTINGs for those controls, as you already do
in the STATE-SUMMARY-LINE. Give the column 54 in there a name, and you
should be able to reference this SUM counter in the upper CONTROL
FOOTINGS. You may have to RESET the SUM counter, though.

Instead of using

t> AT END MOVE "YES" TO EOF-FLAG.

use the file status

Put the whole thing in one section with a proper loop, as shown in
this my example (which processes an OPTIONAL sequential file):

--------- schnipp -----------------------------------------
OPEN INPUT input-file
IF is-not-present-file in status-input-file
THEN *> minor filestat = '5'
DISPLAY "input-file is not present"
ELSE
READ input-file
IF has-reached-EOF in status-input-file
THEN *> Major filestat = '1'
DISPLAY "input-file is empty"
ELSE
OPEN OUTPUT output-file
INITIATE output-report
PERFORM WITH TEST AFTER
UNTIL has-reached-EOF in status-input-file
*> do something useful with the input record
*> whose presence is asserted here
GENERATE report-detail-item
READ input-file
END-PERFORM
TERMINATE output-report
CLOSE output-file
END-IF
CLOSE input-file
END-IF
STOP RUN

HeyBub

2005-04-15, 3:55 pm

Tracy wrote:
> THANK YOU SO MUCH!!!! You guys are amazing.
>
> Keep up the great work. I can't thank you enough!
>
> Tracy

Just illustrating the rule: "Don't use SECTIONS." They are an artifact of a
more complicated time.

Pete Dashwood

2005-04-15, 8:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:115vd671ecudr9a@news.supernews.com...
> Tracy wrote:
>
> Just illustrating the rule: "Don't use SECTIONS." They are an artifact of
a
> more complicated time.
>
Or, just illustrating the rule: "Don't use COBOL." It is an artifact of a
simpler time.

If you are going to use COBOL, there is nothing wrong with using sections,
provided you don't perform paragraphs as well. We have thrashed this to
death here many times. It is a question of style. COBOL with or without
sections, provided it is well written, should be easily maintainable by any
competent COBOL programmer.

Pete.

Lueko Willms

2005-04-16, 8:55 am

.. On 16.04.05
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 3cascbF6lme65U1@individual.net
about Re: Problem With Cobol Report Writer

PD> If you are going to use COBOL, there is nothing wrong with using
PD> sections, provided you don't perform paragraphs as well.

Back in the days of COBOL-74, when I had written sort of a rulebook
for COBOL programming at Sperry Univac Germany, I stipulated that only
SECTIONs might be target of a PERFORM, and that only paragraphs might
be target of a GOTO (as in a GOTO DEPENDING ON, the way one could code
a CASE statement in a pre-85 COBOL).

Sure, with COBOL-85 a GOTO isn't necessary anymore at all, but I
stick to the rule, and recommend it to everybody else. All other
DIVISIONs, except the ultra-short IDENTIFICATION DIVISION are divided
in SECTIONS, so the PROCEDURE DIVISION should follow the pattern.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Vorstellungen sind auch ein Leben und eine Welt. -G.C.Lichtenberg

Richard

2005-04-16, 8:55 pm

> Sure, with COBOL-85 a GOTO isn't necessary anymore at all, but I
> stick to the rule, and recommend it to everybody else. All other
> DIVISIONs, except the ultra-short IDENTIFICATION DIVISION are divided

> in SECTIONS, so the PROCEDURE DIVISION should follow the pattern.

It may well be that the PROCEDURE DIVISION should be divided up into
SECTIONs. In fact I used to do that for the purpose of using
'priorities' in order to overlay the program into the memory space
available to me.

But it doesn't follow, as you seem to claim, that these SECTIONs should
therefore be what the PERFORMs target. After all one doesn't INITIALISE
WORKING-STORAGE as a SECTION.

Lueko Willms

2005-04-16, 8:55 pm

.. On 16.04.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1113676699.610450.255030@g14g2000cwa.googlegroups.com
about Re: Problem With Cobol Report Writer

r> It may well be that the PROCEDURE DIVISION should be divided up into
r> SECTIONs. In fact I used to do that for the purpose of using
r> 'priorities' in order to overlay the program into the memory space
r> available to me.

This is ancient ... but has nothing to do with the SECTION as such.
I have never played around with segmentation.

r>
r> But it doesn't follow, as you seem to claim, that these SECTIONs
r> should therefore be what the PERFORMs target.

This is a questin of individual discipline or shop standards. It
just makes sense, and it made much more sense before COBOL-85 was
implemented which finally made proper programming possible in COBOL.

It is a simple rule: PERFORM only SECTIONs, never a paragraph, and
GOTO only to paragraphs, never SECTIONs.

Today, where a GOTO is superflouus even in COBOL, I see the only
sense in paragraphs to serve as a visual documentation tool.

r> After all one doesn't INITIALISE WORKING-STORAGE as a SECTION.

I don't understand what that is supposed to mean.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Der Mann hatte soviel Verstand, daß er zu fast nichts mehr in der Welt zu gebrauchen war. -G.C.Lichtenberg

Richard

2005-04-17, 3:55 am

> This is ancient ... but has nothing to do with the SECTION as such.

It has _everything to do with SECTIONs. SECTION are _the_ way of
specifying which bits are overlayed and which are permanent.
Overlaying is still useful for large DOS programs and I still have
sites using DOS based systems (OK, I have one still using a DOS
run-time).

Now, as it happens, it is possible to also use a SECTION as the target
of a PERFORM, and some _ancient_ styles still do that.

> I have never played around with segmentation.

That probably explains why you don't understand it.

> This is a questin of individual discipline or shop standards.

Exactly, whereas you stated that you evangelise, to everyone.

> It just makes sense, and it made much more sense before COBOL-85 was

> implemented which finally made proper programming possible in COBOL.

So, you do agree that it is 'ancient'. Actually there is no real
problem in doing 'proper programming' in Cobol using ANS-74. The scope
terminators made it rather easier, but 'goto-less' programming is not
difficult without them.

> It is a simple rule: PERFORM only SECTIONs, never a paragraph, and
> GOTO only to paragraphs, never SECTIONs.

I, too, have a simple rule: PERFORM only single paragraphs (no THRU,
not SECTIONs) and then there cannot be a GOTO.

Which set of rules one follows is a matter of choice (or of site
imposed rules), whether one set is better than another may depend
entirely what one is used to.

Tracy's problem was that she (assumed) mixed PERFORMs (or implied
perform) of sections and paragraphs. The easiest solution was to change
to only performing paragraphs. Then the SECTION header is used as a
documentary grouping of the performed paragraphs that comprise that
'output procedure'.

> Today, where a GOTO is superflouus even in COBOL, I see the only
> sense in paragraphs to serve as a visual documentation tool.

How strange, because I see SECTION headers as purely a documentary
mechanism for grouping the paragraphs that I perform.

r> After all one doesn't INITIALISE WORKING-STORAGE as a SECTION.

> I don't understand what that is supposed to mean.

The SECTION is a way of grouping like items together so that they are
treated in the same way. That does not mean that they should all be
'done together' at one time. A SECTION can be a way of grouping
together several procedures that are to be treated in some way (such as
being all in memory at the same time) and that does not mean that they
should all be 'done together' as in PERFORMed via the SECTION header.

Lueko Willms

2005-04-17, 8:55 am

.. On 16.04.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1113693988.032812.32940@o13g2000cwo.googlegroups.com
about Re: Problem With Cobol Report Writer

[color=darkred]

r> It has _everything to do with SECTIONs. SECTION are _the_ way of
r> specifying which bits are overlayed and which are permanent.
[color=darkred]

r> That probably explains why you don't understand it.

I think the opposite, that _you_ have not understood segmentation.

While segementation requires SECTIONs as a precondition, because
the segment number applies only to a SECTION header (like you can't
apply a MULTIPLY to a group item, but only to an elementary item), it
is not the SECTION headers which determine the allocation of SEGMENTs,
but the SEGMENT NUMBER.

A segment is built out of the executable code of _all_ SECTIONs
which have the same SEGMENT NUMBER, there is even no requirement that
they be consecutive or ordered. You may have a sequence of segment
numbers 50, 53, 47, 50, 51, again 50, and so on. Segmentation _relies_
on the structuring of the PROCEDURE DIVISION in SECTIONS, but
segmentation plays in another dimension.

SECTIONs are about the logical structure and program flow, segments
about structuring the executable code. SECTIONs are part of the
NUCleus in COBOL standard speak, segments are part of the SEGmentation
module.

So, forget about segmentation when we talk about logical structure
of the program, and the role of SECTIONs and paragraphs in it.

[color=darkred]

r> Exactly, whereas you stated that you evangelise, to everyone.

Sure, I recommend to structure the program logically in SECTIONs,
because that is the hierarchically next classification following the
DIVISION, as in the other DIVISIONs too.

And they are syntactically required when using event processing
thru DECLARATIVES, what should be mandatory for proper file processing
to catch unrecoverable errors.

I really deplore that the COBOL-85 standard has made a step
backwards by e.g. dropping the requirement that a SORT INPUT or OUTPUT
PROCEDUREmust be a SECTION; they better should have published the 1971
draft as the standard instead of bickering four more years over it.
COBOL lost valuable years and reputation with it.

[color=darkred]

r> I, too, have a simple rule: PERFORM only single paragraphs (no THRU,
r> not SECTIONs) and then there cannot be a GOTO.
r>
r> Which set of rules one follows is a matter of choice (or of site
r> imposed rules), whether one set is better than another may depend
r> entirely what one is used to.

Sure, but using SECTIONs is the logical thing to do, for the
reasans explained above.

r> Tracy's problem was that she (assumed) mixed PERFORMs (or implied
r> perform) of sections and paragraphs. The easiest solution was to
r> change to only performing paragraphs.

It is the primitive way to solve that logical error. Better to
write it as the simple loop of which I have presented an example.

Besides, doing that in COBOL-74 was not really easy, it tends to be
obfuscating because loops could not be written 'in place' and cannot
be nested because looping was only possible by PERFORMing other
SECTIONs (or paragraphs, if you insist); the problem presented by
Tracy was a reflection of it, and my recommendation is to get over
that as soon and as quickly as possible.

Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Der Mann machte sehr viel Wind. B: O nein! Wenn es noch Wind gewesen wäre, es war aber mehr ein wehendes Vacuum. -G.C.Lichtenberg

Richard

2005-04-17, 8:55 pm

>>> I have never played around with segmentation.

r>> That probably explains why you don't understand it.

> I think the opposite, that _you_ have not understood segmentation.

> While segementation requires ... blah blah blah

After admitting that you have never 'played around' with segmentation,
and seeing that I have used it for 35 years, you then attempt to
'teach' it to me. Hmmmmm, I'm sure there's a word for that.

> And they are syntactically required when using event processing
> thru DECLARATIVES,

I always found declaratives to be rather clumsy and almost
neccessitated a GOTO. Tried them, didn't like them, found them
unneccessary.

> what should be mandatory for proper file processing
> to catch unrecoverable errors.

I have no difficulty catching 'unrecoverable errors' without
declaratives.

Now you are not only evangelising but attempting to enforce style by
making it 'mandatory'.

> Sure, but using SECTIONs is the logical thing to do, for the
> reasans explained above.

No. You are wrong. You like to have sections and then have invented
those justifications and call them 'reasons' merely as a style of
argument.

> It is the primitive way to solve that logical error. Better to
> write it as the simple loop of which I have presented an example.

Yes, I did notice that you liked to claim that your _style_ was
_better_ than others.

I tried to avoid telling Tracy that her complete code was crap and just
focus on the one little item that was the actual problem. I could have
told her to make all the paragraphs to sections (or actually you could
have), there are many ways to correct her mistake, but I felt it was
important to indicate that error in the simplest way.

Rewriting the code to a single statement may well have avoided the
problem but, by reducing the code to a single paragraph or section, may
not have taught her not to mix.

> Besides, doing that in COBOL-74 was not really easy, it tends to be
> obfuscating because loops could not be written 'in place' and cannot

> be nested because looping was only possible by PERFORMing other
> SECTIONs (or paragraphs, if you insist);

Well actually, yes I do insist on it being an option. I don't insist
on either one being used or banned.

I certainly agree with you that each label should only be used for one
thing. I wrote some quite lengthy discussion about this here some time
ago, including a proposal I sent in for label qualifiers that would
implement such restrictions.

I used to use sections so I am familiar with whatever advantages they
have, such as allowing GOTO to an exit paragraph, but once GOTO has
been eliminated there is no need for any paragraph labels within a
section, any commentary value may be obtained in exactly the same way,
with less confusion, with an actual comment. The program then only has
sections. Without declaratives (aren't they deprecated now as being
archaic ?) it makes no difference whether they are _all_ sections or
_all_ paragraphs.

It then comes down to whether the author prefers one or the other.
With sections there is a risk of forgetting the keyword and having a
difficult to find bug. If there are no sections then a text search
proves this quickly and easily.

> because that is the hierarchically next classification following the

> DIVISION, as in the other DIVISIONs too.

Let us take DATA DIVISION. There may be one or two SECTIONS, possibly
a couple more. The SECTIONs are each of different types of data. Each
section is divided up into _records_ or independent items. Reference
are to the _records_ or _items_ and _never_ to the section header.

To form a logical argument about this usage in PROCEDURE DIVISION we
may then divide the PD up into SECTIONs (such as MAIN SECTION,
PROGRAM-INITIALISATION SECTION, UTILITY-ROUTINE SECTION, etc) and these
would have individual items (paragraphs) that are referred to by
statements in the program (ie PERFORM paragraph).

You may even want to note that even in declaratives the section name is
never used anywhere.

If you want consistency then you will never explicitly refer to a
section name in your code.

Now I am not using this as an argument to convince people to change,
only to show that the conclusion you draw from what happens in other
divisions is illogical.

Lueko Willms

2005-04-17, 8:55 pm

.. On 17.04.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1113770749.471349.36690@g14g2000cwa.googlegroups.com
about Re: Problem With Cobol Report Writer

[color=darkred]
[color=darkred]

r> After admitting that you have never 'played around' with segmentation,
r> and seeing that I have used it for 35 years, you then attempt to
r> 'teach' it to me. Hmmmmm, I'm sure there's a word for that.

Say it!

What made me think what I wrote, is that you started talking about
segmention when the talk was about SECTIONs. The only relationship is
that SEGmentation requires SECTIONs, but SECTIONs exist in programs
without any thought about segmentation. SEG is not required in a
standard-conforming implementation, but support for SECTIONs is. There
millions of COBOL programs without segmentation, but with the
PROCEDURE DIVISON structured in SECTIONS.

On the other hand, for someone who _does_ use segmentation, the
logical structuring of the PROCEDURE DIVISION should be the most
normal thing to do, since the number of a segment can only be given to
a SECTION.

r> Yes, I did notice that you liked to claim that your _style_ was
r> _better_ than others.

Sure, if would find another style to be superior, I would apply that
one, but then this turns into my style... why should I apply a style
which I find inferiour without being forced to use it?

r> Now you are not only evangelising but attempting to enforce style
r> by making it 'mandatory'.

Well, I could make it only mandatory in a place where I could make
the rules. There is none, I am working on my own.

[color=darkred]

r> No. You are wrong. You like to have sections and then have invented
r> those justifications and call them 'reasons' merely as a style of
r> argument.

Everybody is free to do as she or he pleases. I think that I have
good reasons for my decisions, and I will not hide these reasons. But,
of course, I have neither the intention nor the power to enforce this
on anybody.

On DECLARATIVES:

[color=darkred]

r> I always found declaratives to be rather clumsy and almost
r> neccessitated a GOTO.

Why? That interests me. And why 'almost'?

r> Tried them, didn't like them, found them unneccessary.

In the beginning I felt like you. In the mean time I changed my
mind, after having worked with a database development system and
interactive forms.

[color=darkred]

r> I have no difficulty catching 'unrecoverable errors' without
r> declaratives.

Sure, but that introduces additional complexity into the normal
program flow, which is not necessary.

There are unrecoverable errors, where the program can only do a STOP
RUN, and give some explanations before; that is done most elegantly by
event processing.

It is a pity, by the way, that the standards committee (and as far
as I know, not implementor) has used DECLARATIVES for event processing
on a GUI form. Having DECLARATIVES for event processing outside of the
sequential program flow from start to stop run, would have made COBOL
the natural language for such form processing, with DECLARATIVEs as
ON DOUBLE-CLICK in FIELD txt-Given-Name OF FORM form-25
ON GET-FOCUS in FIELD date-of-birth OF FORM form-25

and so on.

Yours,

Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Mit dem Band das ihre Herzen binden sollte haben sie ihren Frieden stranguliert. -G.C.Lichtenberg

Richard

2005-04-18, 3:55 am

> The only relationship is that SEGmentation requires SECTIONs,

Yes, Segmention requires sections.

> but SECTIONs exist in programs without any thought about
segmentation.

Sections _might_ exist in programs without segmention. Sections are
not _required_ except for segmentation and for declatatives.

> There millions of COBOL programs without segmentation, but with the
> PROCEDURE DIVISON structured in SECTIONS.

Yes, but you draw the illogical conclusion that therefore one must
explicitly use those section header names whereas one is banned from
referring to the section names of other divisions.

> In the beginning I felt like you. In the mean time I changed my
> mind, after having worked with a database development system and
> interactive forms.

I have worked with databases and interactive forms and never felt the
need for declaratives. It just depends on what you are used to.

> Sure, but that introduces additional complexity into the normal
> program flow, which is not necessary.

The complexity is _somewhere_. You put it into declaratives, I put it
into performed paragraphs. For example one may have:

OPEN filename
<deal with exceptions in declaritives>
carry on

or:

PERFORM Open-filename
<deal with exceptions in the code that opens the file>
carry on

'Normal' program flow is the same.

> There are unrecoverable errors, where the program can only do a STOP

> RUN,

Are you talking about batch programs only ? because I certainly don't
do a STOP RUN in interactive systems just because it is
'unrecoverable'.

> and give some explanations before; that is done most elegantly by
event processing.

In your opinion, of course.

I also have standardised, reusable, code that gives the user a message
(and writes it to a log file), this may give options that would allow
recovery. After, say, a READ WITH LOCK I may check the status for
success, for locked, for missing and deal with those specifically and
otherwise perform 'discfail'.

<shug>. It is just what one is used to. Claiming superiority for a
style is, well, ...

> It is a pity, by the way, that the standards committee (and as far
> as I know, not implementor) has used DECLARATIVES for event
processing
> on a GUI form.

I think you missed a 'not'.

William M. Klein

2005-04-18, 8:55 am

I have said this before and I will say it again, ...

When working for Micro Focus (and even earlier when working with the Xpeditor
vendor) it was my impression that"

- Using all SECTIONS (and 1 or 0 - depending upon extensions) paragraphs per
SECTION was more common in Europe than in the US

- Using all Paragraphs (and NO sections - except for Declaratives and '74
Standard SORT Input/Output procedures) was more common in the US than in Europe

(and I had minimal exposure to Asia, Canada, and other "COBOL worlds")

***

This is, was (and probably always will be <G> ) a STYLE issue only. It is
entirely possible to code "maintainable" (and well structured) COBOL code with
either approach. There is NO indication that the COBOL "developers" ever
thought that all (most?) programs should be divided into SECTIONS and then
PARAGRAPHS (within the Procedure Division) - although they did provide for this
POSSIBLE approach.

With the removal of requiring SECTIONS for SORT/MERGE Input/Output procedures, I
would say that there was - at least SOME evidence - that those "maintaining"
the COBOL language were moving away from "encouraging" the use of SECTIONS.
(with some additional movement in this direction in the '02 Standard and under
consideration for the future).

***

My style is to:
- Only use Paragraphs (unless using a DECLARATIVE)
- Never use PERFORM THRU
- Never use GO TO
- DO code "misleading" PERFORM of paragraphs that never come back - because
they terminate the program/run-unit
- DO use EXIT PARAGRAPH/PERFORM - with compilers supporting it

However, I don't see anything SUPERIOR in this style to other "consistent" and
"maintainable" styles

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2005-04-18, 8:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:YZI8e.268681$za2.43904@news.easynews.com...
> I have said this before and I will say it again, ...
>
> When working for Micro Focus (and even earlier when working with the
Xpeditor
> vendor) it was my impression that"
>
> - Using all SECTIONS (and 1 or 0 - depending upon extensions) paragraphs
per
> SECTION was more common in Europe than in the US
>
> - Using all Paragraphs (and NO sections - except for Declaratives and '74
> Standard SORT Input/Output procedures) was more common in the US than in
Europe
>
> (and I had minimal exposure to Asia, Canada, and other "COBOL worlds")
>

As it really doesn't matter, why are we discussing it? I've been about a bit
and written COBOL here and there... I've seen both styles used all over.

> ***
>
> This is, was (and probably always will be <G> ) a STYLE issue only. It is
> entirely possible to code "maintainable" (and well structured) COBOL code
with
> either approach. There is NO indication that the COBOL "developers" ever
> thought that all (most?) programs should be divided into SECTIONS and then
> PARAGRAPHS (within the Procedure Division) - although they did provide for
this
> POSSIBLE approach.

Bill, I don't think Richard suggested it was other than a style issue. In
fact, I thought his post was quite restrained and fair, given that his
personal preference is for paragraphs.

I like SECTIONS and we have covered this so often and at such length nothing
much is gained by re-opening it.

I agree with Lueko, that SECTIONS in the procedure division seem like a
logical extension of the COBOL structure, but I agree with Richard that that
is inconsistent with other use of SECTIONs in COBOL.

Personally, I don't care whether the originators of COBOL intended us to
code with sections or not. We all do what is familiar and easy to us. The
message here is "Don't mix styles", but either style is OK.

Actually, I have used both styles, not in the same program, I hasten to
add... (I like to code in the style of the installation I'm working on, even
though it may not be my personal preference).

I became persuaded to using SECTIONs many years ago for my personal stuff
(and where I had a choice),after spending many years using PERFORM...THRU
and paragraphs; it was in the days when nobody really knew much about
programming, but there are pros and cons to using PERFORM ... SECTION, and
in one particular post Richard made a very persuasive case against their
use. If I was still making a living out of coding COBOL, there's a small
chance I might consider moving to paragraphs, but I believe the full benefit
of such a move would only be really felt if Richard's idea for standard
labels was implemented, and, although it is a good idea, it is just too much
effort, for me at any rate.

>
> With the removal of requiring SECTIONS for SORT/MERGE Input/Output
procedures, I
> would say that there was - at least SOME evidence - that those
"maintaining"
> the COBOL language were moving away from "encouraging" the use of
SECTIONS.
> (with some additional movement in this direction in the '02 Standard and
under
> consideration for the future).
>
And given the track record of these people with regard to COBOL we should
follow their "encouragement"? I don't think so... The 02 standard you refer
to shows no sign of being implemented and is not likely to be. Until it is,
it is vaporware.

> ***
>
> My style is to:
> - Only use Paragraphs (unless using a DECLARATIVE)
> - Never use PERFORM THRU
> - Never use GO TO
> - DO code "misleading" PERFORM of paragraphs that never come back -
because
> they terminate the program/run-unit
> - DO use EXIT PARAGRAPH/PERFORM - with compilers supporting it
>

Well, good for you. You won't hear me disagreeing with the above. But would
I adopt it myself? No. What I do works fine for me.

> However, I don't see anything SUPERIOR in this style to other "consistent"
and
> "maintainable" styles
>
Exactly.

What is familiar, is good. What is strange, is not.

Richard has said it many times, and he's absolutely right on this.

Pete.

Rick Smith

2005-04-18, 8:55 am

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3chbv8F6n886aU1@individual.net...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:YZI8e.268681$za2.43904@news.easynews.com...
[snip]
> procedures, I
> "maintaining"
> SECTIONS.
> under

Bill, I have never been on the 'inside'; but the pattern I see
is more to 'accommodate' a paragraphs-only style. Consider
the means available for the new common exception processing.
One could set a flag and RESUME AT NEXT STATEMENT,
which 'accomodates' a paragraphs-only style; or one could
RESUME AT procedure-name-1, which 'accommodates'
a sections style. To me, this seems neutral and therefore not
'encouraging' one style over the other.
[color=darkred]
> And given the track record of these people with regard to COBOL we should
> follow their "encouragement"? I don't think so... The 02 standard you
refer
> to shows no sign of being implemented and is not likely to be. Until it
is,
> it is vaporware.

Pete, meditate ... find your 'happy' place. <g> ... trust that the
standards committee will remain neutral, except that a few
'radicals' may continue to try to eliminate the GO TO statement.

Pete Dashwood

2005-04-18, 3:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11675s6cq6ver50@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3chbv8F6n886aU1@individual.net...
> [snip]
and[color=darkred]
>
> Bill, I have never been on the 'inside'; but the pattern I see
> is more to 'accommodate' a paragraphs-only style. Consider
> the means available for the new common exception processing.
> One could set a flag and RESUME AT NEXT STATEMENT,
> which 'accomodates' a paragraphs-only style; or one could
> RESUME AT procedure-name-1, which 'accommodates'
> a sections style. To me, this seems neutral and therefore not
> 'encouraging' one style over the other.

This facilty has been in Visual Basic (ugh! Spits three times and turns
widdershins to the East) since the beginning...

>
should[color=darkred]
> refer
> is,
>
> Pete, meditate ... find your 'happy' place. <g> ... trust that the
> standards committee will remain neutral, except that a few
> 'radicals' may continue to try to eliminate the GO TO statement.
>
:-) There is no happy place for me where the standards for COBOL are
concerned. However, I've really said everything on that subject that I ever
want to. I will concede (gladly) that there have been a lot of people
working very hard on it. They deserve some credit for that. My XXXXX is at
the mismanagement and lack of achievement. I still believe 17 years between
viable standards was a contributing factor to the decline of COBOL. Please
don't start me off again... :-) (Applies saffron robe, ping pong ball eyes,
and becomes calm...)

Pete.

Howard Brazee

2005-04-18, 3:55 pm

On 17-Apr-2005, "Richard" <riplin@Azonic.co.nz> wrote:

>
> Yes, Segmention requires sections.

Who uses segmentation anymore?

Heck, I don't even use multiple programs in one compile which is another way of
getting the same effect.

Frederico Fonseca

2005-04-18, 3:55 pm

On Mon, 18 Apr 2005 15:08:51 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 17-Apr-2005, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
>Who uses segmentation anymore?
I have customers that still use segmentation.

In one of them the smallest program is one with 16K lines of code, and
that gets really big in terms of memory usage.

Segmentation is the only way of running some of their programs.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Lueko Willms

2005-04-18, 3:55 pm

.. On 18.04.05
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 3chbv8F6n886aU1@individual.net
about Re: Problem With Cobol Report Writer

PD> What is familiar, is good. What is strange, is not.

I for my part find it very strange that anybody writing COBOL
programs would not want to divide the PROCEDURE DIVISION in SECTIONs.

I have learned it that way, I always done it, and I have never
seen a program which was not divided in SECTIONs with SECTIONs playing
the role of a PROCEDURE or FUNCTION in, say a Pascal program, except
that it is not really shielded of from the rest. Well, that is COBOL,
an ancient programming language which did not take input from the
scientific research regarding programming when it was created.

Nested programs, which are the real equivalent to a procedure or
funtion in C or Pascal came later, and they are, er, not really
comfortable to use.

So, I see SECTIONS as procedures, and paragraphs as labels. So do
many other programmers. Bill Klein says that he sees that as a
European habit; well, I happen to live in that part of the world. But
having done my COBOL work mostly working in a US-american computer
vendor... and it is only in the past few months, by reading this
newsgroup, that I have encountered people who did not use SECTIONs as
procedures and paragraphs as labels. Well, one learns something new
every day...

Well, when anybody (outside of my jurisdiction!) wants to use the
labels as procedure headers, so be it. As long as I have not to fiddle
with such a program text ...

Besides, I think there are sound technical reasons for it, even if
one of those was dropped from the 1981 draft standard, the one
regarding SORT and MERGE input or output procedures.

But please don't think that my recommendations are something more
than a recommendation...

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Der Mann hatte soviel Verstand, daß er zu fast nichts mehr in der Welt zu gebrauchen war. -G.C.Lichtenberg

Howard Brazee

2005-04-18, 8:55 pm

On 18-Apr-2005, l.willms@jpberlin.de (Lueko Willms) wrote:

> PD> What is familiar, is good. What is strange, is not.
>
> I for my part find it very strange that anybody writing COBOL
> programs would not want to divide the PROCEDURE DIVISION in SECTIONs.
>
> I have learned it that way, I always done it, and I have never
> seen a program which was not divided in SECTIONs with SECTIONs playing
> the role of a PROCEDURE or FUNCTION in, say a Pascal program, except
> that it is not really shielded of from the rest. Well, that is COBOL,
> an ancient programming language which did not take input from the
> scientific research regarding programming when it was created.
>
> Nested programs, which are the real equivalent to a procedure or
> funtion in C or Pascal came later, and they are, er, not really
> comfortable to use.

I learned with sections, but I have seen many cases of people having
unintentional drop through code. I changed my preference to recommend that
there is *no* drop through code.

I agree that nested programs aren't comfortable. But I never had real world
fixes to make that persuaded me to go in that direction.

Frederico Fonseca

2005-04-18, 8:55 pm

On 18 Apr 2005 16:53:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>. On 18.04.05
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 3chbv8F6n886aU1@individual.net
> about Re: Problem With Cobol Report Writer
>
>
>PD> What is familiar, is good. What is strange, is not.
>
> I for my part find it very strange that anybody writing COBOL
>programs would not want to divide the PROCEDURE DIVISION in SECTIONs.
I on the other hand find it hard to have the PD with sections unless
segmentation is required. Too many problems arise with sections as
others have mentioned.
Most of the programs I have seen recently only have two sections.
Declaratives
and another one as using declaratives requires that the main program
is also within a section.

>
> I have learned it that way, I always done it, and I have never
>seen a program which was not divided in SECTIONs with SECTIONs playing
>the role of a PROCEDURE or FUNCTION in, say a Pascal program, except
>that it is not really shielded of from the rest. Well, that is COBOL,
>an ancient programming language which did not take input from the
>scientific research regarding programming when it was created.
>
> Nested programs, which are the real equivalent to a procedure or
>funtion in C or Pascal came later, and they are, er, not really
>comfortable to use.
That is really a question of knowing how to use them. I have been
using them for many years now and I don't see any problems with them.

>
> So, I see SECTIONS as procedures, and paragraphs as labels. So do
>many other programmers. Bill Klein says that he sees that as a
>European habit; well, I happen to live in that part of the world. But
>having done my COBOL work mostly working in a US-american computer
>vendor... and it is only in the past few months, by reading this
>newsgroup, that I have encountered people who did not use SECTIONs as
>procedures and paragraphs as labels. Well, one learns something new
>every day...
Well.. I am also from Europe, and MOST of my customers (and they are
many in three different EU countries) do not/did not use sections
unless segmentation is required. Most of the times I saw sections were
mainly with COBOL 74 and ONLY because of segmentation or SORT
requirements. Obviously when those customers upgraded to COBOL 85 most
of them did NOT change the programs.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Richard

2005-04-18, 8:55 pm

> Segmentation is the only way of running some of their programs.

DOS systems can use memory extenders when run on 386 and above.
MicroFocus (and the MicroSoft rebadged versions) have had XM for a
dozen years or so which allows several megabytes of RAM to be used.

Richard

2005-04-18, 8:55 pm

> an ancient programming language which did not take input from the
> scientific research regarding programming when it was created.

Just because it didn't turn out to be another Algol does not mean that
it didn't take into account reasearch that had been done on compiling
and language structure.

Cobol derived from several existing languages, some of which were
'experimental', and chose the parts from each which had been shown to
be useful and understandable.

> I for my part find it very strange that anybody writing COBOL
> programs would not want to divide the PROCEDURE DIVISION in SECTIONs.

> and it is only in the past few months, by reading this
> newsgroup, that I have encountered people who did not use SECTIONs as

> procedures and paragraphs as labels.

That must make it very difficult for you to be objective when
evaluating the advantages and di

vantages of these two styles.

Arnold Trembley

2005-04-19, 3:55 am

William M. Klein wrote:

> (snip)
> My style is to:
> - Only use Paragraphs (unless using a DECLARATIVE)
> - Never use PERFORM THRU
> - Never use GO TO
> - DO code "misleading" PERFORM of paragraphs that never come back - because
> they terminate the program/run-unit
> - DO use EXIT PARAGRAPH/PERFORM - with compilers supporting it

This is close to my style, except that in 25 years of programming at
two different shops in the USA, I have NEVER seen a production COBOL
program that used DECLARATIVES.

I used to see sections used with internal SORT, but since IBM COBOL
II, that has pretty much vanished in my current shop.

Occasionally, I see PERFORM THRU and GO TO some-EXIT, but I try never
to code that way in a new program.

Unfortunately, I have not yet tried EXIT PARAGRAPH or EXIT PERFORM. I
don't believe IBM Enterprise COBOL for z/OS and OS/390 supports that.

>
> However, I don't see anything SUPERIOR in this style to other "consistent" and
> "maintainable" styles
>

With kindest regards,

--
http://arnold.trembley.home.att.net/

Lueko Willms

2005-04-19, 8:55 am

.. On 18.04.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1113852390.634835.33970@l41g2000cwc.googlegroups.com
about Re: Problem With Cobol Report Writer

r> That must make it very difficult for you to be objective when
r> evaluating the advantages and di

vantages of these two styles.

I sure can't see any advantages in using labels, er, paragraph
names as procedure names, but everybody is free to do as she or he
pleases.

There even enough people who can't understand why anybody would
want to use COBOL in the first place.

Just don't worry and do as you please.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Hinlänglicher Stoff zum Stillschweigen. -G.C.Lichtenberg

Frederico Fonseca

2005-04-20, 8:55 am

Frederico Fonseca

2005-04-23, 3:55 am

Lueko Willms

2005-04-23, 3:55 am

Lueko Willms

2005-04-23, 3:55 am

Howard Brazee

2005-04-25, 8:55 am

Frederico Fonseca

2005-04-25, 8:55 am

Sponsored Links