Is it always possible to write a COBOL program using only 1 sentence per paragraph?
Oliver Wong
COBOL program. One of the transformations I'd like to apply is to try to
eliminate as many periods as possibles, using the END-whatever (END-IF,
END-CALL, END-COMPUTE, etc.) constructs.
My question is, is it always possible to do this? I don't want to
"cheat" by adding new paragraph names at the beginning of every sentence
(which may affect PERFORM statements anyway). My theory is that yes, it is
always possible, but I haven't been programming in COBOL for that long, so I
wasn't sure.
- Oliver Wong
Frederico Fonseca
wrote:
It is, but you need to have AT LEAST ONE period at the end of each
paragraph.
Some people will use a period on it's own, others will use a
"CONTINUE."
If you are going to do this (I don't agree with it myself) then I
advise you to use the "CONTINUE." way as it makes it very clear that
you have a "." there.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
Howard Brazee
On 11-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> I'm trying to write a program that reformats the structure of a given
> COBOL program. One of the transformations I'd like to apply is to try to
> eliminate as many periods as possibles, using the END-whatever (END-IF,
> END-CALL, END-COMPUTE, etc.) constructs.
Why?
Is every statement that can use an END- clause going to have one?
> My question is, is it always possible to do this? I don't want to
> "cheat" by adding new paragraph names at the beginning of every sentence
> (which may affect PERFORM statements anyway). My theory is that yes, it is
> always possible, but I haven't been programming in COBOL for that long, so I
> wasn't sure.
It's not possible to do this when not all of the code is visible. If some of
the code comes from inaccessible copy members or from precompilers, then it
won't work.
Oliver Wong
"Frederico Fonseca" <real-email-...@email.com> wrote in message
news:7ub5d1pej9vs5msg7...@4ax.com...
> It is, but you need to have AT LEAST ONE period at the end of each
> paragraph.
>
> Some people will use a period on it's own, others will use a
> "CONTINUE."
>
> If you are going to do this (I don't agree with it myself) then I
> advise you to use the "CONTINUE." way as it makes it very clear that
> you have a "." there.
Yes, sorry, I meant I wanted to remove all the periods except for the one
terminating every paragraph.
- Oliver
Oliver Wong
news:dauceb$qs1$1...@peabody.colorado.edu...
>
> On 11-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
>
>> I'm trying to write a program that reformats the structure of a
>> given COBOL program. One of the transformations I'd like to apply is to
>> try to eliminate as many periods as possibles, using the END-whatever
>> (END-IF, END-CALL, END-COMPUTE, etc.) constructs.
>
> Why?
Mainly to facilitate GOTO elimination. For example, given the code:
PROCEDURE DIVISION.
IF A THEN
DISPLAY "A"
GO TO TERM-PROC
END-IF
DISPLAY "B".
DISPLAY "C".
TERM-PROC.
EXIT PROGRAM.
I'll first remove all the periods (that don't terminate a paragraph) to get
PROCEDURE DIVISION.
IF A THEN
DISPLAY "A"
GO TO TERM-PROC
END-IF
DISPLAY "B"
DISPLAY "C"
.
TERM-PROC.
EXIT PROGRAM
.
and then I can transform it to:
PROCEDURE DIVISION.
IF A THEN
DISPLAY "A"
SET GOTOFLAG TO TRUE
END-IF
IF GOTOFLAG IS FALSE THEN
DISPLAY "B"
DISPLAY "C"
ENDIF
TERM-PROC.
EXIT PROGRAM.
Whereas if 'DISPLAY "B"' and 'DISPLAY "C"' had periods after them, it would
be more difficult for my code to group them together under the new IF THEN
clause.
> Is every statement that can use an END- clause going to have one?
For simplicity, yes. The output isn't meant to be read by humans, but rather
it's to serve as the input for yet more code manipulation algorithms.
>> My question is, is it always possible to do this? I don't want to
>> "cheat" by adding new paragraph names at the beginning of every sentence
>> (which may affect PERFORM statements anyway). My theory is that yes, it
>> is always possible, but I haven't been programming in COBOL for that
>> long, so I wasn't sure.
>
> It's not possible to do this when not all of the code is visible. If
> some of the code comes from inaccessible copy members or from
> precompilers, then it won't work.
Hmm, good point. I think my code can handle the COPY statements, but
it'll probably break with in the presence of conditional compilation
markers. Okay, thanks.
- Oliver
Colin Campbell
Wouldn't you want to simply substitute something like:
IF A
DISPLAY "A"
ELSE
DISPLAY "B"
DISPLAY "C"
END-IF
.
There is no need to introduce a variable, set it, and test it. In my
opinion, it doesn't "improve" the code; rather, it makes it even harder
to understand.
After nearly 40 years of programming, and working on the programs of
others, I can easily believe that you could find an example such as the
one you cited. They seem to be everywhere. However, I would be equally
unimpressed with the proposed "solution", because it takes what is
"simple, bad" code and replaces it with "not as simple, still bad" code.
Howard Brazee
On 11-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> Mainly to facilitate GOTO elimination. For example, given the code:
>
> PROCEDURE DIVISION.
> IF A THEN
> DISPLAY "A"
> GO TO TERM-PROC
> END-IF
> DISPLAY "B".
> DISPLAY "C".
> TERM-PROC.
> EXIT PROGRAM.
...
> and then I can transform it to:
>
> PROCEDURE DIVISION.
> IF A THEN
> DISPLAY "A"
> SET GOTOFLAG TO TRUE
> END-IF
> IF GOTOFLAG IS FALSE THEN
> DISPLAY "B"
> DISPLAY "C"
> ENDIF
> TERM-PROC.
> EXIT PROGRAM.
I'm a big proponent of structured code. But I would rather leave the GO TO in
unstructured code than replacing them with switches in that same code. My
distaste for the second piece of code above is real strong. Structured is a
lot more than GO TO - less code.
Does your restructure handle *real* spaghetti code? With GO TOs pointing all
over the place?
Mette Stephansen
> > PROCEDURE DIVISION.
> > IF A THEN
> > DISPLAY "A"
> > SET GOTOFLAG TO TRUE
> > END-IF
> > IF GOTOFLAG IS FALSE THEN
> > DISPLAY "B"
> > DISPLAY "C"
> > ENDIF
> > TERM-PROC.
> > EXIT PROGRAM.
>
code !
I have also been coding Cobol for 20 years - and the problems with
unstructured programs are note GOTO's .. it's the lousy algorithms
underneath, it's the use of hopeless variable names, its the use to swicthes
or flags ... and like here the introduction of error possibilities .... if
yo just add another statement after the second end_if (saying the section is
a lot longer and more complex than here) ... then we have to have all that
inside the second IF ..... just because that we for some reason dont like a
GOTO to an exit :-)
The way that we always code is ... always have sections and paragraphs,
always perform, never ever perform though, always just GOTO's to exits or
top of a section. Never sections bigger than 3 pages in your favorite
editor. + a couple of more items (no alter etc),
regards
Mette
Oliver Wong
"Colin Campbell" <cmc...@adelphia.net> wrote in message
news:TO2dnVxaoru...@adelphia.com...
> Oliver Wong wrote:
>>PROCEDURE DIVISION.
>> IF A THEN
>> DISPLAY "A"
>> SET GOTOFLAG TO TRUE
>> END-IF
>> IF GOTOFLAG IS FALSE THEN
>> DISPLAY "B"
>> DISPLAY "C"
>> ENDIF
>>TERM-PROC.
>> EXIT PROGRAM.
>
> IF A
> DISPLAY "A"
> ELSE
> DISPLAY "B"
> DISPLAY "C"
> END-IF
> .
Yes, if I, as a human, were refactoring the code, I'd write it the way
you put it. However the transformations are done by machine, and I felt it
was better to keep the algorithms simple (and thus "obviously correct"), and
then to perhaps later do an optimization pass to transform multiple IFs in
the format above to IF ELSEs and other such transformations.
- Oliver
Oliver Wong
> I'm a big proponent of structured code. But I would rather leave the GO
> TO in
> unstructured code than replacing them with switches in that same code.
> My
> distaste for the second piece of code above is real strong. Structured
> is a
> lot more than GO TO - less code.
I understand your distate (I share it as well), so let's just say that
"GO TO elimination" is a requirement for the project I'm working on. If the
code is "easy to understand", that's a plus, but it a non-negotiable
requirement for me that there be no GO TO statements.
> Does your restructure handle *real* spaghetti code? With GO TOs pointing
> all
> over the place?
That's the plan. In theory, the algorithms should be able to handle
everything (PERFORM THRUs, ALTERed GOTOs, fall through logic, the works)
except for SECTIONS with independent overlayed segments (which is low
priority because it doesn't seem to appear in any of my sample COBOL files,
but still laying in the back of my mind as a future problem I'll have to
eventually address).
In practice, I've just started trying to implement the algorithms, and
the first obstacle I've encountered is the desire to have just 1 sentence
per paragraph to make the future transformations more easy. So I started to
wonder if I could always transform a given COBOL program to an equivalent
one with only 1 sentence per paragraph, and I couldn't think of a reason why
not, but I thought I'd post on the newsgroup just in case.
- Oliver
Oliver Wong
"Mette Stephansen" <mm> wrote in message
news:42d2d4e0$0$4723$edfa...@dread15.news.tele.dk...
> In my opinion this coding style is a lot more unstructured than the
> original
> code !
>
> I have also been coding Cobol for 20 years - and the problems with
> unstructured programs are note GOTO's .. it's the lousy algorithms
> underneath, it's the use of hopeless variable names, its the use to
> swicthes
> or flags ... and like here the introduction of error possibilities .... if
> yo just add another statement after the second end_if (saying the section
> is
> a lot longer and more complex than here) ... then we have to have all that
> inside the second IF ..... just because that we for some reason dont like
> a
> GOTO to an exit :-)
Yes, unfortunately because these transformations I want to do are going
to be done by a computer, there'll be even more hopelessly meaningless
variable names, and introductions of lots of falgs and switches. As I
mentioned in another post though, the results of this transformation is not
intended to be read by human programmers, but it's just there to make code
analysis easier. Right now, all the algorithms I've seen for logic flow
analysis and the such work a lot better if there are zero GO TO statements
in the code.
As for the possibility for introducing a new error, I won't have to
worry about that too much, because all the modifications are going to be
done by automatic tools. So assuming that I can prove all my transformations
won't modify the semantics of the COBOL program, I know the tools will do
the right thing. Actually, that's the reason I asked this question about 1
sentence per paragraph in the first place; to make sure that my
transformation won't change the behaviour of the program!
- Oliver
Richard
> one with only 1 sentence per paragraph, and I couldn't think of a reason why not,
I can. It has been recently argu^H^H^H discussed here that a NEXT
SENTENCE embedded in a nested imperitive IF is allowed (some even think
it was deliberately allowed) and this will transfer control to after
the next full stop which may be at some arbitrary point.
In my view any such usage should cause the converter to put the output
and input to /dev/nul, and preverably the coder as well, but it does
mean that such a program cannot have that full stop removed.
docd...@panix.com
Oliver Wong <ow...@castortech.com> wrote:
>
>"Colin Campbell" <cmc...@adelphia.net> wrote in message
>news:TO2dnVxaoru...@adelphia.com...
[snip]
>> Wouldn't you want to simply substitute something like:
>> IF A
>> DISPLAY "A"
>> ELSE
>> DISPLAY "B"
>> DISPLAY "C"
>> END-IF
>> .
>
> Yes, if I, as a human, were refactoring the code, I'd write it the way
>you put it. However the transformations are done by machine, and I felt it
>was better to keep the algorithms simple (and thus "obviously correct"), and
>then to perhaps later do an optimization pass to transform multiple IFs in
>the format above to IF ELSEs and other such transformations.
Mr Wong, permit me to ask: have you ever read any code, before and after
versions, that's been run through a restructuring program?
DD
Peter Lacey
Assuming your code restructuring engine works: how does one go about
maintaining the code afterwards? This isn't meant to be a hostile
question. But it occurs to me that if, as you've pointed out, all
GOTO's >>must<< be removed, then the program may be totally unlike the
original even if it's functionally identical. Odds are good that
whatever specs and documentation exist (ha! as if) will now not be
applicable in large part without some sort of similar restructuring.
That's to say, the documentation to do with input/output/interfaces of
the program will still apply, but the black-box aspect of the
documentation will no longer describe what's under the hood of the
program.
Seems to me that TPB (The Poor Beggar who does maintenance) is going to
have to study the program line-by-line to make changes possible.
Whatever knowledge of the program existed prior to the conversion will
no longer apply. Given the supposition that there are very few new
people coming into COBOL, one wonders how maintenance will even get
done.
Respectfully,
Peter Lacey
Colin Campbell
DD,
That is a good point. My experience with "restructured" code is that in
most cases, a large, poorly structured program gets "structured" (though
often not in an easily understandable way - for human readers, I mean),
and the program tends to get about 20% larger, give or take.
Seems like there is very little "profit" in that....
HeyBub
Yes. Hunt around for the ETK Toolkit. It's a collection of about thirty
compiler-independent routines - some quite clever. The author was positively
anal about one period per paragraph.
Colin Campbell
All I find when I google on "ETK Toolkit" is a response you made at
another place, suggesting the use of the ETK Toolkit. Where do I find it?
Arnold Trembley
Arnold Trembley
docd...@panix.com
Colin Campbell <cmcampb_at_adelphia.net> wrote:
>docd...@panix.com wrote:
>
>>In article <AEAAe.105441$HI.1740@edtnps84>,
>>Oliver Wong <ow...@castortech.com> wrote:
[snip]
>>> Yes, if I, as a human, were refactoring the code, I'd write it the way
>>>you put it. However the transformations are done by machine, and I felt it
>>>was better to keep the algorithms simple (and thus "obviously correct"), and
>>>then to perhaps later do an optimization pass to transform multiple IFs in
>>>the format above to IF ELSEs and other such transformations.
>>>
>>>
>>
>>Mr Wong, permit me to ask: have you ever read any code, before and after
>>versions, that's been run through a restructuring program?
>>
>DD,
>That is a good point. My experience with "restructured" code is that in
>most cases, a large, poorly structured program gets "structured" (though
>often not in an easily understandable way - for human readers, I mean),
>and the program tends to get about 20% larger, give or take.
>
>Seems like there is very little "profit" in that....
But you get such... *intuitive* paragraph-names... like
A71342-D0841-PROCESS-RTN.
DD
Oliver Wong
> In article <AEAAe.105441$HI.1740@edtnps84>,
>
> Mr Wong, permit me to ask: have you ever read any code, before and after
> versions, that's been run through a restructuring program?
Back in highschool, my English teacher would always call me "Mr. Wong"
whenever I was in trouble, so now I've associated that unpleasant feeling
with that name. Feel free to call me "Oliver".
The closest I've come is using the Eclipse IDE to refactor my Java code,
with which I was quite pleased with the result. But really, I think that's
aside from the point. I'm not saying that the code produced from my
transformation will be anywhere as nice and clean as the transformations
Eclipse does. I'm not even saying that the transformations will look nice at
all on an absolute scale.
All I'm saying is that I've been given the task of writing code that
eliminates GO TO, ALTER, PERFORM THRU and other similar statements,
regardless of whether I think the resulting code will look pretty or not.
Now given these requirements, I'm seeking a bit of help, because I'm not
familiar with COBOL enough to just wade through and be confident that my
transformations won't change the behaviour of the program.
- Oliver
Oliver Wong
"Richard" <rip...@Azonic.co.nz> wrote in message
news:1121117821.0...@g14g2000cwa.googlegroups.com...
> I can. It has been recently argu^H^H^H discussed here that a NEXT
> SENTENCE embedded in a nested imperitive IF is allowed (some even think
> it was deliberately allowed) and this will transfer control to after
> the next full stop which may be at some arbitrary point.
>
> In my view any such usage should cause the converter to put the output
> and input to /dev/nul, and preverably the coder as well, but it does
> mean that such a program cannot have that full stop removed.
Hmm, interesting. I did not find any mention of "NEXT SENTENCE" in any
of the documentation I initially used as references for the COBOL language,
but based on the discussions I've found on the web, it looks like NEXT
SENTENCE is an unconditional jump to the statement immediately following the
period of the sentence containing the NEXT SENTENCE statement, as you've
said.
I think this would be one one case where I would have to add a new
paragraph name (to act as a label), then change the NEXT SENTENCE to a GO TO
which jumps to that label. All the while, I have to be check for any PERFORM
or PERFORM THRU statements that I might have to update to reflect the
addition of this new paragraph.
Thanks for the tip, I might have to factor in this new issue into the
algorithm design.
- Oliver.
Oliver Wong
"Peter Lacey" <la...@mb.sympatico.ca> wrote in message
news:42D31A48...@mb.sympatico.ca...
Excellent question. Michael Kasten has written an answer to this on "The
Kasten COBOL Page" (http://home.swbell.net/mck9/cobol/style/rewrite.html)
which probably phrases the answer much better than I ever could. He points
out that while the code is still in an unstructured (in the formal sense of
the word, i.e. containing 1 or more GO TO statements or similar construct),
a lot of changes you'd like to make (e.g. inserting a new paragraph) aren't
"safe" because you don't know what PERFORM or PERFORM THRU might be present.
You can't touch any GO TO statements, because there might be ALTER
statements elsewhere that modify them, and so on. By structuring the code
using this tool, you can now make a lot of assumptions about how control
flow progresses through the program. Sure, the resulting program is a mess,
but it's a mess that can be easily modified and fixed up, as compared to the
original program, which might have *looked* perfectly fine, but was
completely resistant to any modifications whatsoever. Anyway, the relevant
quote from Kasten's page follows:
[BEGIN QUOTE]
Some re-engineering tools can transform unstructured spaghetti code
into logically equivalent COBOL with no GO TOs or PERFORM THRUs. Such a tool
can begin a rewrite, and automate some of the drudgery, but the results
should not be regarded as a finished product. The tool is no more a
substitute for a programmer than an anvil is a substitute for a blacksmith.
[...]
Spaghetti code is almost always buggy code. The obvious bugs will have
already been eliminated by the time you inherit the program. The remaining
ones are subtle; they lie concealed in the convoluted logic until a human
being flushes them out.
If the restructuring tool does its job properly, it will carefully
preserve every bug in the original code. On the other hand, once the tool
has formally restructured the program, the bugs may be easier to recognize.
[END QUOTE]
- Oliver
docd...@panix.com
Oliver Wong <ow...@castortech.com> wrote:
><docd...@panix.com> wrote in message news:dauqfd$bh$1...@panix5.panix.com...
>> In article <AEAAe.105441$HI.1740@edtnps84>,
>>
>> Mr Wong, permit me to ask: have you ever read any code, before and after
>> versions, that's been run through a restructuring program?
>
> Back in highschool, my English teacher would always call me "Mr. Wong"
>whenever I was in trouble, so now I've associated that unpleasant feeling
>with that name. Feel free to call me "Oliver".
Back in grade school it was common knowledge among the boys that it was
best not to touch girls *at all* because they were infested with an
invisible horror called 'cooties' (not to be confused with the Southern
USA colloquialism 'cooties', or 'lice')... fortunately a few years have
passed since then and this has been proven wrong. During my Kollidj Daze
I attended an institution where all classes had three rules:
1) One person talks at a time.
2) Any opinion, unless substantiated by reasoned argument, can be
dismissed as 'mere opinion'.
3) Everyone, at all times, is to be referred to as Mr or Ms.
Since, of course, what one learns in college is supposed to be 'higher
education' (in the sense of 'more advanced') than what learns in high
school... well, I'll try not to offend o'ermuch.
>
> The closest I've come is using the Eclipse IDE to refactor my Java code,
>with which I was quite pleased with the result. But really, I think that's
>aside from the point. I'm not saying that the code produced from my
>transformation will be anywhere as nice and clean as the transformations
>Eclipse does. I'm not even saying that the transformations will look nice at
>all on an absolute scale.
Wow... I thought 'look nice' was an aesthetic judgement... are there
absolute scales for those things now? I'll take that as a 'no, I've never
read any code, before and after versions, that's been run through a
restructuring program'.
>
> All I'm saying is that I've been given the task of writing code that
>eliminates GO TO, ALTER, PERFORM THRU and other similar statements,
>regardless of whether I think the resulting code will look pretty or not.
All I'm saying is that this kind of task might require a bit of knowledge
and experience that you've yet to garner and whoever assigned it to you
might do well to reconsider the criteria which are taken into account when
it comes to doling out work... granted that I do not believe I can lower
the quality of my thinking far enough to be Management but I'd say that a
good foundation for this kind of work would be a few years spent doing
maintenance/enhancement programming.
>Now given these requirements, I'm seeking a bit of help, because I'm not
>familiar with COBOL enough to just wade through and be confident that my
>transformations won't change the behaviour of the program.
Given the various ways that the execution of code can be directed it might
be wise to become more familiar with COBOL. GO TO, ALTER, PERFORM THRU
all concern themselves with code contained in sections/paragraphs in that
they address labels... NEXT SENTENCE, however, is a slightly different
kettle o' fish.
Bona fortuna!
DD
docd...@panix.com
Oliver Wong <ow...@castortech.com> wrote:
[snip]
> Hmm, interesting. I did not find any mention of "NEXT SENTENCE" in any
>of the documentation I initially used as references for the COBOL language,
>but based on the discussions I've found on the web, it looks like NEXT
>SENTENCE is an unconditional jump to the statement immediately following the
>period of the sentence containing the NEXT SENTENCE statement, as you've
>said.
Leaving aside the persnickety labelling for statement, sentence,
imperative, instruction, what happens at the end of a paragraph (etc)...
would someone pass this along to The Standards Folks and ask them for what
reason - given this level of interpretation shown by a rank neophyte -
they think the function of NEXT SENTENCE is so difficult to grasp?
Well done, Mr Wong!
DD
Oliver Wong
"HeyBub" <heybub...@gmail.com> wrote in message
news:11d6am6...@news.supernews.com...
Formally, to prove that it's always possible to write a COBOL program
with one period per paragraph, it isn't enough to just give examples of
COBOL programs which are written with one period per paragraph. Rather, you
need to present some sort of logical proof; However, you can disprove the
statement by giving an example of a COBOL program which cannot be rewritten
with just one period per paragraph. (Remember all those science test
questions which start with "Prove or give a counterexample"?)
Still, the ETK is a neat library. Thanks.
- Oliver
Howard Brazee
On 11-Jul-2005, docd...@panix.com wrote:
> Mr Wong, permit me to ask: have you ever read any code, before and after
> versions, that's been run through a restructuring program?
>
> DD
Those of us who have aren't in any hurry to spend the money on another one.
Michael Mattias
> > I'm trying to write a program that reformats the structure of a
> > given COBOL program. One of the transformations I'd like to apply is
> > to try to eliminate as many periods as possibles, using the
> > END-whatever (END-IF, END-CALL, END-COMPUTE, etc.) constructs.
> >
> > My question is, is it always possible to do this? I don't want to
> > "cheat" by adding new paragraph names at the beginning of every
> > sentence (which may affect PERFORM statements anyway). My theory is
> > that yes, it is always possible, but I haven't been programming in
> > COBOL for that long, so I wasn't sure.
Well, if this program is for internal use only, you may not have to deal
with "always." If your program logic encounters something you can't handle
(e.g., nesting level too deep, END-whatevers already mixed in, NEXT
SENTENCE, etc), you could always write your output with some kind of token
you could search for and leave those paragraphs/blocks for manual
reformatting after your program has done the bulk of the work.
FWIW, if you really haven't been programming in COBOL all that long and you
intend this to be a 'generic' tool, be forewarned that you are going to
encounter some code construction you would have never imagined.
MCM
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> All I'm saying is that I've been given the task of writing code that
> eliminates GO TO, ALTER, PERFORM THRU and other similar statements,
> regardless of whether I think the resulting code will look pretty or not.
> Now given these requirements, I'm seeking a bit of help, because I'm not
> familiar with COBOL enough to just wade through and be confident that my
> transformations won't change the behaviour of the program.
I've been given stupid tasks to perform before also.
Do you have code with ALTER in it?
Howard Brazee
On 11-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> In practice, I've just started trying to implement the algorithms, and
> the first obstacle I've encountered is the desire to have just 1 sentence
> per paragraph to make the future transformations more easy.
I'm not convinced getting rid of periods will make future transformations more
easy.
> So I started to
> wonder if I could always transform a given COBOL program to an equivalent
> one with only 1 sentence per paragraph, and I couldn't think of a reason why
> not, but I thought I'd post on the newsgroup just in case.
I mentioned invisible code (pre-compiler, copies, etc). The other issue that
you should be careful is NEXT SENTENCE. The standard does not allow NEXT
SENTENCE with END-IF, but some compilers (IBM mainframes) do allow it.
Certainly if you're concerned about ALTER, you should be concerned with NEXT
SENTENCE.
Some people who believe in the one period per paragraph, use NEXT SENTENCE as a
way to terminate a paragraph. I dislike this intensely, but I like periods
within my paragraph. It appears that it is within your mandate to eliminate
NEXT SENTENCE altogether, I'd consider doing so if I were you. Trouble is,
converting NEXT SENTENCE to CONTINUE isn't a trivial task, and will require
parsing.
Another hard to parse code is with "D" in column 6.
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
[snip]
>Another hard to parse code is with "D" in column 6.
I'm familiar with designating debugging code (SOURCE-COMPUTER. xxxxxxx
WITH DEBUGGING MODE.) by putting a 'D' in column 7... what does putting
a 'D' in the last column of the card's sequence number do?
DD
Howard Brazee
what would your results look like?
PERFORM SECTION-NAME THROUGH PARAGRAPH-EXIT UNTIL M=N.
SECTION-NAME SECTION.
PARAGRAPH-NAME.
IF A=B
PERFORM READ-NEXT
D IF C=D
D NEXT SENTENCE;
ELSE
GO TO PARAGRAPH-EXIT
END-IF
PERFORM WRITE-OUTPUT
PERFORM WRITE-ERROR.
COPY ABCDE.
GO TO PARAGRAPH-NAME.
PARAGRAPH-EXIT.
EXIT.
where
ABCDE contains:
ABCDE.
PERFORM CHECK-SUM
IF Z=Z1 GO TO ABCDE
PERFORM CHECK-SUM2.
PERFORM CHECK-SUM3.
ABCDE-EXIT.
EXIT.
Oliver Wong
>
> Do you have code with ALTER in it?
I'd have to check; I've got about 470 test COBOL source files, but I
haven't actually read through all of them yet. Regardless of whether an
ALTER statement actually appears in any of them (though I suspect that it
probably does appear somewhere at least once), the tool I'm working on is
expected to eventually be able to handle ALTER statements; so if it none of
the test files contain an ALTER, I'd probably have to write a few new test
files to be sure the transformation works.
- Oliver
Oliver Wong
>
> I'm not convinced getting rid of periods will make future transformations
> more
> easy.
In one scenario for a GO TO elimination, I have to take a series of
statements and put them in the body of an IF THEN clause. If these
statements occur in consecutive, but distinct sentences, then I don't think
I can actually put them in the THEN clause, because a THEN clause can
contain a sequence of statements, but not a sequence of sentences. If I can
convert these sentences into statements (what visually amounts of "removing
the periods"), then I can put all those statements in the THEN clause
without much problem.
>
>> So I started to
>> wonder if I could always transform a given COBOL program to an equivalent
>> one with only 1 sentence per paragraph, and I couldn't think of a reason
>> why
>> not, but I thought I'd post on the newsgroup just in case.
>
> I mentioned invisible code (pre-compiler, copies, etc). The other issue
> that
> you should be careful is NEXT SENTENCE. The standard does not allow
> NEXT
> SENTENCE with END-IF, but some compilers (IBM mainframes) do allow it.
> Certainly if you're concerned about ALTER, you should be concerned with
> NEXT
> SENTENCE.
>
> Some people who believe in the one period per paragraph, use NEXT SENTENCE
> as a
> way to terminate a paragraph. I dislike this intensely, but I like periods
> within my paragraph.
You mean they make the last statement in a paragraph be "NEXT SENTENCE"
as sort of an indicator that this is the last statement in the paragraph?
That does seem strange to me as well.
> It appears that it is within your mandate to eliminate
> NEXT SENTENCE altogether, I'd consider doing so if I were you. Trouble
> is,
> converting NEXT SENTENCE to CONTINUE isn't a trivial task, and will
> require
> parsing.
I've already written a COBOL parser to generate a parse tree, so that
latter requirement isn't a problem for me. As for eliminating NEXT SENTENCE,
I haven't encountered that in any of my test files, nor in any of the
reference documentation I've been using (I think they were the references
for VS COBOL/II, RM COBOL and ANSI 85 COBOL), but it is something that I'll
will probably eventually look into. I posted a strategy in another thread. I
was wondering if you thought this was a feasible strategy:
[BEGIN QUOTE, with some typos corrected]
I think this would be one of the few cases where I would have to add a
new
paragraph name (to act as a label), then change the NEXT SENTENCE to a GO TO
which jumps to that label. All the while, I have to be check for any PERFORM
or PERFORM THRU statements that I might have to update to reflect the
addition of this new paragraph.
[END QUOTE]
> Another hard to parse code is with "D" in column 6.
Yeah, I wasn't sure what the semantics were of indicator codes in column
6. From my understand, a "*" denotes that the line should be ignored (as in
a comment), and any alphabetic character indicates a conditional compilation
line, so that all the lines marked with "A" could be toggled on or off
independently of all the lines with "B" and so on, with "D" being, by
convention (but with no particularly special support), being reserved for
debugging code. Is this understanding correct?
- Oliver
Oliver Wong
news:bEPAe.592$8y1...@newssvr17.news.prodigy.com...
> Well, if this program is for internal use only, you may not have to deal
> with "always." If your program logic encounters something you can't handle
> (e.g., nesting level too deep, END-whatevers already mixed in, NEXT
> SENTENCE, etc), you could always write your output with some kind of token
> you could search for and leave those paragraphs/blocks for manual
> reformatting after your program has done the bulk of the work.
Hmm, that's an interesting strategy, though I think it might not be
compatible with the requirements I was given. Still, I might adapt something
similar (inserting special marker tokens for intermediate results between
two transformations, for example).
> FWIW, if you really haven't been programming in COBOL all that long and
> you
> intend this to be a 'generic' tool, be forewarned that you are going to
> encounter some code construction you would have never imagined.
Yeah, I have about 470 test COBOL files, some of which illustrating some
pretty degenerate cases which I had not expected while writing my first
prototype parser. Probably the most painful are line comments appearing
between line continuations, as in:
[ Line 1: Some COBOL Statement]
*[ Line 2: A Comment]
-[ Line 3: Continuation of line 1]
which when combined with COPY REPLACE statements (e.g. something half on
line 1, half on line 3 needs to get replaced) can become quite painful to
handle.
- Oliver
Chuck Stevens
> Leaving aside the persnickety labelling for statement, sentence,
> imperative, instruction, what happens at the end of a paragraph (etc)...
> would someone pass this along to The Standards Folks and ask them for what
> reason - given this level of interpretation shown by a rank neophyte -
> they think the function of NEXT SENTENCE is so difficult to grasp?
Well, I guess I'd qualify as A Standards Folk.
What the standard says NEXT SENTENCE ought to do is very clear, and as
stated above. The contexts in the standard in which NEXT SENTENCE may
appear are also clear (and limited strictly to undelimited IF and
undelimited SEARCH statements).
The two problems discussed in the '02 standard can be found on Page 833:
"It is a common belief among users that control is transferred to a position
after the scope delimiter rather than to a separator period that follows it
somewhere. In addition, it is a common source of errors, especially for
maintenance programmers who inadvertently insert a period somewhere before
the actual terminating separator period."
A third unstated issue is that use of NEXT SENTENCE outside the limited
contexts in which the standard allows is a very common implementor extension
(e.g., AT END, INVALID KEY, SIZE ERROR, etc., etc., and their corresponding
NOT phrases). That complicates its interpretation.
A fourth unstated issue is that at least one implementation has supported
the perpetuation in the user community of the misapprehension as to where
NEXT SENTENCE is supposed to transfer control. It is my understanding that
this error is in the process of being corrected, but because of the large
body of existing programs that might be dependent on this erroneous
presumption, the vendor's policy and agreements with its customers requires
a long period of stern warnings from the compiler before the change can
actually be made.
A fifth unstated issue is that *before* the introduction of scope delimiters
NEXT SENTENCE could in most cases reasonably be considered an imperative
statement on its own without impacting parsing much if at all. That
fostered its use in contexts in which the standard did not provide for it
(see issue #3 above).
As the standard says as its closing defense of the archaization of NEXT
SENTENCE, "The CONTINUE statement and scope delimiters can be used to
accomplish the same functionality and such constructs are clearer and less
prone to error."
-Chuck Stevens
Howard Brazee
On 12-Jul-2005, docd...@panix.com wrote:
> >Another hard to parse code is with "D" in column 6.
>
> I'm familiar with designating debugging code (SOURCE-COMPUTER. xxxxxxx
> WITH DEBUGGING MODE.) by putting a 'D' in column 7... what does putting
> a 'D' in the last column of the card's sequence number do?
My bad. Column 7 - or with some compilers optionally column 1.
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> > Do you have code with ALTER in it?
>
> I'd have to check; I've got about 470 test COBOL source files, but I
> haven't actually read through all of them yet. Regardless of whether an
> ALTER statement actually appears in any of them (though I suspect that it
> probably does appear somewhere at least once), the tool I'm working on is
> expected to eventually be able to handle ALTER statements; so if it none of
> the test files contain an ALTER, I'd probably have to write a few new test
> files to be sure the transformation works.
Why do you suspect they might occur at least once? I haven't seen one in
decades and they are no longer supported.
Depending upon your employment status, and how likely you think they might be,
you might want to propose simply doing exception reporting with ALTER
statements.
Hmm. If you have ALTER statements, you might also have memory segmentation by
SECTION. I'd also do exception reporting if you find this, as determining such
needs isn't trivial. Again - I haven't seen this in decades either.
Michael Mattias
news:_zQAe.106822$HI.2697@edtnps84...
> "Michael Mattias" <michael...@gte.net> wrote in message
> news:bEPAe.592$8y1...@newssvr17.news.prodigy.com...
> > Well, if this program is for internal use only, you may not have to deal
> > with "always." If your program logic encounters something you can't
handle
> > (e.g., nesting level too deep, END-whatevers already mixed in, NEXT
> > SENTENCE, etc), you could always write your output with some kind of
token
> > you could search for and leave those paragraphs/blocks for manual
> > reformatting after your program has done the bulk of the work.
>
> Hmm, that's an interesting strategy, though I think it might not be
> compatible with the requirements I was given. Still, I might adapt
something
> similar (inserting special marker tokens for intermediate results between
> two transformations, for example).
"Convert anything and everything with a single automated program" is a poor
spec if the goal is "convert all our programs." I have no doubt that most
constructions can be converted virtually 'on sight' by an experienced COBOL
programmer. If your program can handle 90% of situations, the programmer now
only has to "sight" ten (10) percent of the total workload. So how much does
a 90 percent reduction of "sight" save, versus the time necessary to make
your program handle that additional extra ten percent?
To make your program handle that last ten percent seems waste of time and
money. (Intuitive/visceral, not empirical).
Of course, I have twenty-plus years as an executive accustomed to thinking
'bottom line."
Then again, you may be working for a government agency, where no such
'bottom line' thinking is allowed.
MCM
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> > Some people who believe in the one period per paragraph, use NEXT SENTENCE
> > as a
> > way to terminate a paragraph. I dislike this intensely, but I like periods
> > within my paragraph.
>
> You mean they make the last statement in a paragraph be "NEXT SENTENCE"
> as sort of an indicator that this is the last statement in the paragraph?
> That does seem strange to me as well.
I mean they use it to mean EXIT PARAGRAPH.
PARAGRAPH-NAME.
READ MY-FILE AT END NEXT SENTENCE
PERFORM A
PERFORM B
PERFORM C
CONTINUE.
NEXT PARAGRAPH.
> I've already written a COBOL parser to generate a parse tree, so that
> latter requirement isn't a problem for me. As for eliminating NEXT SENTENCE,
> I haven't encountered that in any of my test files, nor in any of the
> reference documentation I've been using (I think they were the references
> for VS COBOL/II, RM COBOL and ANSI 85 COBOL), but it is something that I'll
> will probably eventually look into. I posted a strategy in another thread. I
> was wondering if you thought this was a feasible strategy:
It's a lot, lot more common than ALTER.
> > Another hard to parse code is with "D" in column 6.
>
> Yeah, I wasn't sure what the semantics were of indicator codes in column
> 6.
I meant "7'. Sorry.
> From my understand, a "*" denotes that the line should be ignored (as in
> a comment), and any alphabetic character indicates a conditional compilation
> line, so that all the lines marked with "A" could be toggled on or off
> independently of all the lines with "B" and so on, with "D" being, by
> convention (but with no particularly special support), being reserved for
> debugging code. Is this understanding correct?
* is a comment. I'm not familiar with A and B.
People often comment out code with expectations that they can uncomment it and
have it work.
IF A=B
** AND C=D
PERFORM DEF
** DEF is my new routine asked for by Joe Smith
END-IF.
You may have to decide manually whether a comment is such code and what to do
about it.
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> [ Line 1: Some COBOL Statement]
> *[ Line 2: A Comment]
> -[ Line 3: Continuation of line 1]
>
> which when combined with COPY REPLACE statements (e.g. something half on
> line 1, half on line 3 needs to get replaced) can become quite painful to
> handle.
Don't forget to make sure your formatting doesn't move code into column 73 or
beyond.
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
><docd...@panix.com> wrote in message news:db0gd8$amg$1...@panix5.panix.com...
>
>> Leaving aside the persnickety labelling for statement, sentence,
>> imperative, instruction, what happens at the end of a paragraph (etc)...
>> would someone pass this along to The Standards Folks and ask them for what
>> reason - given this level of interpretation shown by a rank neophyte -
>> they think the function of NEXT SENTENCE is so difficult to grasp?
>
>Well, I guess I'd qualify as A Standards Folk.
Makes the passing-along rather easy, it seems.
[snip]
>The two problems discussed in the '02 standard can be found on Page 833:
>"It is a common belief among users that control is transferred to a position
>after the scope delimiter rather than to a separator period that follows it
>somewhere.
Given that Mr Wong is a moderate neophyte and concluded from his research
that 'based on the discussions I've found on the web, it looks like NEXT
SENTENCE is an unconditional jump to the statement immediately following
the period of the sentence containing the NEXT SENTENCE statement' it
seems that he managed sidestep this 'common belief'... but perhaps those
who post to this group are, by definition, rather uncommon.
DD
Chuck Stevens
> Some people who believe in the one period per paragraph, use NEXT SENTENCE
as a
> way to terminate a paragraph. I dislike this intensely, but I like
periods
> within my paragraph. It appears that it is within your mandate to
eliminate
> NEXT SENTENCE altogether, I'd consider doing so if I were you. Trouble
is,
> converting NEXT SENTENCE to CONTINUE isn't a trivial task, and will
require
> parsing.
As alluded to earlier, NEXT SENTENCE in the two contexts in which the '85
standard allows it -- non-delimited IF statements and non-delimited SEARCH
statements -- is an archaic element of '02 COBOL, which carries with it the
implication that its use is deprecated. Thus, getting rid of NEXT SENTENCE
altogether is indeed a laudable goal.
That being said, in standard COBOL, the only effective contexts in which
NEXT SENTENCE can appear immedately before the period terminating a sentence
(whether the last or only sentence of a paragraph or not) is as part of the
ELSE phrase of a non-delimited IF statement, or as part of the last WHEN
phrase of a non-delimited SEARCH.
While CONTINUE is a STATEMENT and can stand alone, NEXT SENTENCE is a
PHRASE.
Put another way, in standard COBOL the following is legal:
PARAGRAPH-1.
MOVE A TO B.
CONTINUE.
PARAGRAPH-2.
...
while the following is not:
PARAGRAPH-1.
MOVE A TO B.
NEXT SENTENCE.
PARAGRAPH-2.
...
Note that I have learned from decades of painful experience supporting COBOL
(and other language) compilers that it is unwise to presume "Nobody in his
right mind would dream of even considering the possibility of writing
something like that." .
-Chuck Stevens
Oliver Wong
> Why do you suspect they might occur at least once? I haven't seen one
> in
> decades and they are no longer supported.
The the majority of the test files aren't "real" COBOL programs that do
anything "useful", but rather are intended to illustrate as many different
"things" that a correct ANSI 85 COBOL compiler should be able to handle. At
the very least, I'd expect each statement to appear at least once.
> Depending upon your employment status, and how likely you think they might
> be,
> you might want to propose simply doing exception reporting with ALTER
> statements.
>
> Hmm. If you have ALTER statements, you might also have memory
> segmentation by
> SECTION. I'd also do exception reporting if you find this, as
> determining such
> needs isn't trivial. Again - I haven't seen this in decades either.
I've done some research on the semantics of independent segments in
SECTION declarations, and this is one of the obstacles I cannot currently
handle.
The strategy we're using right now is "start with the easy cases, and
work your way up". So right now I'm trying to eliminate COBOL programs with
just a single GO TO, no ALTER or PERFORM/PERFORM THRU or segmentation or
anything like that. Gotta be able to handle GO TO in IF statements, loops,
EVALUATE statements, and all those fun cases. Luckily, unlike some other
languages, it seems like in COBOL you can only use GO TO to jump out of
these constructs, not into the constructs. Once I've got all those cases
working, I can start worrying about PERFORM THRUs and ALTERs. And then from
there, maybe it'll become more clear how to handle segmentation. Worst case,
as you've said, is for the tool to simply detect segmentation and give up,
reporting an error.
- Oliver
Peter Lacey
This discussion has encouraged me to pose a question to the group which
I've been contemplating for some time. One of the goals of tools like
this is to eliminate spaghetti code. Accepting that as a good thing,
the question arises: exactly what is spaghetti code? If GOTO =
spaghetti code - that is, if a program that uses GOTO's is automatically
defined as SC, then there's not much to discuss except whether we agree
with the definition or not. But that strikes me as much too
simple-minded. Examples in texts that I've seen show program flow
leaping from one end of the program to another, allegedly because the
programmer kept on thinking of things he'd missed or wanting to reuse
code. It's always struck me that those practices are very much rookie
mistakes. I can't believe that anyone with some experience under
his/her belt and any level of aptitude for the job would continue doing
so.
I've encountered one example of this - which I called disaster code, not
just spaghetti code - written in BASIC; every statement was followed by
a GOTO to some other part of the program (EVERY statement except the
start & end!); this was a commercial accounting package and the
rationale was to make theft of the code more difficult; by gum, it
succeeded at that! And there has been just one COBOL program (by
somebody else, of course) that I have not been able to follow - the only
one I ever gave up in disgust on and rewrote; its problem was that it
had READ's all over the place and I couldn't work out what the heck it
was doing.
Anyway: I'd like to hear some definitions and examples!
Peter
Chuck Stevens
> PARAGRAPH-NAME.
> READ MY-FILE AT END NEXT SENTENCE
> PERFORM A
> PERFORM B
> PERFORM C
> CONTINUE.
> NEXT PARAGRAPH.
NEXT SENTENCE in AT END is a vendor extension, not standard COBOL.
Presuming '85 COBOL, how about something like:
PARAGRAPH-NAME.
READ MY-FILE
AT END
CONTINUE
NOT AT END
PERFORM A
PERFORM B
PERFORM C
END-READ.
NEXT-PARAGRAPH.
-Chuck Stevens
Oliver Wong
> Here's some ugly code that compiles with my compiler. After converting
> it,
> what would your results look like?
Probably not what you'd "want" =P. First of all, the code isn't there
yet, so if I were to actually post some COBOL code, it would be me as a
human trying to mechanically follow through the steps of the algorithm, and
quite probably making mistakes here and there. Second, a lot of simplifying
assumptions were made during the design of this tool. For example, during
the parse phase, all conditional compilation lines (e.g. the ones with "D"
in the indicator field) are treated as comments, and the contents of
copybooks are inserted right into the code, so that the next phases can
assume that all preprocessing has been done.
Please recall that the output produced by this tool isn't meant to be
read by humans, but rather, will serve as the input for other tools.
- Oliver
Chuck Stevens
Implementation-specific. The location of Margin R has been defined by the
individual implementor since no later than the '74 standard. I have some
reason to think that ANSI X3.23-1968 may have specified Margin R as being
between columns 72 and 73 of the source image, but in ANSI X3.23-1974 and
subsequent standards (including ISO/IEC 1989:2002 fixed-form reference
format) it's clear that it's up to the compiler writer how long Area B is.
-Chuck Stevens
jce
> <docd...@panix.com> wrote in message news:dauqfd$bh$1...@panix5.panix.com...
>> In article <AEAAe.105441$HI.1740@edtnps84>,
<snip snip>
> All I'm saying is that I've been given the task of writing code that
> eliminates GO TO, ALTER, PERFORM THRU and other similar statements,
> regardless of whether I think the resulting code will look pretty or not.
> Now given these requirements, I'm seeking a bit of help, because I'm not
> familiar with COBOL enough to just wade through and be confident that my
> transformations won't change the behaviour of the program.
>
> - Oliver
I wish I worked somewhere that had enough $$$ to spend on this type of
requirement.
Please, go through the works of Coleridge and remove all instances of
"dialogue" as a verb..we don't care about the aesthetics or the art of his
work. We are looking to satisfy the definition of the word according to 11
members of the board - and right now there is concern about the confusion
caused by having "archaic" words populate our world forums.
JCE
Oliver Wong
Writing language tools (e.g. parsers, compilers, etc.) means I had to
read whatever language reference and documentations much more carefully than
I might otherwise have done if I were merely interested in learning how to
program in said language. For example, I felt I was a relatively
knowlegeable Java programmer, but it was't until I wrote Java compilation
tools that I had heard about the strict_fp modifier, or that you could
declare functions in the form "public int foo()[][][] { /*body of
function*/ }".
And it is certainly possible that if you use this newsgroup as a sample
space to perform some surveys on COBOL programmers, your results may
certainly be skewed.
- Oliver
Oliver Wong
"Chuck Stevens" <charles...@unisys.com> wrote in message
news:db0ma9$e55$1...@si05.rsvl.unisys.com...
>
> While CONTINUE is a STATEMENT and can stand alone, NEXT SENTENCE is a
> PHRASE.
Could you clarify this a bit? I have only a vague understanding of the
hierarchy of statements and sentences and such. For me, the clearest picture
of this hierarchy is
http://www.csis.ul.ie/COBOL/Course/Resources/pics/CobolStructure.gif , but
the documentation I've seen often refers to phrases and clauses and such,
and I'm not sure what the significance of all these names are.
- Oliver
Oliver Wong
>
> * is a comment. I'm not familiar with A and B.
I've encountered code where it seems any alphabetic character can appear
in the indicator column, and the stuff in the "main code area" seemed to be
exectuable COBOL statements (i.e. not merely comments), so I had assumed
these characters served as some sort of conditional compilation flags.
Here's a random snippet from one of my test files (hopefully word wrapping
won't mangle up this code; just in case, I've added an initial full line of
hyphens to indicate the intended width the code should display at).
--------------------------------------------------------------------------------
025700 WRITE-LINE.
IF1114.2
025800 ADD 1 TO RECORD-COUNT.
IF1114.2
025900Y IF RECORD-COUNT GREATER 42
IF1114.2
026000Y MOVE DUMMY-RECORD TO DUMMY-HOLD
IF1114.2
026100Y MOVE SPACE TO DUMMY-RECORD
IF1114.2
026200Y WRITE DUMMY-RECORD AFTER ADVANCING PAGE
IF1114.2
026300Y MOVE CCVS-H-1 TO DUMMY-RECORD PERFORM WRT-LN 2 TIMES
IF1114.2
026400Y MOVE CCVS-H-2A TO DUMMY-RECORD PERFORM WRT-LN 2 TIMES
IF1114.2
026500Y MOVE CCVS-H-2B TO DUMMY-RECORD PERFORM WRT-LN 3 TIMES
IF1114.2
026600Y MOVE CCVS-H-3 TO DUMMY-RECORD PERFORM WRT-LN 3 TIMES
IF1114.2
026700Y MOVE CCVS-C-1 TO DUMMY-RECORD PERFORM WRT-LN
IF1114.2
026800Y MOVE CCVS-C-2 TO DUMMY-RECORD PERFORM WRT-LN
IF1114.2
026900Y MOVE HYPHEN-LINE TO DUMMY-RECORD PERFORM WRT-LN
IF1114.2
027000Y MOVE DUMMY-HOLD TO DUMMY-RECORD
IF1114.2
027100Y MOVE ZERO TO RECORD-COUNT.
IF1114.2
- Oliver
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> The strategy we're using right now is "start with the easy cases, and
> work your way up". So right now I'm trying to eliminate COBOL programs with
> just a single GO TO, no ALTER or PERFORM/PERFORM THRU or segmentation or
> anything like that
Decide whether you want to eliminate SECTIONs and all drop through paragraphs.
Figure out how you are going to change copy members or database includes.
Obviously you can't change one of these without affecting all programs that use
them.
Even if you don't handle these now, you will need to have a planned strategy so
that your "easy cases" fit into the big picture.
Does your new compiler have some of the very newest features such as EXIT
PARAGRAPH?
Howard Brazee
On 12-Jul-2005, Peter Lacey <la...@mb.sympatico.ca> wrote:
> This discussion has encouraged me to pose a question to the group which
> I've been contemplating for some time. One of the goals of tools like
> this is to eliminate spaghetti code.
Let me try.
Spaghetti code is designed around flow. It's a highway where each decision has
us leave the highway, perform a task, and then continue the journey. There is
no requirement that we return to the highway via the same exit we left. Maybe
I left at exit 180, drove around looking for a restaurant that interested me,
and returned to exit 178 to finish my journey. It is possible to save time
taking the shortcut back to the freeway, but it is also possible to get lost.
A GO TO can direct you to exit 178 (or 176), or you can have a series of
switches that tell you where to turn at each street until you get to exit 178
(or 176). Either way is spaghetti code.
Structured flow is more atomic in nature. It is a step towards OO, but not
really there. We are using maps. When we exit on exit 180, we return to exit
180 to continue our journey. Every time we leave the main path, we return to
the exact same spot. Each paragraph performs a function and then returns.
Complicated functions have sub-functions, but the concept is the same. Since
you don't return via exit 178, you don't need the GOTO.
Howard Brazee
On 12-Jul-2005, "Chuck Stevens" <charles...@unisys.com> wrote:
> Put another way, in standard COBOL the following is legal:
> PARAGRAPH-1.
> MOVE A TO B.
> CONTINUE.
> PARAGRAPH-2.
> ...
>
> while the following is not:
> PARAGRAPH-1.
> MOVE A TO B.
> NEXT SENTENCE.
> PARAGRAPH-2.
Speaking of CONTINUE...
The following is legal:
MY-PARAGRAPH-EXIT.
D DISPLAY "REACHED MY-PARAGRAPH-EXIT".
CONTINUE.
While the following depends on whether DEBUGING MODE is ON.
MY-PARAGRAPH-EXIT.
D DISPLAY "REACHED MY-PARAGRAPH-EXIT".
EXIT.
Chuck Stevens
The diagram you cite lacks entirely the concept of "phrase". Statements
contain *phrases* according to their individual syntax diagrams (e.g., the
WHEN phrase of the SEARCH statement, the AT END phrase of the READ
statement). There should thus be one more level of "nesting" in the
diagram if it is intended to include all concepts. The appropriate and
ultimate authority on the subject of the component parts of a COBOL source
program that conforms to the 1985 standard is, of course, ANSI X3.23-1985.
A given "phrase" is meaningful only in the context of the "statement" that
includes it in its syntax diagram.
The only places standard COBOL allows the NEXT SENTENCE "phrase" are the
following:
1) IF <some-condition> NEXT SENTENCE
2) IF <some-condition> <imperative-statement> ELSE NEXT SENTENCE
3) IF <some-condition> NEXT SENTENCE ELSE NEXT SENTENCE [yes, this is
allowed!]
4) SEARCH ... WHEN <some-condition> NEXT SENTENCE
5) SEARCH ALL ... WHEN <key comparison> NEXT SENTENCE
The standard explicitly disallows
1) IF ... NEXT SENTENCE ... END-IF [whether the phrase appears before
or after ELSE]
2) SEARCH ... NEXT SENTENCE END-SEARCH [whether SEARCH or SEARCH ALL]
Conditional statements include *NON-delimited* varieties of: EVALUATE; IF;
SEARCH; RETURN; READ with [NOT] AT END or [NOT] INVALID KEY; WRITE with
[NOT] INVALID KEY or [NOT] AT END-OF-PAGE; DELETE, REWRITE or START with
[NOT] INVALID KEY; ADD, SUBTRACT, MULTIPLY, DIVIDE or COMPUTE with [NOT] ON
SIZE ERROR; RECEIVE ... NO DATA; RECEIVE ... WITH DATA; STRING or UNSTRING
with [NOT] ON OVERFLOW; and CALL with ON OVERFLOW or [NOT] ON EXCEPTION.
The *ONLY* ones of these in which NEXT SENTENCE is allowed as an alternative
for an imperative statement are IF and SEARCH.
Delimited versions of the above are *imperative* statements in and of
themselves.
It is a MISTAKE to assume that NEXT SENTENCE can be substituted for any
imperative statement in standard COBOL.
It is a MISTAKE to assume that NEXT SENTENCE can be used as a part of any
conditional statement om stamdard COBOL.
If an implementor allows either of these assumptions, it does so as an
implementor extension to standard COBOL.
-Chuck Stevens
"Oliver Wong" <ow...@castortech.com> wrote in message
news:txRAe.106836$HI.57415@edtnps84...
Oliver Wong
>
> Decide whether you want to eliminate SECTIONs and all drop through
> paragraphs.
Though not a requirement, I will probably end up removing all SECTIONs
and drop through paragraphs, as a lot of the ideas I'm using are based on
Micheal Kasten's recommendations in "Rewriting Spaghetti Code"
(http://home.swbell.net/mck9/cobol/style/rewrite.html) in which he
recommends such eliminations.
> Figure out how you are going to change copy members or database includes.
> Obviously you can't change one of these without affecting all programs
> that use
> them.
Hmm, this is a very good point. I realized I haven't fully thought out
how to handle modification of copy members yet. Thanks.
> Even if you don't handle these now, you will need to have a planned
> strategy so
> that your "easy cases" fit into the big picture.
>
> Does your new compiler have some of the very newest features such as EXIT
> PARAGRAPH?
Not sure I understand the question, but I'm tempted to answer yes. Some
of the code that my tools will have to handle may contain the EXIT PARAGRAPH
statement, and some of the code that my tools output may contain the EXIT
PARAGRAPH statement, and as far as I know, there is currently no plan on
eliminating such statements.
- Oliver
ep...@juno.com
> This discussion has encouraged me to pose a question to the group which
> I've been contemplating for some time. One of the goals of tools like
> this is to eliminate spaghetti code. Accepting that as a good thing,
> the question arises: exactly what is spaghetti code?
For some great examples, see recent long program listings in
comp.lang.fortran. :-).
It's not just GOTOs at fault. Calling subroutines peppered around the
program in seemingly random order is also a problem. Here's an
operational definition of spaghetti code in approximate order of
severity:
1. I really can't fathom what the program is doing, even in broad
detail.
2. I print a program listing, then mark it up in pencil, then various
colored markers, then highlighters, etc.
3. I toss the listing into the wastebasket in disgust.
4. I wad the listing into a ball and shoot it into the basket.
5. I light the contents of the wastebasket on fire. :-).
6. I rewrite the program from scratch.
7. I fire the guy who wrote it.
8. I renounce computers and join a monastic order.
Chuck Stevens
> I've encountered code where it seems any alphabetic character can
appear
> in the indicator column, and the stuff in the "main code area" seemed to
be
> exectuable COBOL statements (i.e. not merely comments), so I had assumed
> these characters served as some sort of conditional compilation flags.
In '85 standard COBOL, the only things that can appear in Column 7 are " ",
"-", "*", "/", "D" and "d". If other characters are allowed by an
implementor to appear in the Indicator Area, their purpose is entirely up to
the individual implementor and likely will have nothing whatever to do with
what another COBOL implementation might do upon encountering such a
character. So long as the compiler lets the user know in some way (which
might include by committing hara-kiri) that such things are not standard
COBOL, as far as the standard is concerned the compiler can turn them into
rutabagas or Novembers.
-Chuck Stevens
Oliver Wong
"Peter Lacey" <la...@mb.sympatico.ca> wrote in message
news:42D3DD3B...@mb.sympatico.ca...
> the question arises: exactly what is spaghetti code?
> Anyway: I'd like to hear some definitions and examples!
I come from a Java background, so this answer might not apply very well
to (traditional) COBOL, as it relies a bit on using an object oriented
paradigm, but...
I believe that in an ideal program, if you wanted to know what a piece
of code does, you wouldn't need to read anything other than the code in
question. That is to say, if you were reading through the code listing, and
saw a method call (I guess the closest COBOL equivalent is a PERFORM
statement), your first instinct wouldn't be to immediately scroll over to
read the contents of that method (or paragraph); rather, it would be clear
what that method does at a high level based on the name of that method.
That's one reason the presence of GOTOs imply unstructured (or
"spaghetti") code: Even if you give a really meaningful name to the
paragraph you're GOTO-ing, the reader still has a strong temptation to
scroll down and read the code there, to see if you eventually branch back to
where you came from (maybe this isn't possible in COBOL; I may be thinking
more of BASIC's GOSUB and RETURN statements).
This also explains why it's possible (though often unlikely) to write
structure (i.e. non-spaghetti code) even with the presence of GOTO
statements. If after reading through the code listing for a bit, you realize
that the original author was very dilligent and organized and so on, then
you might be confident that this author has arranged it so that whenever she
GOTOs somewhere, she always GOTOs back; and so you no longer have the
temptation, upon encountering a GOTO, to scroll down and read that bit of
code; you're confident that control will eventually come back, and the name
of the label of the GOTO target made it clear what that subroutine was
doing.
The reason spaghetti code, under the definition I'm offering, is
difficult for humans to understand is that it essentially requires us to
maintain a "call stack" like structure in our minds. While reading some
spaghetti code, when we see a branch, we're tempted to go read whatever code
migth be at the target of that branch. So we have to remember where we are
now, and go check it out. While reading THAT code, we then get tempted
again, to go look at another part of the code. We have to push a new address
onto our stack, and go read THAT new section of code, and so on.
With structure code, there is no temptation to go browsing around at
other locations, and so our stack height will always remain at 1 (or 0,
depending on whether you count the "current location" as being on the stack
or not).
BTW, this is also why comments at the beginning of methods (or
paragraphs or whatever) that describe what the method does can reduce the
symptoms of spaghetti code. Now, if you see a method call for which you're
tempted to branch off into, rather than actually reading the code of that
method, you can just read the high level description of the method (i.e. the
comment at the top), and so your stack never exceeds 2 (or 1, again
depending on how you count).
- Oliver
Howard Brazee
On 12-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> > Does your new compiler have some of the very newest features such as EXIT
> > PARAGRAPH?
>
> Not sure I understand the question, but I'm tempted to answer yes. Some
> of the code that my tools will have to handle may contain the EXIT PARAGRAPH
> statement, and some of the code that my tools output may contain the EXIT
> PARAGRAPH statement, and as far as I know, there is currently no plan on
> eliminating such statements.
My compiler is old enough that it does not support EXIT PERFORM (EXIT PARAGRAPH
and EXIT SECTION). If yours has these ways to get out of a loop, you will want
to use them.
Hmmm. Consider the following code and what you plan to do to it.
PERFORM UNTIL A=B
PERFORM GET-SALAD
ADD 1 to A
IF SALAD = GREEN
GO TO EXIT
END-IF
PERFORM GET-DRESSING
END-PERFORM.
Oliver Wong
> My compiler is old enough that it does not support EXIT PERFORM (EXIT
> PARAGRAPH
> and EXIT SECTION). If yours has these ways to get out of a loop, you
> will want
> to use them.
Oh, yes, in that sense, I can indeed output code using the EXIT PERFORM
statement. Thanks for the tip; it would have probably been very easy for me
to go overboard with adding flags everywhere and forgetting about the
existence of the EXIT PERFORM statement (indeed, one of the transformations
I was planning on using does require a way to break out of loops).
>
> Hmmm. Consider the following code and what you plan to do to it.
> PERFORM UNTIL A=B
> PERFORM GET-SALAD
> ADD 1 to A
> IF SALAD = GREEN
> GO TO EXIT
> END-IF
> PERFORM GET-DRESSING
> END-PERFORM.
Okay, again this is just me as a human trying to mechanically apply the
rules, but I think the transformation step will look like this (assuming no
malicious ALTERs or anything like that elsewhere in the code):
PERFORM UNTIL A=B
PERFORM GET-SALAD
ADD 1 to A
IF SALAD = GREEN
SET SHOULD-GOTO-EXIT TO TRUE
EXIT PERFORM
END-IF
PERFORM GET-DRESSING
END-PERFORM
IF SHOULD-GOTO-EXIT THEN
GO TO EXIT
END-IF
.
Where the transformation of the last GOTO depends on whether EXIT appears
above or below the GO TO.
- Oliver
Howard Brazee
On 12-Jul-2005, "Chuck Stevens" <charles...@unisys.com> wrote:
> The standard explicitly disallows
> 1) IF ... NEXT SENTENCE ... END-IF [whether the phrase appears before
> or after ELSE]
> 2) SEARCH ... NEXT SENTENCE END-SEARCH [whether SEARCH or SEARCH ALL]
But in this thread we have programs with ALTER in it, so I wouldn't assume that
the code is from CoBOL compilers which follow this standard either. (My
compiler allows the above disallowed code).
Oliver Wong
> In '85 standard COBOL, the only things that can appear in Column 7 are "
> ",
> "-", "*", "/", "D" and "d". If other characters are allowed by an
> implementor to appear in the Indicator Area, their purpose is entirely up
> to
> the individual implementor and likely will have nothing whatever to do
> with
> what another COBOL implementation might do upon encountering such a
> character.
That's very strange, because the code I posted above actually comes from
a COBOL85 test suite produced by NIST. To quote their page, "The COBOL85
test suite is a product of the National Computing Centre, UK. It is used to
determine, insofar as is practical, the degree to which a COBOL processor
conforms to the COBOL standard (ANSI X3.23-1985, ISO 1989-1985, ANSI
X3.23a-1989 and ANSI X3.23b-1993.)" So I had assumed that these alphabetic
characters in the indicator field must have been part of the ANSI 85 COBOL
standard.
Anyway, you can download the same test suite I did from
http://www.itl.nist.gov/div897/ctg/cobol_form.htm , and the file in question
was "IF111A", and the snippet I quoted begins on line 257.
- Oliver
William M. Klein
following is for a "85 standard conforming environment".
Original:
If A = "A"
Next Sentence
Else
Perform XYZ
.
Move L to M
.
Converted code:
Perform
If A = "A"
Continue
Else
Perform XYZ
End-IF
End-Perform
Move L to M
.
The following assumes an environment with an EXTENSION (available in Micro
Focus, IBM, and possibly others) that allows NEXT SENTENCE in nested IF with
END-IF at same level)
Original Source:
If A = "A"
If B = "B"
Next Sentence
Else
Perform XYZ
End-IF
Else
Perform A23
End-If
.
Move L to M
.
Modified code:
Perform
If A = "A"
If B = "B"
Continue
Else
Perform XYZ
End-IF
Else
Perform A23
End-If
End-Perform
Move L to M
.
--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <ow...@castortech.com> wrote in message
news:vcPAe.149478$on1.126481@clgrps13...
>
> "Richard" <rip...@Azonic.co.nz> wrote in message
> news:1121117821.0...@g14g2000cwa.googlegroups.com...
>> I can. It has been recently argu^H^H^H discussed here that a NEXT
>> SENTENCE embedded in a nested imperitive IF is allowed (some even think
>> it was deliberately allowed) and this will transfer control to after
>> the next full stop which may be at some arbitrary point.
>>
>> In my view any such usage should cause the converter to put the output
>> and input to /dev/nul, and preverably the coder as well, but it does
>> mean that such a program cannot have that full stop removed.
>
> Hmm, interesting. I did not find any mention of "NEXT SENTENCE" in any of
> the documentation I initially used as references for the COBOL language, but
> based on the discussions I've found on the web, it looks like NEXT SENTENCE is
> an unconditional jump to the statement immediately following the period of the
> sentence containing the NEXT SENTENCE statement, as you've said.
>
> I think this would be one one case where I would have to add a new
> paragraph name (to act as a label), then change the NEXT SENTENCE to a GO TO
> which jumps to that label. All the while, I have to be check for any PERFORM
> or PERFORM THRU statements that I might have to update to reflect the addition
> of this new paragraph.
>
> Thanks for the tip, I might have to factor in this new issue into the
> algorithm design.
>
> - Oliver.
>
Howard Brazee
One disadvantage to removing periods first is that parsing needs to look at
complete sentences. You read a sentence, get rid of spaces and lines and such,
handle continuations (I presume you need to check for this) etc. If you remove
the distinction between sentences and paragraphs, the smallest element to be
parsed will be the paragraph.
Chuck Stevens
get disappeared until '02.
-Chuck Stevens
"Howard Brazee" <how...@brazee.net> wrote in message
news:db0vf3$ktn$1...@peabody.colorado.edu...
William M. Klein
"preparation" program that does some source code modification based on "control
cards" passed to it. For example, it tests literal continuation based on input
on where the R-margin is.
I know of NO test case that has "non-Standard) alphabetic characters in margin 7
*after* the conversion program runs. If you have an example, please tell me the
test case name.
FYI,
If you are using the NIST test suite to "check out" your converter that is
both good and bad.
A) GOOD - it really DOES test every "standard" COBOL "valid" construction
B) GOOD - it is AWFUL spaghetti code - so it will test your tool
C) BAD - it is NOT typical application code and does NOT use many common
"constructs" and does use some that I never saw in any real-world application.
--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <ow...@castortech.com> wrote in message
news:SrTAe.106860$HI.61039@edtnps84...
Oliver Wong
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:StTAe.227354$ub.1...@fe07.news.easynews.com...
> You do NOT need to add a new paragraph name to handle "next sentence".
> The following is for a "85 standard conforming environment".
>
> Original:
> If A = "A"
> Next Sentence
> Else
> Perform XYZ
> .
> Move L to M
> .
>
> Converted code:
>
> Perform
> If A = "A"
> Continue
> Else
> Perform XYZ
> End-IF
> End-Perform
> Move L to M
> .
That's a very interesting usage of the inline PERFORM statement! I'll have
to look more into this one. Naively, it looks like the trick is just to wrap
code around an inline PERFORM once statement, and using CONTINUE to break
out of it. But what happens if there's already some nesting of PERFORM
statements? Assuming the extensions that allow NEXT SENTENCE in a nested IF
with END-IF:
PERFORM
IF A = "A" THEN
NEXT SENTENCE
ELSE
PERFORM XYZ
END-IF
MOVE L TO M
.
MOVE M TO K
.
Using the naive algorithm I've outlined above, this becomes:
PERFORM
PERFORM
IF A = "A" THEN
CONTINUE
ELSE
PERFORM XYZ
END-IF
MOVE L TO M
END-PERFORM
MOVE M TO K
END-PERFORM
.
which doesn't seem to do the same thing as the original (the original did
not move L to M, whereas the modified version does).
- Oliver
Oliver Wong
> What is your position going to be about GO TO DEPENDING?
This will need to be eliminated as well, probably via a 2 step process.
In the first step, it is converted to a series of GO TOs within some IF THEN
ELSE statements. Then the individual simple GO TOs will be eliminated
individually.
> One disadvantage to removing periods first is that parsing needs to look
> at
> complete sentences. You read a sentence, get rid of spaces and lines and
> such,
> handle continuations (I presume you need to check for this) etc. If you
> remove
> the distinction between sentences and paragraphs, the smallest element to
> be
> parsed will be the paragraph.
From my point of view, the transformations would be done on a statement
by statment basis rather than a paragraph by paragraph (or sentence by
sentence) basis. And aside from the presence of the NEXT SENTENCE statement,
if you always use the END-whatever (END-IF, END-CALL, END-COMPUTE, etc.)
constructs, there's no semantic different between statements and sentences.
So to simplify the transformation rules, I'd like to largely ignore the
existence of sentences; or equivalently, I'd like to assume exactly 1
sentence per paragraph.
- Oliver
William M. Klein
equivalent if the
PERFORM XYZ
were
Go To XYZ
The "End-Perform is matched ONLY with the nearest "in-line" perform, so I don't
see any reason that the MOVE would not occur (if it does in the original).
--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <ow...@castortech.com> wrote in message
news:sKTAe.106864$HI.103463@edtnps84...
Chuck Stevens
4.2, and a brief perusal of it leads me to believe the process of building
the test symbol files involves an extraction process (and I'm pretty sure
it's a "self-extraction" process from the monolithic symbol using the first
program included therein and the rest as input data). The "executive"
appears to be that part of the file that has "EXEC84.2" in the ID field.
Thus, there seems to be a "preprocessor" provided for this file to get its
contents into a state suitable for compilation.
I double-checked ANSI X3.23-1985, and I still don't see anything other than
spaces, forward-slashes, asterisks, hyphens, and upper and lower case D
characters being allowed in the indicator area.
-Chuck Stevens
"Oliver Wong" <ow...@castortech.com> wrote in message
news:SrTAe.106860$HI.61039@edtnps84...
Oliver Wong
> The (old no longer supported) NIST test suite requires one to run a
> "preparation" program that does some source code modification based on
> "control cards" passed to it. For example, it tests literal continuation
> based on input on where the R-margin is.
>
> I know of NO test case that has "non-Standard) alphabetic characters in
> margin 7 *after* the conversion program runs. If you have an example,
> please tell me the test case name.
I actually had to write my own "preparation program", which does the
appropriate substitution for certain control cards, but to be quite honest,
I really had no idea what I was doing and was mainly just fumbling around in
the dark. When the output "looked like" valid COBOL programs, I had assumed
that I succeeded.
Anyway, these characters appear in the original (non-prepared) versions
of the source file. Is there any documentation I could look at to see how to
interpret these characters for preparation? Or perhaps a link to a
conversion program?
- Oliver
Chuck Stevens
With respect to GO TO DEPENDING:
> This will need to be eliminated as well, probably via a 2 step
process.
> In the first step, it is converted to a series of GO TOs within some IF
THEN
> ELSE statements. Then the individual simple GO TOs will be eliminated
> individually.
What about EVALUATE? It preserves the structure of GO TO DEPENDING better
than IF ... THEN ... ELSE does, I think.
-Chuck Stevens
Oliver Wong
> You conversion does exactly what the original code does. It what also be
> equivalent if the
> PERFORM XYZ
> were
> Go To XYZ
>
> The "End-Perform is matched ONLY with the nearest "in-line" perform, so I
> don't see any reason that the MOVE would not occur (if it does in the
> original).
>
>> IF A = "A" THEN
>> NEXT SENTENCE
>> ELSE
>> PERFORM XYZ
>> END-IF
>> MOVE L TO M
>> .
>> MOVE M TO K
>> .
My interpretation of this code is that if A is equal to "A", then the
NEXT SENTENCE statement causes execution to jump to after the next period
that occurs, which means it skips over the "MOVE L TO M" statement, and goes
straight to the "MOVE M TO K" statement.
>> PERFORM
>> PERFORM
>> IF A = "A" THEN
>> CONTINUE
>> ELSE
>> PERFORM XYZ
>> END-IF
>> MOVE L TO M
>> END-PERFORM
>> MOVE M TO K
>> END-PERFORM
>> .
In this code, if A is equal to "A", then CONTINUE is executed (which
doesn't do anything), and then execution conditions after the END-IF, which
is the "MOVE L TO M" statement. Then after than "MOVE M TO K" gets executed.
Is this the correct interpretation? If so, then the former performs only
1 MOVE statement, whereas the latter performs 2.
- Oliver
William M. Klein
As far as I know it is ALWAYS possible to convert an '85 Standard conforming
COBOL program to a style of:
A) No Sections
B) only one period per procedure division paragraph
C) no PERFORM THRU statements and no ALTER statements and no GO TO statements
As far as I know it is also possible to do this for most (as far as I know ALL)
vendor extended COBOL's. However, I don't know this for certain. I *do* know
that IBM provided a product (that Arnold) mentioned called "COBOL/SF" or "COBOL
Structuring Facility". This product sold for $100,000 - which may give you an
idea of its complexity. This product is no longer sold or supported by IBM.
Its primary use (frequency) was during the time that many sites were converted
from OS/VS COBOL (a '68 or '74 Standard compiler) to VS COBOL II (an '85
Standard compiler). For more information on this product's development (which
was interesting in and of itself), see:
http://www.scisstudyguides.addr.com/papers/cwdiss725paper1.htm
or
http://hissa.ncsl.nist.gov/formal_methods/vol2.txt
This brings up a question that I have not seen asked or answered yet within this
thread:
What compiler is being used for the "unmodified" source code today (and do you
know what compiler options or directives are being used)? This can
SIGNIFICANTLY impact what your source code needs to handle. For example,
- IBM's OS/VS COBOL supported the
-- documented ON statement ("weird" control flow)
-- undocumented syntax such as:
Sort ...
Input Procedure ABC THRU XYZ
- Micro Focus
--- has a compiler directive to determine the semantics of NEXT SENTENCE
- Does your "real" code include preprocessors (mentioned elsewhere in the
thread)
-- For example IBM code with either DB2 or CICS can have LOTS of "inserted"
and flow-control code
What compiler will be the target of your "output" source code? If it is NOT the
same as your input, then other conversions may be needed.
***
Next, if the "goal" of this who project is REALLY to get code analysis, then
have you really looked at all the tools available for this? Although some work
BETTER with "structured" code, this is NOT a requirement for all. For example
(AND THIS IS ONLY AN EXAMPLE), the "Micro Focus REVOLVE" product provides
EXCELLENT code analysis for "IBM mainframe" as well as "Micro Focus" COBOL code.
See:
http://www.microfocus.com/products/revolve/
***
Finally, as stated initially in this note, I *do* think it is possible to do
what you are asking about. However, I am with those who questions the wisdom
(and cost-effectiveness) of starting on the project. If you can "better"
explain your actual business need and environment, we (comp.lang.cobol) MAY be
able to suggest a "better" solution.
--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <ow...@castortech.com> wrote in message
news:wqwAe.115746$9A2.13677@edtnps89...
> I'm trying to write a program that reformats the structure of a given COBOL
> program. One of the transformations I'd like to apply is to try to eliminate
> as many periods as possibles, using the END-whatever (END-IF, END-CALL,
> END-COMPUTE, etc.) constructs.
>
> My question is, is it always possible to do this? I don't want to "cheat"
> by adding new paragraph names at the beginning of every sentence (which may
> affect PERFORM statements anyway). My theory is that yes, it is always
> possible, but I haven't been programming in COBOL for that long, so I wasn't
> sure.
>
> - Oliver Wong
>
>
>
William M. Klein
(which may or may not be available with your compiler. If it is available,
changing the CONTINUE to an EXIT PERFORM would do the conversion correctly.
As just asked in another note:
- What is your "unmodified" compiler?
- What is your "modified" compiler?
(Release, operating system, etc - would be useful)
--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <ow...@castortech.com> wrote in message
news:U7UAe.106871$HI.61171@edtnps84...
Oliver Wong
I had considered that, and actually I mispoke: there would be no "ELSE"
clause. So code like:
GO TO P1, P2, P3, P4 DEPENDING ON FLAG
would translate to
IF FLAG = 1 THEN
GO TO P1
END-IF
IF FLAG = 2 THEN
GO TO P2
END-IF
IF FLAG = 3 THEN
GO TO P3
END-IF
IF FLAG = 4 THEN
GO TO P4
END-IF
and the rational for this is that this actually decouples, from an
abstract syntax tree perspective, the GO TO statements from each other, so
that they could be moved around independently for easier manipulation. On
the other hand, if the GO TOs were inside an "EVALUTE FLAG WHEN 1 etc." type
construct, the GO TO statements need to be handle together in one big chunk.
And anyway, it turns out that the algorithm for eliminating GO TOs
within EVALUATE statement eventually degenerates to the above code (of a
sequence of IF statements) anyway, except it doesn't look as pretty, being
machine generated, and also will cause the addition of more variables and
flags and such.
- Oliver
Oliver Wong
> Yes, I see that. I found my vintage-1993 copy of CCVS 85 USER GUIDE
> VERSION
> 4.2, and a brief perusal of it leads me to believe the process of building
> the test symbol files involves an extraction process (and I'm pretty sure
> it's a "self-extraction" process from the monolithic symbol using the
> first
> program included therein and the rest as input data). The "executive"
> appears to be that part of the file that has "EXEC84.2" in the ID field.
>
> Thus, there seems to be a "preprocessor" provided for this file to get its
> contents into a state suitable for compilation.
>
> I double-checked ANSI X3.23-1985, and I still don't see anything other
> than
> spaces, forward-slashes, asterisks, hyphens, and upper and lower case D
> characters being allowed in the indicator area.
Okay, thanks. I had originally written my own "extraction program" (base
merely on guesswork by inspecting the large monolithic file, and my limited
knowledge of what a valid COBOL program looks like), but it did seem like
the EXEC84 program had some sort of special status.
I'll have to investigate what this means with respect to whether or not
I'll have to redo the extraction process.
- Oliver
Oliver Wong
> FYI,
> If you are using the NIST test suite to "check out" your converter that
> is both good and bad.
>
> A) GOOD - it really DOES test every "standard" COBOL "valid" construction
> B) GOOD - it is AWFUL spaghetti code - so it will test your tool
> C) BAD - it is NOT typical application code and does NOT use many common
> "constructs" and does use some that I never saw in any real-world
> application.
I haven't read all the NIST test programs, but I did read some of them
(in particular, the ones that made my parser choke), and yeah, it was pretty
obvious that there was some code that could only be described as "no sane
person would ever write code like that, except as a mischievious attempt to
try and screw up the compiler".
As for point C, in addition to the NIST test suite, I've also been
provided with random COBOL programs download from tutorial sites that aim to
teach COBOL to a novice, as well as a handful of actual code that was once
(perhaps still is) used in a production environment.
Generally, for each phase, the test consisted of making sure it worked
for the novice programs, then making sure it works for the serious programs,
then making sure it works for the NIST programs. I can parse almost all of
the NIST files (I still have some issues with line continuation and the such
to work out), and right now my restructure tool is still only working on
novice-style files.
- Oliver
Oliver Wong
> I was thinking of the EXIT PERFORM staterment (which may or may not be
> available with your compiler. If it is available, changing the CONTINUE
> to an EXIT PERFORM would do the conversion correctly.
Aha, but now if the original code was:
IF B = "B" THEN
PERFORM
IF A = "A" THEN
NEXT SENTENCE
ELSE
PERFORM XYZ
END-IF
MOVE L TO M
END-PERFORM
MOVE K TO M
ELSE
CONTINUE
END-IF
.
Then the transformation, with an EXIT PERFORM would result in
PERFORM
IF B = "B" THEN
PERFORM
IF A = "A" THEN
EXIT PERFORM
ELSE
PERFORM XYZ
END-IF
MOVE L TO M
END-PERFORM
MOVE K TO M
ELSE
CONTINUE
END-IF
END-PERFORM
which again would be slightly different than the original.
I think the basic idea of using inline "PERFORM once" statements is a
good idea, but I'll have to think of something clever to work in general, as
the semantics of EXIT PERFORM and not exactly the same as that of NEXT
SENTENCE. Worst case, I could just revert to create new paragraphs in the
general case, but using your cleaner solution in simpler cases where I can
detect that it won't change the semantics.
> As just asked in another note:
> - What is your "unmodified" compiler?
> - What is your "modified" compiler?
>
> (Release, operating system, etc - would be useful)
The test COBOL source files come from a variety of sources (as mentioned
in another thread, they are the NIST test suite complemented with example
COBOL programs from tutorial sites as well as a few "real", "production"
code that was once used somewhere), and thus probably would normally be
compiled from various compilers. As a minimum, I'm supposed to accept COBOL
programs which comply with ANSI COBOL 85. Beyond that, the tool should try
to be lenient in accepting as many vendor extensions as feasible. Most of my
documentation is based on IBM's VS COBOL II and Liant's RM/COBOL language
reference, so those are the vendor extensions whose support is strongest.
Given appropriate documentation, I'm open to supporting other
extensions, as long as it doesn't break existing support elsewhere (so I
guess it's a first come first serve kind of deal).
- Oliver
Richard
>> as a way to terminate a paragraph.
> while the following is not:
> PARAGRAPH-1.
> MOVE A TO B.
> NEXT SENTENCE.
> PARAGRAPH-2.
I thought that it was clear he meant 'terminating' the logic flow not
the source text.
Chuck Stevens
> I think the basic idea of using inline "PERFORM once" statements is a
> good idea, ...
Note that "inline PERFORM" is by no means limited to "PERFORM once"
circumstances. In the syntax diagrams for PERFORM in ANSI X3.23-1985, note
that [procedure-name-1 [THROUGH procedure-name-2]] shows that the whole
thing is optional.
Note also that the terminating test for a more-than-once-through PERFORM
need have nothing whatever to do with anything you might be varying as part
of the PERFORM. Presuming the appropriate declarations have been made,
these are all at least theoretically correct:
PERFORM VARYING I FROM J BY K
UNTIL I IS GREATER THAN 500
CONTINUE
END-PERFORM.
PERFORM VARYING I FROM J BY K
UNTIL FUNCTION CURRENT-DATE (9:2) IS EQUAL TO ZERO
CONTINUE
END-PERFORM.
PERFORM VARYING I FROM J BY K
UNTIL ITS-A-RUTABAGA
CONTINUE
END-PERFORM.
PERFORM VARYING I FROM J BY K UNTIL
I IS GREATER THAN 500 OR
FUNCTION CURRENT-DATE (9:2) IS EQUAL TO ZERO OR
ITS-A-RUTABAGA
CONTINUE
END-PERFORM.
Note also that EXIT PERFORM (new in the '02 standard) is valid only from
within inline PERFORMs.
-Chuck Stevens
Richard
> The following assumes an environment with an EXTENSION (available in Micro
> Focus, IBM, and possibly others) that allows NEXT SENTENCE in nested IF with
> END-IF at same level)
Yes, but this is also possible by poor design or by accident:
Original Source:
If A = "A"
If B = "B"
Next Sentence
Else
Perform XYZ
End-IF
Else
Perform A23
End-If
Oliver Wong
> As far as I know it is ALWAYS possible to convert an '85 Standard
> conforming COBOL program to a style of:
>
> A) No Sections
> B) only one period per procedure division paragraph
> C) no PERFORM THRU statements and no ALTER statements and no GO TO
> statements
Yes, I supposed from a formal, purely logical perspective, this is very
likely. One would simply need to prove that the COBOL language (minus the
above mentioned statements) is Turing Complete, and assuming that the COBOL
language (including the above mentioned statement) is not more powerful than
a Turing Machine (unlikely), then the two languages would be equal in power.
I guess what I really mean is, will it be feasible to do this conversion
by machine? =)
I can sidestep issues of solving the halting problem and such by
assuming that my input COBOL source code should always be a valid program
(which should, given the appropriate inputs, eventually terminate).
> What compiler is being used for the "unmodified" source code today (and do
> you know what compiler options or directives are being used)? This can
> SIGNIFICANTLY impact what your source code needs to handle.
You posted this question again elsewhere (and I answered it there), but
just for continuity, I've copied and pasted my responce here.
The test COBOL source files come from a variety of sources (as mentioned
in another thread, they are the NIST test suite complemented with example
COBOL programs from tutorial sites as well as a few "real", "production"
code that was once used somewhere), and thus probably would normally be
compiled from various compilers. As a minimum, I'm supposed to accept COBOL
programs which comply with ANSI COBOL 85. Beyond that, the tool should try
to be lenient in accepting as many vendor extensions as feasible. Most of my
documentation is based on IBM's VS COBOL II and Liant's RM/COBOL language
reference, so those are the vendor extensions whose support is strongest.
Given appropriate documentation, I'm open to supporting other
extensions, as long as it doesn't break existing support elsewhere (so I
guess it's a first come first serve kind of deal).
> - Micro Focus
> --- has a compiler directive to determine the semantics of NEXT
> SENTENCE
I was not aware of this. I'll probably have to investigate this further.
> - Does your "real" code include preprocessors (mentioned elsewhere in the
> thread)
For debugging lines, the parser currently assumes debugging is set to
OFF (that is, all lines with D in the indicator field are treated as
comments), and the only preprocessor-like statement I'm aware of is the COPY
and REPLACE pair of statements, which I am expected to eventually handle, so
yes.
> -- For example IBM code with either DB2 or CICS can have LOTS of
> "inserted" and flow-control code
Embedded languages are currently not supported, though there are plans
to support them in the future.
> What compiler will be the target of your "output" source code? If it is
> NOT the same as your input, then other conversions may be needed.
See next responce.
> Next, if the "goal" of this who project is REALLY to get code analysis,
> then have you really looked at all the tools available for this? Although
> some work BETTER with "structured" code, this is NOT a requirement for
> all. For example (AND THIS IS ONLY AN EXAMPLE), the "Micro Focus REVOLVE"
> product provides EXCELLENT code analysis for "IBM mainframe" as well as
> "Micro Focus" COBOL code.
So yes, the goal of this project really is code analysis, so the output
target compiler is mostly irrelevant. As for looking into other tools, no I
haven't really done that. I am interested in hearing about other tools, if
only to get inspiration for my own, but I don't think I can actually just
"drop" this project and purchase a license for another tool. The analysis
module that I'll eventually have to work on actually has to expose a very
specific API so that it can be controlled by yet another tool, which pretty
much locks me into having to implement all this stuff myself.
I'll mention the idea of exploring existing tools to my boss (and will
probably bring up the example of Revolve in particular), but I'm doubt that
that will be the direction we will head in.
> See:
> http://www.microfocus.com/products/revolve/
As an aside, I watched the flash movie containing a demo of using
revolve, and not really knowing anything JCLs or CICS or anything like that,
the demo looked very impressive. =) While the example task they go through
(expanding a field by 2 bytes, did they meant 2 characters?) probably won't
apply to me (I'm mainly a Java programmer, so I have abitrarily long strings
and array-like structures available to me), I might still bookmark and send
a link to that demo to all my non-programmer friends who don't understand
why simple changes in the requirement can add so much extra development
time.
> Finally, as stated initially in this note, I *do* think it is possible to
> do what you are asking about. However, I am with those who questions the
> wisdom (and cost-effectiveness) of starting on the project. If you can
> "better" explain your actual business need and environment, we
> (comp.lang.cobol) MAY be able to suggest a "better" solution.
Well, I'm hesitant to go into too much detail, as I'm actually a recent
university graduate (bachelors in computer science) and this is my first
(computer-related) job, and I signed an NDA, and I don't have much business
experience, nor easy access to a lawyer, etc. But the basic gist is given
above. This GO TO elimination tool is just a small tool in a long chain of
them. I'm doing period elimination because it makes GO TO elimination easier
later on. I'm doing GO TO elimination because I it makes it easier for the
analysis I plan on doing later on. I have to write my own analysis tool
because I have to expose a specific API.
- Oliver
Chuck Stevens
> I can sidestep issues of solving the halting problem and such by
> assuming that my input COBOL source code should always be a valid program
> (which should, given the appropriate inputs, eventually terminate).
Hmmm. If I've read you aright:
There is no requirement that a syntactically-correct COBOL program *must*
eventually terminate, or even *should* eventually terminate. There is no
requirement that a program execute a STOP RUN statement, or EXIT PROGRAM to
another program that does a STOP RUN. I've run into many on-line programs
that are intended to run 24/7, for which *any* sort of termination is
considered catastrophic, and in which there is no provision whatever for
graceful *termination* (though such a program would likely include
provisions for a graceful *recovery*).
There is no correspondence between "valid program" and "eventually
terminate"; there are valid application-design reasons to have "outer loops"
that have no terminal condition -- "PERFORM MAIN-LINE UNTIL
HADES-FREEZES-OVER", the ALGOL version "WHILE TRUE DO ...", or even the
Dijkstra-inspired Burroughs B1000 SDL/UPL "DO FOREVER".
STOP RUN (and EXIT PROGRAM) are statements like any other; the programmer
can choose to use them, or not, as the application design requires.
-Chuck Stevens
Richard
EXIT PARAGRAPH and SECTION are works of the devil ;-) In many ways
they have some of the problems of GO TO and NEXT SENTENCE. As with
those they are 100% clear and definite abouut what happens when you
look at the words themselves, but cloak what happens when you are
examining the target point.
Or, specifically, if there are any of these anywhere in the program
then it is always necessary to examine every possible context on any
change. If these are proven to not exist then the amount of context is
much reduced and productivity is much greater.
One of the ways that I simplify code is by breaking it down into
smaller paragraphs that are grouped. For example if I find that nested
IFs are getting too deeply indented it is easy to rip out imperitive
statements into a paragraph and perform it. EXIT ~ get in the way of
doing this, just as GO TO does.
Peter Lacey
>
> "Peter Lacey" <la...@mb.sympatico.ca> wrote in message
> news:42D3DD3B...@mb.sympatico.ca...
> > the question arises: exactly what is spaghetti code?
> [...]
> > Anyway: I'd like to hear some definitions and examples!
>
> I come from a Java background, so this answer might not apply very well
> to (traditional) COBOL, as it relies a bit on using an object oriented
> paradigm, but...
>
> I believe that in an ideal program, if you wanted to know what a piece
> of code does, you wouldn't need to read anything other than the code in
> question. That is to say, if you were reading through the code listing, and
> saw a method call (I guess the closest COBOL equivalent is a PERFORM
> statement), your first instinct wouldn't be to immediately scroll over to
> read the contents of that method (or paragraph); rather, it would be clear
> what that method does at a high level based on the name of that method.
>
> That's one reason the presence of GOTOs imply unstructured (or
> "spaghetti") code: Even if you give a really meaningful name to the
> paragraph you're GOTO-ing, the reader still has a strong temptation to
> scroll down and read the code there, to see if you eventually branch back to
> where you came from (maybe this isn't possible in COBOL; I may be thinking
> more of BASIC's GOSUB and RETURN statements).
>
As you suspect: that's a GOSUB. A GOTO is an unconditional transfer of
control with no instrinsic implication that you're going to return, as
opposed to a PERFORM which does imply that. The program flow may well
require that you will go through this part of the code again - such as
in a loop of any kind - but that's an artifact of the flow, not the
statement. I'd agree that if somebody did write in such a fashion as to
require that the program to return to the next statement in line after
the GOTO would be spaghetti-coding. But I haven't seen that done ever
except for my example mentioned before, and about two rookie FORTRAN
programs, a LONG time ago. Therefore there is no temptation to check
the label to see if it comes back; likely though you'd have to follow it
up anyway to find out what happens there.
Regrettably, all your analysis really applies to PERFORM's (or CALL's).
> The reason spaghetti code, under the definition I'm offering, is
>difficult for humans to understand is that it essentially requires us to
>maintain a "call stack" like structure in our minds. While reading some
>spaghetti code, when we see a branch, we're tempted to go read whatever code
>migth be at the target of that branch. So we have to remember where we are
>now, and go check it out. While reading THAT code, we then get tempted
>again, to go look at another part of the code. We have to push a new address
>onto our stack, and go read THAT new section of code, and so on.
It seems to me that since "structured" programming requires nested
PERFORM's (or at least cascaded PERFORM's) then by your definition it's
spaghetti code. (Correct me if I'm wrong, people, but I don't think
it's possible to write any non-trivial program with PERFORM's only one
level deep). If you see a PERFORM, you must eventually find out what's
going on there to understand the program logic.
>
> BTW, this is also why comments at the beginning of methods (or
> paragraphs or whatever) that describe what the method does can reduce the
> symptoms of spaghetti code. Now, if you see a method call for which you're
> tempted to branch off into, rather than actually reading the code of that
> method, you can just read the high level description of the method (i.e. the
> comment at the top), and so your stack never exceeds 2 (or 1, again
> depending on how you count).
>
> - Oliver
Funny, that; about the time that Dijkstra (sp? I never am sure) invented
"structured" programming, another study came out that found that
comments were just as effective in creating better programs; but, the
author said, comments aren't as intellectually exciting as GOTO-less
methods, so probably won't get the same sort of attention. How right he
was! But so far as top-level comments go: if they describe exactly what
happens, with input and output variables defined and listed, then you're
right. But if there is any doubt as to what's happening within the
method - such as a payroll calculation going slightly wrong - somebody
is going to have to examine the thing. I've always thought that that is
one of the two problems with objects: one is determining exactly what
they do, the other is finding out which ones exist to solve the problem
you're working on.
PL
Arnold Trembley
Arnold Trembley
Arnold Trembley
Howard Brazee
On 13-Jul-2005, "William M. Klein" <wmk...@nospam.netcom.com> wrote:
> My definition of "spaghetti code" is any (COBOL) code in which transfer of
> control "crosses" at least once (and in such programs it is USUALLY multiple
> times) in a one way direction.
I've seen a lot of spaghetti code with transfers of control in both directions.
Aren't all directions "one way"?
William M. Klein
following "spaghetti code"
Para1.
If A = "A"
Go to Para2
Else
Display "Not equal"
End-If
Display "after IF"
.
Para2.
Move x to A
Go To Para1
.
"functionally" this is the same as a PERFORM PARA2 (because you "go to" a single
paragraph that, itself, - unconditionally - "comes back" from where you went
to).
This also shows why I would allow "go to" a previous paragraph (procedure-name).
Needless to say, my PERSONAL PREFERRED way to code the above logic would be:
Para1.
If A = "A"
Perform Para2
Else
Display "Not equal"
End-If
Display "after IF"
.
Para2.
Move x to A
.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:db3s2g$d1h$1...@peabody.colorado.edu...
Howard Brazee
On 13-Jul-2005, "Oliver Wong" <ow...@castortech.com> wrote:
> The basic heuristic I was getting at for determining whether a program
> was written in the spaghetti style of coding was to ask: Do I have to scroll
> up and down the program listing (i.e. "follow the spaghetti trail") to
> understand it? Or can I just read the one paragraph I'm interested in, and
> whenever I see a "PERFORM", I can infer what the performed paragraph does
> based on the name of the paragraph.
Unfortunately, there is no way to guarantee that what you think is a
well-structured program really is, unless you (or your program) actually looks.
> Checkout.
> PERFORM CheckItemsAreStillInStock
> IF error-flag IS TRUE THEN
> GOTO ErrorHandling
> END-IF
> PERFORM ApplyAnyApplicableRebates
> IF error-flag IS TRUE THEN
> GOTO ErrorHandling
> END-IF
> PERFORM CalculateShippingAndTaxSurchage
> IF error-flag IS TRUE THEN
> GOTO ErrorHandling
> END-IF
> GOTO ConfirmSale
> .
>
> Then I'd say that code isn't really spaghetti, even though it may
> contain GOTOs. I can read that code, and without actually reading any of the
> paragraphs it refers to ("CheckItemsAreStillInStock", "ErrorHandling",
> etc.), I can pretty much tell what the program is doing. I didn't have to
> scroll to another part of the program to figure out what was going on.
Possibly. It depends on what ErrorHandling does. If it is an abort routine,
the GOTO is fine. If it prints an error report then does a GOTO ConfirmSale,
then it is not. I also have to look at ConfirmSale.
William M. Klein
Just thought I would mention one other area that you will need to consider in
the analysis phase - if not the "structuring" phase.
The question of what happens with non-Standard PERFORM ranges. For a
(semi-)discussion of how a number of vendors handle these, see the PERFORM-TYPE
compiler directive available from Micro Focus:
FYI,
If you haven't already, you might want to look at the entire section
"Run-time Behavior"
in the manual
"Compiler Directives"
available online at:
http://supportline.microfocus.com//documentation/books/sx40sp1/stpubb.htm
NOTE:
Micro Focus is KNOWN for its "vast" quantity of directives AS WELL AS its
ability to (more or less) emulate the behavior of many, MANY, other vendor's
compilers. Therefore, either when it comes to "extensions" or "implementor
defined" behavior, Micro Focus may (probably?) has a directive (or two) to
provide compatibility with the different semantics for the SAME syntax.
Oliver Wong
You are, of course, completely right. I think I made the above comment
mainly out of habit from an inside joke amongst my computer science student
peers. The Halting Problem, as you may already know, was proven by Alan
Turing to be undecideable by Turing Machines. Furthermore, all known
computers today have equal or less power than a Turing Machine. Therefore,
if you could ever show that solving the problem you're working on was
equivalent to solving the Halting Problem, then you know that the problem is
impossible to solve in COBOL (or any other programming language running on
any known computer). So of course we would frequently compare solving the
assignments our teachers gave us to solving the Halting Problem (i.e. they
were impossibly difficult).
The Halting Problem is: given a program written in COBOL (or any other
programming language, but let's assume COBOL for now, since we're in
comp.lang.cobol), and given the set of inputs that will be provided to that
program (if any), determine whether that program will eventually halt or
not.
Whenever you do significant analysis on a program source code (as I'm
trying to do), there's always the lingering fear that you might run into the
Halting Problem. For example, if you're given the task of determining
whether a program always returns the number "2" as a result, that's
equivalent to solving the Halting Problem (to be sure it'll eventually
return 2, you'd have to first know that it eventually halts, or terminates).
I guess what I was initially trying to say is: "I don't think the
Halting Problem will be an issue for my analysis tool, so don't worry about
that."
- Oliver
Oliver Wong
> As you suspect: that's a GOSUB. A GOTO is an unconditional transfer of
> control with no instrinsic implication that you're going to return, as
> opposed to a PERFORM which does imply that. The program flow may well
> require that you will go through this part of the code again - such as
> in a loop of any kind - but that's an artifact of the flow, not the
> statement. I'd agree that if somebody did write in such a fashion as to
> require that the program to return to the next statement in line after
> the GOTO would be spaghetti-coding. But I haven't seen that done ever
> except for my example mentioned before, and about two rookie FORTRAN
> programs, a LONG time ago. Therefore there is no temptation to check
> the label to see if it comes back; likely though you'd have to follow it
> up anyway to find out what happens there.
>
> Regrettably, all your analysis really applies to PERFORM's (or CALL's).
I was actually trying to argue for the point that PERFORMs or CALLs are
*better* than GOTOs, because with PERFORMs, you "know" that control is going
to come back, whereas with GOTOs, you don't know (or I guess you know that
it won't) come back.
The basic heuristic I was getting at for determining whether a program
was written in the spaghetti style of coding was to ask: Do I have to scroll
up and down the program listing (i.e. "follow the spaghetti trail") to
understand it? Or can I just read the one paragraph I'm interested in, and
whenever I see a "PERFORM", I can infer what the performed paragraph does
based on the name of the paragraph.
For example, if the code for a online webstore checkout was something
like (I'm not familiar with the limits of lengths of names of paragraph and
such, so maybe this isn't valid COBOL code, but it illustrates the idea):
Checkout.
PERFORM CheckItemsAreStillInStock
IF error-flag IS TRUE THEN
GOTO ErrorHandling
END-IF
PERFORM ApplyAnyApplicableRebates
IF error-flag IS TRUE THEN
GOTO ErrorHandling
END-IF
PERFORM CalculateShippingAndTaxSurchage
IF error-flag IS TRUE THEN
GOTO ErrorHandling
END-IF
GOTO ConfirmSale
.
Then I'd say that code isn't really spaghetti, even though it may
contain GOTOs. I can read that code, and without actually reading any of the
paragraphs it refers to ("CheckItemsAreStillInStock", "ErrorHandling",
etc.), I can pretty much tell what the program is doing. I didn't have to
scroll to another part of the program to figure out what was going on.
>
>> The reason spaghetti code, under the definition I'm offering, is
>>difficult for humans to understand is that it essentially requires us to
>>maintain a "call stack" like structure in our minds. While reading some
>>spaghetti code, when we see a branch, we're tempted to go read whatever
>>code
>>migth be at the target of that branch. So we have to remember where we are
>>now, and go check it out. While reading THAT code, we then get tempted
>>again, to go look at another part of the code. We have to push a new
>>address
>>onto our stack, and go read THAT new section of code, and so on.
>
> It seems to me that since "structured" programming requires nested
> PERFORM's (or at least cascaded PERFORM's) then by your definition it's
> spaghetti code. (Correct me if I'm wrong, people, but I don't think
> it's possible to write any non-trivial program with PERFORM's only one
> level deep). If you see a PERFORM, you must eventually find out what's
> going on there to understand the program logic.
I was making the assumption that there may exists times when you see a
PERFORM, and yet you *DON'T* have to actually read the paragraph the PERFORM
refers to to find out what's going on there, for example, if the name of the
paragraph is meaningful.
In the case of GOTO, you pretty much HAVE to go to the paragraph being
referred to, because the rest of the program logic occurs there, and no
longer at where you're currently reading. With a PERFORM, the control
temporarily goes there, but it should eventually come back, and so if you
can guess at what the PERFORMed paragraph does, you don't need to leave your
spot to understand what the overall program is doing. You just keep reading
from where you're at (i.e. the statement following the PERFORM statement).
> But so far as top-level comments go: if they describe exactly what
> happens, with input and output variables defined and listed, then you're
> right. But if there is any doubt as to what's happening within the
> method - such as a payroll calculation going slightly wrong - somebody
> is going to have to examine the thing.
The problem I often see with top-level comments is that it's very easy
to accidentally describe how you implemented the function there, rather than
what the method actually does. As a perhaps non-realistic trivial example,
if you were writing a library of math functions, then a not-so-good top
level comment might be (using "C++/Java style comments", to avoid issues
with word wrapping):
/* This subroutine uses Newton's method to calculate the square root of a
number by recursively calling itself. */
Whereas a better comment might be:
/* Given a non-negative floating point number N, returns a floating point
number that is within epsilon of the true positive square root (i.e. the
result of this function is always positive unless an error occured, see
below).
If the integer is negative, -1 is returned.
@param N the number whose square root is desired.
@param e epsilon, the accpetable error of the answer.
@returns an approximation of the square root of N with an error no greater
than epsilon, or -1 if an error occured.
*/
The second comment says nothing about how the method is implemented,
only what it does. Typically, what a method does never changes for a given
program, so it never needs to be updated. The first comment instead says HOW
it does something, and that may very well change (perhaps the recursion will
be unrolled into an iteration for efficientcy), and then the comment will
not match with the code.
> I've always thought that that is
> one of the two problems with objects: one is determining exactly what
> they do, the other is finding out which ones exist to solve the problem
> you're working on.
The first (determining what they do) is a documentation issue more than
an "OO versus non-OO" issue, and I usually never had any problems with this
regard for the Java or PHP standard API library (though I often have these
type of problems when using 3rd party open source libraries).
The second is a good point, but I think it's better to have the
solutions out there, requiring you to put effort into finding those
solutions, than to not have the solutions out there, and having to implement
them yourself.
- Oliver
HeyBub
> Formally, to prove that it's always possible to write a COBOL
> program with one period per paragraph, it isn't enough to just give
> examples of COBOL programs which are written with one period per
> paragraph. Rather, you need to present some sort of logical proof;
> However, you can disprove the statement by giving an example of a
> COBOL program which cannot be rewritten with just one period per
> paragraph. (Remember all those science test questions which start
> with "Prove or give a counterexample"?)
And I believe Mark Twain said he never took health advice from books. "I
might die of a misprint," he concluded. Still, the chances of both
single-period paragraphs and proper living being correct are great.
>
> Still, the ETK is a neat library. Thanks.
>
> - Oliver
docd...@panix.com
Arnold Trembley <arnold....@worldnet.att.net> wrote:
[snip]
>I don't miss OS/VS COBOL, but the sysprogs in my shop can't seem to
>get rid of it. It seems that when IBM sends you a new OS release,
>z/OS 1.5 for example, if your shop had ever ordered OS/VS COBOL in the
>past it is still included in your new installation media.
>
>That should give DocDwarf a chuckle.
zzzzzzzzzz... zzzzaaaAAWWWWKKKkkkkhhhhh... zzzzznnnnoooooopppphhhhh... eh?
huh? whuh? Oh, sorry, I was just... resting my eyes, did I miss
something?
Now that you mention it... let me take a look-see at my current client's
Prod loadlib... hmmmm... got a bunch of 'em, looks like a couple of
systems have been merged over the decades... let's see... this'un's got a
mere 1300 modules, that'll be a start...
... nope, no ILB0 routines in there.
DD
Howard Brazee
On 13-Jul-2005, Peter Lacey <la...@mb.sympatico.ca> wrote:
> > I was actually trying to argue for the point that PERFORMs or CALLs are
> > *better* than GOTOs, because with PERFORMs, you "know" that control is going
> > to come back, whereas with GOTOs, you don't know (or I guess you know that
> > it won't) come back.
>
> But why SHOULD it come back?? I'm guessing that you're thoroughly
> familiar with the "structured" style and haven't written much in the
> GOTO-style. While of course "structured" thinking works well, it does
> impose a certain mind-set: in this case it is that flow must be from the
> start of the paragraph to the end (with flow transfers happening but
> disguised as PERFORMS etc. - which are of course equivalent to "go
> there, do something, come back here"). It's a bit difficult to explain
> clearly - as you can see - but that isn't the only way to do it. Bear
> in mind that using GOTO's in no way precludes PERFORM's - they are used
> as is convenient, of course - contrariwise, GOTO's are never (or at
> least should not ever, on pain of death) used as a substitute for
> PERFORM's. That way lies madness.
Mainly because if you can count on it coming back, you can follow the flow of of
the code more easily.