Cobol - Re: Infinite Loops and Explicit Exits

Author

Re: Infinite Loops and Explicit Exits

Richard

2004-11-16, 6:44 pm

"Rick Smith" <ricksmith@mfi.net> wrote

> Standard COBOL provides no means, similar to
> EXIT PARAGRAPH and EXIT SECTION, to
> "short cycle" PERFORM ... THRU without using
> a GO TO statement. EXIT PERFORM CYCLE
> eliminates those GO TO statements.

There are other ways to eliminate the GO TOs.

> some-process.
> ....
> PERFORM some-other-process
> IF exception-variable NOT = ZERO
> EXIT PERFORM
> END-IF
> ...

So what is wrong with:

> PERFORM some-other-process
> IF exception-variable NOT = ZERO
CONTINUE
ELSE
...
> END-IF

Rick Smith

2004-11-16, 6:44 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410302009.c1781e9@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
>
>
> There are other ways to eliminate the GO TOs.

Not with multiple paragraphs or sections in PERFORM ...
THRU.

>
> So what is wrong with:
>
> CONTINUE
> ELSE
> ...

It won't work in all but the last paragraph of a
PERFORM ... THRU or PERFORM section and will
not cause the PERFORM to terminate without a
test for the same condition.
[color=darkred]
>
> Possibly, but as I have never felt the need for any of them, or GO TO,
> then equally needful is about right.

Robert Wagner

2004-11-16, 6:44 pm

On Tue, 2 Nov 2004 12:13:22 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:r88do0hgoqarvib383eb5mr9i6dciheatv@
4ax.com...
>In a
>GO
>
>Only partly true. GO TO <perform-range-exit> is equivalent to EXIT PERFORM
>CYCLE only if <perform-range-exit> is a paragraph that contains only the
>EXIT statement (not a requirement), and EXIT PERFORM CYCLE is equivalent to
>EXIT PARAGRAPH only if both occur in the last or only paragraph in the
>PERFORM range.

In practice, both are true. Programmers don't perform a thru c, they
perform a thru a-exit.

The significant change is that EXIT PERFORM not only exits but also
stops iteration. There is no equivalent Cobol function to do that
under 2002.

>
>Yes, but again, that only works if <perform-range-exit> is a paragraph
>containing only EXIT. I was thinking of the PERFORM FOREVER case, in which
>event I think they're pretty much equivalent.

PERFORM FOREVER doesn't exist yet, and do-it-yourself methods are
uncommon. Again, the common case is PERFORM A THRU A-EXIT UNTIL
<an-indicator-is-set>. EXIT PERFORM CYCLE would replace A-EXIT and
THRU A-EXIT. EXIT PERFORM would additionally replace the indicator.

There is no need for THRU A-EXIT *now*, and the terminating condition
belongs on UNTIL rather than embedded in the procedure. But there are
some who need an 'excuse' to change their obsolete style.

>The defense of an existing '70's shop standard so stating is that it exists
>and that most likely the owners of a company have spent a fair amount of
>money in programs that conform to it. Because there may be no particular
>technical necessity for a construct in a given context does not mean it is
>valueless to those whose programs contain it. "Because I'm used to it being
>there" is not such a terrible thing!

It is terrible when it prompts outsiders to call Cobol a dinosaur and
abandon it for 'more modern' languages.

>Yes, I am well aware of the Holy Wars as to whether a GO TO to the single
>EXIT point of the paragraph you're in was a violation of Proper Structured
>Programming rules.

A properly structured program has no need for premature exits (except
to abort). The audience for EXIT PERFORM is programmers who don't know
how to do structured programming. For them, EXIT PERFORM is an
improvement over PERFORM A THRU A-EXIT.

Richard

2004-11-16, 6:44 pm

"Rick Smith" <ricksmith@mfi.net> wrote

[color=darkred]
> To say "perform single paragraphs only"

And here is where I used this particular set of words:

"""The particular set of rules that I use are (there are exceptions of
course):

Only PERFORM single paragraphs (NOT sections, no THRU)

Never Drop Through a label

GO TOs are only used to the top of the current paragraph
(continue) or out to a common abandon-program
"""

You misrepresent my words as somehow insisting that others do this
when it quite clearly states that it is what _I_ do.

> and "GO TO is not needed" is to be firm.

I did find where I had said that, but you have taken it completely out
of the specific code sample context that it was used in, deliberately
probably:

"""GO TO is not needed to 'jump over the mess',"""

> To say the same unwaveringly is to be
> resolute. To say the same repetitively is to be emphatic.

And to take these and misrepresent them is disengenuous.

You appear to completely ignore that most of my discussion was
conditional:

"If it is your intent to eliminate the GO TOs then .."

You may also have seen while you were scanning my messages:

"""In my view there is actually nothing wrong with GO TOs. They are
very clear in their intent and easy to follow."""

"""There is actually nothing wrong with a GO TO statement. It is
perfectly
what its action is and, where the GO TO occurs, there is no confusion
over the logic flow."""

"""In fact there is nothing wrong with a GO TO at all. It is a very
clear
statement that is unambiguous and always does what is required."""

> Mr Plinston, you may not see anyone "insisting;" but I have
> seen you "insisting" for years and, a quick search of Google
> groups, confirms at least ten years of being emphatic, firm,
> and resolute on the matters of single paragraph perform and
> GO TO.

Now find somewhere where this wasn't clearly stated as: what _I_ do,
or my opinion, or one option among others, or conditional

In other words find where I actually 'insist' on some one doing it
just one way.

> Mr Plinston, I said "implying ... archaic, the first step toward
> elimination."

Given that it was Chuck that brought up 'archaic', perhaps you could
indicate where exactly you found me saying this.

> To say "perform single paragraphs only" is to imply that THRU
> is not needed.

It certainly isn't needed in my code. Now, did that tell that you
shouldn't use it ?

> To say "GO TO is not needed" is to say so directly.

and yet more recently you stated:

RS>>> EXIT PERFORM CYCLE eliminates those GO TO statements.

> To say these things with the knowledge that THRU
> and GO TO have been part of the language since the
> beginning is to imply "no longer needed" and, therefore, old or
> outmoded; thus anitquated and archaic.

Are you using "no longer needed" as a direct quote of something that I
actually said, or did you just make this up ?

For example I did use that phrase in:

"""and I found I no longer needed -Exit paragraphs"""

Which seems to be somewhat different than your invention.

> The sense of "imply" that I use is: to involve or require as a
> necessary condition.

So find an actual case where I _require_ something.

Richard

2004-11-16, 6:44 pm

Robert Wagner <spamblocker-robert@wagner.net> wrote

> Consider the Hawks movies Rio Bravo and El Dorado. They had the same
> characters and story line. The second was truly a rewrite of the
> first.

A small number do get remade, ususlly the result is much worse than
the original.

>
> The black-and-white fallacy, again. Why not both?

Because 'both' cost twice as much as doing one. In any case, at most
sites there is likely to be a backlog of systems that are required to
be developed. In most cases these new system are cost justified on
the basis that the result will be a cost saving overall.

Existing systems which already do their task reliably will not do it
any better if rewritten, in fact it may well introduce bugs. There is
no cost savings to be had, so the rewrite is entirely unjustified
cost.

Given a particular staffing level they can be allocated to work that
will save money or work that will save nothing and may cause
additional cost and problems.

> I advocate rewrite as a by-product of required maintenance.

And what if there is no 'required maintenance'. The system has been
stable, there are no additional functions required, it does the job.

> At the
> supermarket company I cited, nearly all programs were modified within
> a year.

Was that the system that you said was rewritten at 3 programs per
man/day or somesuch and didn't need anything other than regression
testing ? Now they all get modified.

> If there had been programs, or better whole systems, that were
> untouched, I would have left them alone. Other places I managed had
> untouched systems.

Well, there yer go then. Many sites have systems and programs that
aren't touched for years.

> I'd rather CALL action unconditionally and let it make the decision.
> That way, the 'business rules' are complete within a single program.

That would depend on what 'condition' is and whether it is part of the
'business rule' of the current code or of the code being called.

Howard Brazee

2004-11-16, 6:44 pm

On 5-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> How do I abend under Unix?
> RW: Abends are mainframe culture. Under Unix, you log the error and
> keep running.

That implies that you don't have dependencies.

Chuck Stevens

2004-11-16, 6:44 pm

Xref: newsfeed-west.nntpserver.com comp.lang.cobol:100267

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0411032201.329878f8@posting.google.com...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote
>
my[color=darkred]
>
> But some seemed to be

by what would be equivalent.
>
of[color=darkred]
>
> I do hope you mean the last _active_ PERFORM.
>
> PERFORM A
> here
> ...
> A.
> PERFORM B
> EXIT PERFORM
> ...
> .
>
> The 'PERFORM B' is the 'last PERFORM executed', 'here' is where you want
to get to.

Yes; at this point I'm mostly worried about getting "agreement in principle"
on what it's supposed to do; I have no doubt the wording will be thoroughly
hashed over before it gets into the standard! ;-)

The *current* such rule for EXIT PERFORM reads "The execution of an EXIT
PERFORM statement without the CYCLE phrase causes control to be passed to an
implicit CONTINUE statement following the END-PERFORM phrase that matches
the most closely preceding, and as yet unterminated, inline PERFORM
statement". (ISO/IEC 1989:2002 Page 449, 14.8.13.3, EXIT statement, general
rule 9).

Perhaps "... control is passed to an implicit CONTINUE statement following
the most recently executed, and as yet unterminated, out-of-line PERFORM
statement."?

Simply changing "last PERFORM" to "last such PERFORM" might also work; the
EXIT PERFORM does not appear, to me, to be in the perform range of PERFORM
B.

But again, *at this stage* what I'm more concerned about is whether or not
the basic idea would be accepted by J4 (and WG4), not whether we've got all
the serifs right in the rules. If the whole idea gets shot down, all the
energy and time spent worrying about whether I covered all the cases or not
in the early drafts of the rules is wasted, and I have some rather weightier
issues to consider!

-Chuck Stevens

Richard

2004-11-16, 6:44 pm

Robert Wagner <spamblocker-robert@wagner.net> wrote

> A before-and-after test with full production volume will insure new
> code is doing the same as old.

It will only 'insure' that for the particular items that are in that
test. There will be many things that a 'full production volume' may
not test. Many times I have looked at a 'full production volume' and
seen that the actual data is only a subset of all possible data types
and would fail to excersize all the program.

In any case each individual program will still need testing before
reaching the point that it can be system tested.

Rick Smith

2004-11-16, 6:44 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:cme29k$prg$1@peabody.colorado.edu...
>
> On 4-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:
>
that[color=darkred]
>
> One can recommend without insisting. One can discuss techniques without
> insisting.

When a comment is specific to a problem, I would suggest
it is a recommendation without insisting. When the comment
does not address the problem, I see it as insisting on something.
For example, a poster provides code to print a report; the code
is written using sections; and the problem is with control breaks.
A recommendation solving the problem does not insist; a
recommendation to use Report Writer does insist; and a
recommendation to use paragraphs, not sections, also insists.

> I don't believe the world consists only of dictators and sheep, nor
> should it. I infer that you believe differently.

I think dictators and sheep might have that opinion. I don't.

>
> No, I cannot.

Well, I can't argue with that. But if your use of "lead" is not
in the sense of current practice, then different implications
arise.

>
>
> However to say "I program this way", or even "I find this way of
programming to
> be desirable", does not imply "I want other ways of programming to be
> proscribed" - even if that is what you infer.

Mr Brazee, those statements are ambiguous. I can't tell if, by
"this way," you mean standing on your head, standing on your
feet, sitting in a chair, sitting on the floor, or something else.
To imply, in the sense used, requires a clear statement from
which to draw the necessary consequences or conditions.
The implications arise with the specifics of "this way" and
"this way of programming to be desirable."

Having said that, my dictionary provides a definition of
"desirable" as "advisable; recommendable." It is not a big
leap to conclude that the inadvisable and practice not
recommended is to be proscribed; but it does depend on the
specifics.

Rick Smith

2004-11-16, 6:44 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:cmdjf2$gmi$1@peabody.colorado.edu...
>
> On 3-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:
>
>
> They make huge differences.

Not with the repetition shown.

Consider the qualification "in this case." This seems to limit
the consequences of the statement, but when repeated with
different cases (posters), it approaches "in no case." There
is a point at which the qualification must be discarded.

>
> I agree that it doesn't take much of an observer to observe things that
aren't
> said. What Mr. Plinston does and what I like are in no way insisting
that
> others follow our lead.

Mr Brazee, by saying that you have a "lead" that may be
followed, and to express repeatedly the concept that makes
it "lead[ing]," is to insist that others "follow [y]our lead;" else
why say it?

Can you not see that, by using "lead," you are implying that
what others do, different from that "lead," is outmoded, thus
archaic?

>
>
> And I have repeatedly disagreed with your point. Not only is it based
upon a
> false assumption, the conclusion does not follow. The whole argument is
> entirely in your head. Your inferences are completely unrelated to what
I
> actually said.
>
> There's a big difference between what you infer and what I imply.

There are different senses for the definition of "imply." Either of
these fits the use I relied on.
( www.m-w.com )
2 : to involve or indicate by inference, association, or necessary
consequence rather than by direct statement <rights imply
obligations>
( "The Random House College Dictionary" )
2. to involve or require as a necessary condition.

These are not related to intent of the speaker. For one to say
"At 6 PM, I was stuck in a snow drift outside Chicago." implies
"I was not on a beach at Maui when it was 6 PM in Chicago."
[It seems likely that the importance of this particular implication
would require more information.]

Howard Brazee

2004-11-16, 6:44 pm

On 5-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:

>
> When a comment is specific to a problem, I would suggest
> it is a recommendation without insisting. When the comment
> does not address the problem, I see it as insisting on something.

I'm just the opposite. When someone has a specific fix, I see that fix as close
to being insistent. When he is talking general styles, I see it as being a
recommendation.

> For example, a poster provides code to print a report; the code
> is written using sections; and the problem is with control breaks.
> A recommendation solving the problem does not insist; a
> recommendation to use Report Writer does insist; and a
> recommendation to use paragraphs, not sections, also insists.

A recommendation solving the problem DOES insist. A recommendation to use
Report Writer does NOT insist, a recommendation to use paragraphs does NOT
insist.

>
> I think dictators and sheep might have that opinion. I don't.

I inferred differently from the way you segue from "recommend" to "insist".
What kind of person believes that recommending is the same as insisting? I
know dictators believe that. I know sheep do that. But independent
(bears?), don't.

> Having said that, my dictionary provides a definition of
> "desirable" as "advisable; recommendable." It is not a big
> leap to conclude that the inadvisable and practice not
> recommended is to be proscribed; but it does depend on the
> specifics.

It is a much bigger leap than I am willing to make. And it is a bigger leap
than I expect others to make.

Richard

2004-11-16, 6:44 pm

Robert Wagner

2004-11-16, 6:44 pm

On Mon, 8 Nov 2004 16:13:45 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On 5-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>That implies that you don't have dependencies.

If there is a fatal error, you set RETURN-CODE and STOP RUN. The job
scheduler checks RC and terminates the job, same as on mainframe.

Robert Wagner

2004-11-16, 6:44 pm

On 7 Nov 2004 23:26:15 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote

>
>Because 'both' cost twice as much as doing one. In any case, at most
>sites there is likely to be a backlog of systems that are required to
>be developed. In most cases these new system are cost justified on
>the basis that the result will be a cost saving overall.

There isn't much new development precisely *because* new systems must
be cost-justified. It's politically and administratively simpler to
classify development as maintenance. Much of the work I do is new
programs written from scratch, yet they're charged to the maintenance
budget. That's why we see figures like 80% maintenance.

As with many things in life, over time we forget the original reason
for a misclassification and start believing our own lies.

>Existing systems which already do their task reliably will not do it
>any better if rewritten, in fact it may well introduce bugs. There is
>no cost savings to be had, so the rewrite is entirely unjustified
>cost.

That's true if they require no maintenance. If they require lots of
maintenance, not necessarily changes but just searching them, clean
code pays for itself quickly.

Robert Wagner

2004-11-16, 6:44 pm

On Mon, 8 Nov 2004 08:41:25 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:gljro01r88d3eecnonbbc2r62rjpunehms@
4ax.com...

>
>And how exactly is "writing bad code" a reference to new code? Last time I
>looked, writing a patch to an existing program was still "writing code", and
>if the directive is "fix the bug and move onto something else", one may be,
>at one's own management's direction, required to continue the policy of
>"writing bad code".

Do you think they have two stylistic standards -- one for new code and
another for maintenance? The answer is they don't. They write new code
in '70s style.

Richard

2004-11-16, 6:44 pm

Robert Wagner <spamblocker-robert@wagner.net> wrote

>
> I disagree. Style can be refined in an EVOLUTIONARY (not
> revolutionary) way without deprecating what came before. In the world
> of cinema, such progression is called 'auteur theory'.

"""The auteur theory was, of course, not a theory of film at all, but
a method of evaluation which enabled people knowledgeable about film,
film history and particularly individual directors to show their
knowledge and superiority over the uneducated masses who did not know
what John Ford's cavalry trilogy was or the importance of cigarette
lighting in the films of Howard Hawks."""

While both programming and movies are evolutionary, the old ones are
not updated as part of a routine. Though 'The Jazz Singer' had audio
added and 'Casablanca' was colourised, these were not common practice,
remakes are usually failures. If movie companies spent their time
'updating' old movies then they would not have time to make new ones
and would go broke.

In much the same way with Cobol systems. Cost is a factor, they can
spend their time constantly revising old systems just to make them
prettier with no added functionality or they can write new one to
extend the function of IT into new areas.

> If change is gradual, the same themes appear in old and new code.
> There isn't a scism or fracture.

Only if the systems are continually worked on for other reasons. In
many cases systems may continue to be used for many years without any
need for change. You seem to suggest that they should be changed for
no other reason than to change the code. This, of course, also
introduces risk. Unnecessary risk.

> A weak but current example is
> replacing GO TO THE-EXIT with EXIT PERFORM.

1) The only compiler that has EXIT PERFORM in out-of-line in Chuck's
2) in-line EXIT PERFORM is not standard '85 and is only avilable in
a couple of compilers.
3) Out-of-line EXIT PERFORM is not even '02 standard
4) EXIT PERFORM may, or may not, be equivalent to GO TO X-exit

>
> Typedef is available on Micro Focus and Fujitsu.

Yes, how many mainframes run the PC compilers that support this ?

[color=darkred]
> IF condition
> action
> END-IF

You are implying that this cannot be:

IF condition
PERFORM action
END-IF
or
IF condition
CALL action
END-IF

>
> So you join delivery-address, taxable-sales-amount and tax-table in
> one place that isn't subordinate to any of the three. In OO, it would
> be a method of tax-amount.

> I said "far away .. in the same or another program."

Merely being in another program makes it 'far away'.

>
> A well-written program should log and bypass cases it doesn't know how
> to handle. They represent a 'bug' in the specs.

Exactly. A bug in the specs has nothing to do with 'programming
style' 'well written' or 'structured'. It may well be that the
programmer should make a note to the systems analyst/designer and have
code that reports cases not specified, but it does not relate in any
way to 'unstructured'.

Robert Wagner

2004-11-16, 6:44 pm

On 6 Nov 2004 14:22:31 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>
>"""The auteur theory was, of course, not a theory of film at all, but
>a method of evaluation which enabled people knowledgeable about film,
>film history and particularly individual directors to show their
>knowledge and superiority over the uneducated masses who did not know
>what John Ford's cavalry trilogy was or the importance of cigarette
>lighting in the films of Howard Hawks."""

The author would ban knowledgeable people from discussons. 'Don't ask
him about programming. He knows too much. Ask the intern we hired
yesterday.'

In Cambodia, people like the author sent 'intellectuals' to the
countryside for re-education.

>While both programming and movies are evolutionary, the old ones are
>not updated as part of a routine. Though 'The Jazz Singer' had audio
>added and 'Casablanca' was colourised, these were not common practice,
>remakes are usually failures. If movie companies spent their time
>'updating' old movies then they would not have time to make new ones
>and would go broke.

Consider the Hawks movies Rio Bravo and El Dorado. They had the same
characters and story line. The second was truly a rewrite of the
first.

>In much the same way with Cobol systems. Cost is a factor, they can
>spend their time constantly revising old systems just to make them
>prettier with no added functionality or they can write new one to
>extend the function of IT into new areas.

The black-and-white fallacy, again. Why not both?

>
>Only if the systems are continually worked on for other reasons. In
>many cases systems may continue to be used for many years without any
>need for change. You seem to suggest that they should be changed for
>no other reason than to change the code. This, of course, also
>introduces risk. Unnecessary risk.

I advocate rewrite as a by-product of required maintenance. At the
supermarket company I cited, nearly all programs were modified within
a year. If there had been programs, or better whole systems, that were
untouched, I would have left them alone. Other places I managed had
untouched systems.

>
>Yes, how many mainframes run the PC compilers that support this ?

One can do the same with copybooks. It jost doesn't look as nice.

>
>
>You are implying that this cannot be:
>
> IF condition
> PERFORM action
> END-IF
>or
> IF condition
> CALL action
> END-IF

I'd rather CALL action unconditionally and let it make the decision.
That way, the 'business rules' are complete within a single program.

Rick Smith

2004-11-16, 6:44 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:cmgl1d$7k7$1@peabody.colorado.edu...
>
> On 5-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:
[snip]
>
> I inferred differently from the way you segue from "recommend" to
"insist".

H'm, Mr Brazee, you "inferred" from something not yet written.
Is that right?

> What kind of person believes that recommending is the same as insisting?

Perhaps, a person who sees some recommendations as
implying, "Your way of programming is undesirable. I insist you
do it my way."

Chuck Stevens

2004-11-16, 6:44 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:tcmio011erm6g9nebq1k8vbea4sghsnohm@
4ax.com...
> On Wed, 3 Nov 2004 08:12:27 -0800, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
I[color=darkred]
of[color=darkred]
precisely[color=darkred]
>
> I haven't noticed avoidance of 88s.
>
> Use of PERFORM .. FOREVER is uncommon because the standard doesn't
> provide a mechanism to stop iterations in an out-of-line perform.
>

Sure it does. Has done so for decades. It's called "GO TO ... " from
within the PERFORM range!

;-)

wants[color=darkred]
there[color=darkred]
>
> Wants and Pays do not speak with a single voice.
>
> The Person Paying My Salary is an executive who knows nothing about
> programming style. If asked, he'd champion the style with lowest
> maintenance cost and highest reliability, without regard for shop
> traditions.

If you were brought in to *maintain* existing code in the least costly
manner possible? Some of the code I work on has been old enough to vote
for two decades. Sometimes I can manage to clean it up to make it more
maintainable and sometimes I can't, in which case corrections become "make
the least possible change to eliminate the problem."

> The person enforcing shop standards is a supervisor whose motivation
> is job security, not money.

That in no way mitigates the fact that he is the person chartered with
enforcing the shop standards, and if he is unable to convince his management
that overhaul costs are necessary disagrees with the CFO's priorities, his
primary motivation becomes a big issue!

> It's unfamiliar to Cobol programmers because the equivalent to UNDO --
> EXIT PERFORM -- can only be used with in-line PERFORM. We want the
> option to convert in-line to out-of-line when it becomes unwieldy. We
> avoid EXIT PERFORM because it removes that option.

We avoid INITIALIZE ... WITH FILLER ALL TO VALUE THEN TO DEFAULT in COBOL74
for the same underlying reason. What's your point?

> A straw man argument. You haven't shown there would be years of
> unprofitability. I cited one case where savings were realized the
> first year. I could have cited at least four others.

I have direct knowledge of a case in which a large and profitable bank
*initated* its own acquisition lock, stock and barrel by a larger competitor
several years ago because its financial analysts figured out that Y2K
remediation of their own application software would render the financial
holding company unprofitable for a period of some seven years. I think
that's a close-enough parallel.

You don't think overhauling an existing, functioning application suite for
the sole purpose of eliminating elements and constructs that have been
decreed unfashionable by the pundits *might* be considered unnecessary and
even wasteful by the people who sign the checks? That's not my experience!

> I say EXIT PERFORM would be an improvement for unstructured programs;

Thank you ...

> your response talks about seriously unstructured code still in
> production.

Yes ...

> How does the response disprove the assertion? It sounds
> like an example supporting the assertion.

The example is a case in which the customer has no desire whatever to change
the program unless it can be shown that it no longer works properly.

> If the customer upgrades to
> 2002, it will have to rewrite ALTER one way or another. EXIT PERFORM
> might well be the least intrusive translation.

In this case, the customer has no intention of upgrading this program to
ANSI-85 COBOL and would vehemently reject such a recommendation.

This is an example of a *customer* who is perfectly content to continue
using elements marked "obsolete" in the previous standard and absent
altogether from the current one, until such time as pigs fly. Any assertion
that might be taken to deprecate the absolute modernity or the quality of
the customer's application program would be *entirely* out of line, and
would likely prove very costly to *me* as well as to my company.

> I agree that quality is not the concern of the standards committee nor
> compiler vendor, but it is a valid concern of this forum.

True. The question is whether a program deemed "poorly written" by the style
mavens can, under any circumstance, meet the user's needs in a way the user
regards as adequate, and I contend it can.

> Posters here
> can legitimately criticize ALTER, GO TO and PERFORM THRU.

Also true. That in no way has anything to do with whether a program
containing ALTER *MUST IMMEDIATELY* be rewritten so that it works properly,
or even so that it thereby becomes a "good program".

As for me, I do happen to cringe when I see a program that contains ALTER,
but I don't run screaming from the room when I see a program that has
PERFORM THRU or GO TO. I happen to like SECTIONs because *if the
implementor so allows* they can reasonably be used to indicate some sort of
program structure bleeding over into the object-code realm.

But from my standpoint, a "good" program is a program that meets the
end-user's needs, whatever they are, and a "bad" program is one that does
not.

> Readers who care about quality might learn to program better.

They might well.

> Reactionaries will continue writing bad code.

Not necessarily. I would say a "reactionary" programmer would be a person
whose programming is characterized by *reaction* -- e.g. to trouble
reports -- rather than *proaction* -- deciding to overhaul code that
currently functions just to make it look better. If I were hired to be a
"maintenance programmer" on an application, I believe my management's most
reasonable expectation of my actions would be that they be *reactionary*,
and any *proactive* steps I took had better be defensible from *their* view
of *my* role! "Well, I thought it'd be a good idea if I rewrote it because
the coding style is *sooo* 1976 ..."?? I don't think so!

-Chuck Stevens

docdwarf@panix.com

2004-11-16, 6:44 pm

In article <de53p0lbkeh4i9fokt7g716ggrppeb1crp@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On Mon, 8 Nov 2004 08:41:25 -0800, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>
>
>Do you think they have two stylistic standards -- one for new code and
>another for maintenance? The answer is they don't. They write new code
>in '70s style.

I'm sorry, I got

here... it starts with talk about 'bad code' and
then, after a bit of pressing, turns to a reference about ''70s style';
this seems to take it out of the realm of quality (good vs. bad) and into
the realm of aesthetics (style).

DD

Richard

2004-11-16, 6:44 pm

Robert Wagner

2004-11-16, 6:44 pm

On Fri, 5 Nov 2004 11:56:52 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>To elaborate a bit on this point, if you manage to convince a Bean Counter
>that he *really* needs to spend the money to have his COBOL code rewritten
>so that it no longer Looks Yucky, the approach he's *most* likely to take,
>from all I hear, is that rather than rewrite it from Yucky COBOL into Trendy
>COBOL he'll elect to rewrite it from Yucky COBOL into LdJ (Langue-du-Jour)
>even if it costs more. I've seen such efforts(successful and otherwise) for
>several decades now, some successful, some otherwise. Doesn't seem to
>matter much what LdJ is; PL/I, Pascal, ADA, APL, VB, C, C++, Java and C#
>have all occupied that position at one time or another, in one context or
>another. As a COBOL programmer, would you rather work on programs written
>in Yucky COBOL or LdJ?

BIFURCATION

Also referred to as the "black and white" fallacy, bifurcation occurs
when one presents a situation as having only two alternatives, where
in fact otheralternatives exist or can exist.

Howard Brazee

2004-11-16, 6:44 pm

On 9-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

>
> If there is a fatal error, you set RETURN-CODE and STOP RUN. The job
> scheduler checks RC and terminates the job, same as on mainframe.

Ah, a matter of definitions. When a RETURN-CODE is within a particular range,
I call that an ABEND, and our CA software makes sure that it gets noticed.

Howard Brazee

2004-11-16, 6:44 pm

On 9-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

>
> Do you think they have two stylistic standards -- one for new code and
> another for maintenance? The answer is they don't. They write new code
> in '70s style.

Who's "they"?

I maintain old code written with stylistic standards that are not at all the
standards of the new programs I write. And I have done so for years, working
at a variety of mainframe shops.

Sometimes, we even have purchased code that doesn't conform with either the old
shop standards nor the new shop standards.

So obviously you aren't referring to the mainframe shops I have worked at. So
again - who's "they"?

Howard Brazee

2004-11-16, 6:44 pm

On 10-Nov-2004, docdwarf@panix.com wrote:

>
> I'm sorry, I got

here... it starts with talk about 'bad code' and
> then, after a bit of pressing, turns to a reference about ''70s style';
> this seems to take it out of the realm of quality (good vs. bad) and into
> the realm of aesthetics (style).

Are you surprised?

docdwarf@panix.com

2004-11-16, 6:44 pm

In article <cmtbt6$8g$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 10-Nov-2004, docdwarf@panix.com wrote:
>
>
>Are you surprised?

Just

, as I said... but it is to be hoped that those involved in
making the asssertions can demonstrate where the source of my confusion
lies.

DD

Howard Brazee

2004-11-16, 6:44 pm

On 10-Nov-2004, docdwarf@panix.com wrote:

>
> Just

, as I said... but it is to be hoped that those involved in
> making the asssertions can demonstrate where the source of my confusion
> lies.

How do we define "bad code".

Obviously code that does not conform to requirements is bad. But when someone
describes all the working programs in a shop as bad, that isn't what is being
referred to.

So we move to the next level. Code that is not easily maintainable is bad.
Here we are forced into style wars. Code that is written in *my* style tends
to be easy for me to maintain. That is good. Code that is written in a style
that I am not used to is hard for me to maintain. That is bad.

Sure, I'm being simplistic. We can all find programs that are counter to those
observations. But when an entire shop is marked as *bad*, it is because that
style of code that is used by that shop is a style we don't care for. Maybe
that style is bad. But now we are in style wars.

docdwarf@panix.com

2004-11-16, 6:44 pm

In article <cmtf48$29p$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 10-Nov-2004, docdwarf@panix.com wrote:
>
>
>How do we define "bad code".

Plural majestatus est, Mr Brazee... I barely know how *I* define things,
let alone anyone else. When I initiate the use of the term - or when I
use a term whose use was initiated by another - I try to supply a
definition so as to minimise the possibility for confusion, when someone
else initiates or uses a term I leave such things to them.

[snip]

>But now we are in style wars.

That might seem to be the case, Mr Brazee, but perhaps the clarification I
requested could change this conclusion.

DD

Chuck Stevens

2004-11-16, 6:44 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:de53p0lbkeh4i9fokt7g716ggrppeb1crp@
4ax.com...

> On Mon, 8 Nov 2004 08:41:25 -0800, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
code.][color=darkred]
I[color=darkred]
and[color=darkred]
be,[color=darkred]
>
> Do you think they have two stylistic standards -- one for new code and
> another for maintenance? The answer is they don't. They write new code
> in '70s style.
>

I think someone who is either correcting a problem in an existing program or
making an enhancement to the program within its existing framework is not
necessarily "writing bad code" if they elect to follow the programming
conventions and style *as they exist in that program*. Sometimes it's
actually *preferable* to live with the warts than it is to go through the
trouble to remove them.

-Chuck Stevens

Robert Wagner

2004-11-16, 6:44 pm

On Wed, 3 Nov 2004 08:12:27 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:qr6go0tqvutkqbtuji7q0919s8j22plnl2@
4ax.com...

>
>The methods are neither common nor uncommon. What is relevant is whether
>they exist today or not, and whether they are straightforward or not, and I
>believe the answer to both of those is "yes". Now, if what you meant by
>"uncommon" was "not commonly used", that's a matter of personal style and of
>your exposure to it. I suspect the most straightforward method -- an
>88-level item referencing an invariant filler -- isn't that common precisely
>because many practicing programmers seem to avoid 88-level items to begin
>with (despite the continued enhancement to the feature in the various
>standards).

I haven't noticed avoidance of 88s.

Use of PERFORM .. FOREVER is uncommon because the standard doesn't
provide a mechanism to stop iterations in an out-of-line perform.

>
>Depends on whether The Person Paying Your Salary wants it there -- or wants
>it to stay there, even if it's for the simple reason that he wants it there
>and he wants it to stay there.

Wants and Pays do not speak with a single voice.

The Person Paying My Salary is an executive who knows nothing about
programming style. If asked, he'd champion the style with lowest
maintenance cost and highest reliability, without regard for shop
traditions.

The person enforcing shop standards is a supervisor whose motivation
is job security, not money.

>
>So the Dijkstra-inspired "DO FOREVER ... IF <condition> THEN UNDO ...END" is
>completely wrong-headed?

It's unfamiliar to Cobol programmers because the equivalent to UNDO --
EXIT PERFORM -- can only be used with in-line PERFORM. We want the
option to convert in-line to out-of-line when it becomes unwieldy. We
avoid EXIT PERFORM because it removes that option.

>So the appropriate response of a successful and profitable business, when
>some outsider says "your programming standards are hopelessly unfashionable"
>is "yessir, yessir, whatever you say sir. How many years of unprofitability
>are we going to have to go through to rectify this heinous crime?" ???

A straw man argument. You haven't shown there would be years of
unprofitability. I cited one case where savings were realized the
first year. I could have cited at least four others.

>
>Again, Mr. Wagner: we just received a trouble report from a large customer
>that turns out to have been a problem with the ALTER verb. The bug was
>preventing this customer from upgrading to new system software because the
>program, which has clearly (from internal evidence) been performing to the
>customer's satisfaction for something on the order of twenty years or more,
>no longer works correctly.

I say EXIT PERFORM would be an improvement for unstructured programs;
your response talks about seriously unstructured code still in
production. How does the response disprove the assertion? It sounds
like an example supporting the assertion. If the customer upgrades to
2002, it will have to rewrite ALTER one way or another. EXIT PERFORM
might well be the least intrusive translation.

>It is not the business of the *standards* committee to decide whether a
>program is "properly structured" or not. Nor is it the business of the
>*compiler vendor* to decide that. It is the *customer's* job to decide
>that -- or to care, or not to care.

I agree that quality is not the concern of the standards committee nor
compiler vendor, but it is a valid concern of this forum. Posters here
can legitimately criticize ALTER, GO TO and PERFORM THRU. Readers who
care about quality might learn to program better. Reactionaries will
continue writing bad code.

Howard Brazee

2004-11-16, 6:44 pm

LX-i

2004-11-16, 6:44 pm

Howard Brazee wrote:
> On 3-Nov-2004, LX-i <lxi0007@netscape.net> wrote:
>
> Top posted because I have quick questions and a long quote:
>
> So how does allowing this extension effect your code?

Not at all. :)

> How does explaining your
> code imply that Mr. Lacey is correct that adding this extension has the purpose
> of forcing the elimination of a style of programming?

I didn't address that part of his argument.

> If this extension is
> added, your code will still work perfectly well - and nobody's proposing to make
> it illegal.

Right. What I was more-or-less defending was "Go to" as a legitimate
structuring tool. Yes, Perform Thru bugs me, and I still think that
exit paragraphs serve to make maintenance more complicated. But, I was
showing that "Go to" can be used, and be completely understood, in cases
where a "Perform Forever" type structure is needed.

It's been demonstrated here how several constructs can be misused - Go
to is but one of them. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Robert Wagner

2004-11-16, 6:44 pm

On Wed, 10 Nov 2004 15:24:50 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 9-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>Who's "they"?
>
>I maintain old code written with stylistic standards that are not at all the
>standards of the new programs I write. And I have done so for years, working
>at a variety of mainframe shops.
>
>Sometimes, we even have purchased code that doesn't conform with either the old
>shop standards nor the new shop standards.
>
>So obviously you aren't referring to the mainframe shops I have worked at. So
>again - who's "they"?

You're a saint. "They" are the other 99% who write new code using old
standards.

docdwarf@panix.com

2004-11-16, 6:44 pm

In article <5cs7p0hdhvc4mmq7cpe7f78umc8bd3fkkb@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On Wed, 10 Nov 2004 15:24:50 GMT, "Howard Brazee" <howard@brazee.net>
>wrote:
>

[snip]
[color=darkred]
>
>You're a saint. "They" are the other 99% who write new code using old
>standards.

Mr Wagner, 87.5% of all statistics on the UseNet are just made up on the
spot... it seems that your statement boils down to a simple ''They' is
'they', of course'.

DD

Richard

2004-11-16, 6:44 pm

Robert Wagner <spamblocker-robert@wagner.net> wrote

> You're a saint. "They" are the other 99% who write new code using old
> standards.

Is this another statistic that you have generated as a by-product of
your reading the 'programmer wanted' ads, or did you just pull it out
of your arse in your usual way ?

Howard Brazee

2004-11-16, 6:44 pm

Chuck Stevens

2004-11-16, 6:44 pm

LX-i

2004-11-16, 6:44 pm

Rick Smith wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:cmgl1d$7k7$1@peabody.colorado.edu...
>
>
>
> Perhaps, a person who sees some recommendations as
> implying, "Your way of programming is undesirable. I insist you
> do it my way."

This sounds an awfully lot like someone who is insecure. Debates over
styles are fine. Recommendations are fine. Unless the person is your
supervisor, though, you can safely ignore any "insisting," since that
person likely does not have the wherewithal to back up their insistence.

Are you insecure in your programming style? Do you do things that you
think other folks would find unpopular? If so, get a little confidence.
I was actually laughed at by my compiler vendor for using the
"preceding period" style, where paragraph names are done like

.. the-next-paragraph.

Did that stop me? No - I realized the benefits that I realized with
that style (even once I figured out that the compiler was getting

with the period in column 8 - had to change it to something like

Richard

2004-11-17, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote

> The period (full stop) when followed by a space is DEFINITELY a "separator".
>
> The following code is valid in the '85 Standard (and the '02 and as far as I
> know every standard)
>
> MOVE A TO B. ADD 1 TO C.

The full stop is a _statement_ and _sentence_ terminator. You are
correct that it isn't a _line_ terminator. It isn't a 'separator' at
all because it is not needed between consecutive statements, as a
separator would be, it is only needed to terminate them.

My reference to it being a terminator and not a separator is that it
should be (IMHO) considered as part of what it is terminating. The
style that tries to put it in front of the next line is flawed because
that would only be appropriate if it was, in fact, a separator (and
then probably not anyway).

As a comparison the ';' is a terminator in C and a separator in
Pascal. This does make a difference in blocks of statement, and
especially in if statements.

in Pascal:
if ( condition ) then
statement1
else
statement2 ;

in C:
if ( condition )
statement1 ;
else
statement2 ;

in Pascal:
begin
statement1 ;
statement2
end

in C:
{
statement1 ;
statement2 ;
}

William M. Klein

2004-11-17, 3:55 am

Are you saying that is the way YOU would design COBOL? If so, fine - that's
your opinion. If you are talking about every COBOL Standard (and all conforming
implementations) then you are in error.

See (for example) page 82 of the '02 Standard which says,

"3) The COBOL character period, when followed by a space, is a separator. The
separator period shall be used only
to indicate the end of a sentence, or as shown in formats."

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0411161715.5393014e@posting.google.com...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote
>
>
> The full stop is a _statement_ and _sentence_ terminator. You are
> correct that it isn't a _line_ terminator. It isn't a 'separator' at
> all because it is not needed between consecutive statements, as a
> separator would be, it is only needed to terminate them.
>
> My reference to it being a terminator and not a separator is that it
> should be (IMHO) considered as part of what it is terminating. The
> style that tries to put it in front of the next line is flawed because
> that would only be appropriate if it was, in fact, a separator (and
> then probably not anyway).
>
> As a comparison the ';' is a terminator in C and a separator in
> Pascal. This does make a difference in blocks of statement, and
> especially in if statements.
>
> in Pascal:
> if ( condition ) then
> statement1
> else
> statement2 ;
>
> in C:
> if ( condition )
> statement1 ;
> else
> statement2 ;
>
> in Pascal:
> begin
> statement1 ;
> statement2
> end
>
> in C:
> {
> statement1 ;
> statement2 ;
> }

Robert Wagner

2004-11-17, 8:55 am

On Tue, 16 Nov 2004 15:16:36 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 15-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>I thought I remember you discussing your style once, and saying that's what your
>sub-programmers use.

I said it was a collaborative style developed and agreed to by all. In
some cases, I changed my style to follow the consensus.

My standards were organic, encouraging growth. My standards are
positive, telling people what TO do rather than what NOT to do.

> But anyway - if you require them to follow published
>standards, what exactly is your criticism of mainframers with the same
>requirement?

Most mainframe shop standards stifle progress by mandating Lowest
Common Denominator. They should elevate inexperienced programmers
rather than lowering everyone else to their level.

>
>You mean ask questions? I suppose you're right, many (more than a dozen) don't
>know that they should do this - and should also make sure that the programs
>conform to requirements.

They're penny wise and pound foolish. They conserve what they have at
the expense of losing what their staff could have accomplished.

Howard Brazee

2004-11-17, 3:55 pm

On 16-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> I said it was a collaborative style developed and agreed to by all. In
> some cases, I changed my style to follow the consensus.
>
> My standards were organic, encouraging growth. My standards are
> positive, telling people what TO do rather than what NOT to do.

Yep. In my experience that's a good description of standards.

> Most mainframe shop standards stifle progress by mandating Lowest
> Common Denominator. They should elevate inexperienced programmers
> rather than lowering everyone else to their level.

Again, I have to bow to your superior knowledge, as my limited experience is
completely different from "Most mainframe shop standards". I must be extremely
lucky.

>
> They're penny wise and pound foolish. They conserve what they have at
> the expense of losing what their staff could have accomplished.

I'm not following you here - do you have any examples?

LX-i

2004-11-17, 3:55 pm

with the period in column 8 - had to change it to something like

Richard

2004-11-17, 8:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote

> "3) The COBOL character period, when followed by a space, is a separator.
> The separator period

They may _name_ it as a separator, but its _function_ is a terminator.

> shall be used only to indicate the end of a sentence,

Where 'end' is synonomous with 'terminate' in this context.

> or as shown in formats."

Which is invariably at the end to terminate a part or the whole.

Both separators and terminators separate objects, the difference in
function is at the end of a structure. A separator is not required, a
terminator is.

object separator object
object terminator object terminator

In Cobol the structure must be:

sentence . sentence .

Thus the 'full stop space' is functionally a terminator.

Yes, the standard is wrong in calling it a separator, not that it
matters much.

William M. Klein

2004-11-17, 8:55 pm

The "category" of separator in COBOL includes
==
(
)
:

Interestingly enough for purposes of COPY/REPLACING in

Pic 9(2).99

the "(" and the ")" are separators but the "." is not (because it isn't followed
by a space.

"separator" (in COBOL terms) does lots of things. one of them is (for a period)
to terminate a structure - but that is simply a "subset" of all the things a
COBOL separator can do/be.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0411170953.5cd32748@posting.google.com...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote
>
>
> They may _name_ it as a separator, but its _function_ is a terminator.
>
>
> Where 'end' is synonomous with 'terminate' in this context.
>
>
> Which is invariably at the end to terminate a part or the whole.
>
> Both separators and terminators separate objects, the difference in
> function is at the end of a structure. A separator is not required, a
> terminator is.
>
> object separator object
> object terminator object terminator
>
> In Cobol the structure must be:
>
> sentence . sentence .
>
> Thus the 'full stop space' is functionally a terminator.
>
> Yes, the standard is wrong in calling it a separator, not that it
> matters much.

Richard

2004-11-18, 8:55 am

Robert Wagner <spamblocker-robert@wagner.net> wrote

> Not having an official '85 standard, I say that based
> on Micro Focus notation in their manual.

In my MF manual it quite clearly states that all of 'free format' is
an MF extension.

Richard

2004-11-18, 8:55 pm

Peter Lacey

2004-11-18, 8:55 pm

Robert Wagner wrote:
>

>
> Mainframers say they support diversity. Try going to a code review
> with a PERFORM that doesn't have THRU, or a paragraph name that isn't
> prefixed by five meaningless numbers, or a working-storage item not
> prefixed 'ws-'.

Standards are standards. All the three you cite can be justified
(although I personally have never got past 4 digits). You don't like
them; fine. Still doesn't make them wrong. Used consistently they will
prevent certain mistakes.

PL

docdwarf@panix.com

2004-11-18, 8:55 pm

In article <ituap09pknk18bks34tjlr21pkklmg3lg1@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 11 Nov 2004 19:04:29 -0500, docdwarf@panix.com wrote:
>
>
>'They' are hypocrites.

.... and poopie-heads, too, I'm sure.

>The Web site of my new contracting company says
>they support diversity. Directors' names are all from India, mostly
>the same university. Executives' names are also all from India.

It might be that people tend to surround themselves with those whom they
see to be similar to themselves, Mr Wagner; when I was on contract with an
insurance company in Hartford, CT in the mid-1990s I was just amazed by
the fact that - even in those times of Diversity and Equal Employment
Opportunity - that everyone I saw in a corner office, expecially in the
opulent Old Building, was a tall Caucasian male with grey hair, an
aquiline nose and blue or green eyes. What a coincidence, eh?

>
>Mainframers say they support diversity.

Mr Wagner, Mr Brazee has pointed out that your assertions about
mainframers do not represent the shops he's worked at.

>Try going to a code review
>with a PERFORM that doesn't have THRU, or a paragraph name that isn't
>prefixed by five meaningless numbers, or a working-storage item not
>prefixed 'ws-'.

Mr Wagner, I'm not sure what you are doing here... are you railing against
all shop standards or just the one which offend your Delicate Sense of
Aesthetics?

DD

Richard

2004-11-18, 8:55 pm

Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote

>
> 1971 - 1959 = at most 12 years.
>
> Not 2 decades.

While Intel did introduce the 4004 in 1971, that assembler was _not_
for 4004. In fact it is probably for 8086+. ie from 1978 or after. And
that assembler code is not an Intel assembler, but seems to be
Microsoft's MASM from 1981 or later.

Also 'the time frame relevant' is _prior_ to the introduction of Cobol
as it was to cater for _established_ techniques in use.

Richard

2004-11-18, 8:55 pm

Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote

> With assemblers, one can only ....

You appear to think that 'assemblers' are just one language that you
can talk about as one might, for example, 'with Cobol' or 'with
Pascal'.

There are hundreds, if not thousands, of assemblers. These range from
simple 'order code loaders' to complex macro languages.

> one can only branch/jump to 1000-START-SOMETHING and
> then the routine decides when and where to return.

There may be whole rafts of various assemblers that do that, there
certainly are some that do not.

In many cases a 'branch/jump' does not pass any information about
where it came from. The routine cannot 'decide' because there is no
information. In some cases, such as stack based machines, a 'call'
will put the return address in some recoverable place that the routine
can use. In others, the program can set the return point explicitly
prior to the 'branch/jump', such as by modifying the end point of the
routine to branch/jump back.

> That is a huge difference.

Only when you restrict what an assembler is to those that are a
'difference' in the first place.

Howard Brazee

2004-11-18, 8:55 pm

On 12-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> Mainframers say they support diversity.

We do? To get a better handle in what kind of diversity you are talking about
- could you point me to a citation of what we claim?

> Try going to a code review
> with a PERFORM that doesn't have THRU, or a paragraph name that isn't
> prefixed by five meaningless numbers, or a working-storage item not
> prefixed 'ws-'.

Do it all the time - these aren't local standards.

> Your chance of making it through is less than the
> chance of a Pakistani being appointed to the board of my contracting
> company.

Are you implying that when you sub-contract work to other programmers they don't
have to follow some standards that you like?

Howard Brazee

2004-11-18, 8:55 pm

On 13-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> Paragraph numbers were invented when we worked from printed listings.
> They were an index used to find paragraphs. Their utility ended when
> we went to text editors .. THIRTY YEARS AGO.

A minor utility is that it is easy for me to locate paragraph names if I can
search for a numeric character in column 8.
I know this is not very useful - but what di

vantage is there to this standard
that is big enough to counter this advantage?

> Perform THRU -EXIT was invented because we didn't have EXIT PARAGRAPH.
> Under Micro Focus, which had EXIT PARAGRAPH for years, and all 2002
> compilers, THRU should be obsolete. Moreover, structured code has no
> need for premature exits.

My compiler doesn't have EXIT PARAGRAPH.

My new code has no need for premature exits, and I do not write new code with
PERFORM THRU. But I do maintenance on existing programs that have been
working for decades. It is not cost effective to re-write all the programs for
minor business rules changes.

> Prefixing data names with a section or file qualifier doesn't prevent
> mistakes, it causes them. The rationale for copybooks is having a
> single description of a record layout. Having to maintain multiple
> copies, differing only by file name, defeats the purpose of copybooks.

I haven't come across shops that had multiple copybooks for the same record.
And I only rarely see file qualifiers used. The following is one of the rare
cases where MOVE CORRESPONDING is used in a program:

COPY LAMMASTP REPLACING ==EDUSERV-RECORD==
BY ==TAPEOUT-REC==.

COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.

- - - - - - - - - - - - - - - 69 Line(s) not D
MOVE CORRESPONDING EDUSERV-RECORD TO TAPEOUT-REC

This copies a file that was FTPd to us into the old format of the tape that was
sent to us.

Including my contracting time, I have only worked for a couple of dozen
mainframe shops, including IBM, Univac, Burroughs, DEC, and Honeywell. The
fact that my experience doesn't match what you know to be true about mainframes
may simply be an indicator of how limited my knowledge is.

Howard Brazee

2004-11-18, 8:55 pm

On 13-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> Their single standard, written in the '80s, is the reason Cobol is
> called a dinosaur.

*Anything* gets called a dinosaur by people using newer tools. They don't need
a reason.

Peter Coffee said almost a decade ago that CoBOL isn't a dinosaur, it's a shark.
Sharks are older than dinosaurs, but they are still around.

Still, someone writing in the language of the day doesn't need to know anything
about CoBOL to call it a dinosaur say it has been dead for eons. Especially
since he expects to be programming in his tool for decades to come.

Warren Simmons

2004-11-18, 8:55 pm

Early programming used among other things, cards. Everyone should
have to re-sequence a program of punched cards that have been dropped.

There may still be places were this might help, I don't know, but
the fact that they were used stems from the card input used then.

Warren Simmons

Joe Zitzelberger wrote:
> In article <9Kl5eEXuflB@jpberlin-l.willms.jpberlin.de>,
> l.willms@jpberlin.de (Lueko Willms) wrote:
>
>
>
>
>
>
>
> Now I'm really

. I've never seen an instruction set that had a
> THRU -EXIT type instruction. It just isn't possible that this is a
> carryover from assembler since there really is not way to do it in
> assembler.
>
> (Of course you can do everything in assembler, but you have to really
> contort yourself to be able to call a subroutine and declare, at the
> time you call it, where it will end.)
>
> In fact, I know of no construct in any programming language, from bare
> metal to 4GL, that allows you to call an function and declare an end
> point for it at the same time.
>
> Cobol is the only place where this particular notion exists.
>

Richard

2004-11-18, 8:55 pm

Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote

>
> Now I'm really

. I've never seen an instruction set that had a
> THRU -EXIT type instruction. It just isn't possible that this is a
> carryover from assembler since there really is not way to do it in
> assembler.

Not with _an_ instruction, no. Typically it may have been done is
assembler, when used in self-modifying programs, by setting the return
branch into a location at the end of a routine and then jumping to the
routine.

> (Of course you can do everything in assembler, but you have to really
> contort yourself to be able to call a subroutine and declare, at the
> time you call it, where it will end.)

That is correct, you do that _before_ you jump to the routine. Prior
to 1959 few machines were stack based so 'CALL' didn't push the return
address onto the stack, it had to be put into the code at the return
point.

William M. Klein

2004-11-18, 8:55 pm

Robert,
Get REAL !!!!

Do you ever check your fact before posting????

The '85 Standard *definitely* kept the A-/B- margin distinction. (I.e. column 8
vs column 12). It is true that the '02 Standard removed this distinction.

If you ever used the FLAGSTD directive with your Micro Focus compiler, you would
see that it CORRECTLY flags statements starting in column 8 as "non-conforming
and an extension".

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:dmqcp0l44477l9oou9h7sp7eir2r7sqi41@
4ax.com...
> On Fri, 12 Nov 2004 14:30:19 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
>
> The ANSI Cobol 85 standard removed the distinction between columns 8
> and 12. It sounds as though your compiler may be non-compliant.

LX-i

2004-11-18, 8:55 pm

Robert Wagner wrote:
> On Fri, 12 Nov 2004 14:30:19 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
>
>
>
> The ANSI Cobol 85 standard removed the distinction between columns 8
> and 12. It sounds as though your compiler may be non-compliant.

Are you sure it was the '85 standard? I thought the 2002 standard
formalized "free-format" text...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

William M. Klein

2004-11-19, 3:55 am

The '02 Standard *does* include the following substantive change (see page 826:

"54) Fixed-form reference format area A and B removed. Areas A and B of the
previous COBOL standard reference format have been combined into one area called
the program-text area. Restrictions of area A and area B have been removed. The
previous COBOL standard reference format is fully upward compatible."

Page IV-42 of the '85 Standard says the following about "continuation" lines:

"7.2.2 Continuation of Lines
Any sentence, entry, phrase, or clause may be continued by starting subsequent
line(s) in area B. These subsequent lines are called the continuation line(s)."

The text that your quote is a (potentially - but I don't think so - misleading)
paraphrase of is from pages IV-43 - 44) which states (in part),

"There are two types of such entries: those which begin with a level indicator
and those which begin with a level-number.

In the Data Division, a level indicator is any of the following: FD, SD, CD, RD.

In those entries that begin with a level indicator, the level indicator begins
in area A, followed by at least one space, and then followed with the name of
the subject of entry and appropriate descriptive information.

Those entries that begin with level-numbers are called data description entries.
...
In those data description entries that begin with a level-number 01 or 77, the
level-number begins in area A, followed by at least one space, and then followed
with its associated record-name or item-name, if ..."

I see no indication (in the Substantive change appendix) that this is any
different from the '74 Standard, but it might be ...)

***

The exact quote (which you faild to include) which I think you ERRONEOUSLY made
was,

"The ANSI Cobol 85 standard removed the distinction between columns 8 and 12. It
sounds as though your compiler may be non-compliant."

Again, if you are going to make statements about what the '85 Standard did or
did not allow or require, then check THAT - not some vendors "re-wording" of it.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:t49fp0l3ng8trb6mp4kgkr1of1057ih3p5@
4ax.com...
> On Sun, 14 Nov 2004 05:01:24 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> I checked 1.2.1.3 at
> http://supportline.microfocus.com/s...2sp1/lrpubb.htm
>
> "Section names and paragraph names begin in area A and are followed by
> a period and a space. Level indicators FD, SD, CD and RD begin in area
> A and are followed in area B
>
> [ANS85] or area A
>
> by the appropriate description. Level numbers 01 and 77 begin in area
> A and are followed in area B
>
> [ANS85] or area A
>
> by the data description. Level numbers 02 through 49, 66 and 88 begin
> in area B. "
>
> I interpret that to mean ANS85 relaxed the columns where statements
> continue and, to the point here, where they end. In other words, the
> terminating period can be in area A.
>
>
> What about statements ending in column 8? That was the original
> question.
>

Joe Zitzelberger

2004-11-19, 3:55 pm

In article <2hmpp05p1nijcp02lahqdcmu9euooe5au4@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:

> On Thu, 18 Nov 2004 01:25:16 -0500, Joe Zitzelberger
> <joe_zitzelberger@nospam.com> wrote:
>
>
> I too was talking about generic call. The standard call protocol used
> by operating systems, C, assembly language, etc. pass a parameter
> list.

Some of the things I cited, like GOSUB simply go to a routine and share
global data within a module...

Joe Zitzelberger

2004-11-19, 3:55 pm

In article <217e491a.0411181033.51dce36f@posting.google.com>,
riplin@Azonic.co.nz (Richard) wrote:

> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote
>
>
> PERFORM A
> ...
> A SECTION.
> A1.
> PERFORM A2
> ....
> A2.
> ....
> B SECTION.
>
> No THRU there.

What problem here? Does not A execute until the end of the Section?

(I have to admit ignorance here, having never tried to write Cobol on a
machine that lacked virtual memory and fixed disks, I've never wanted to
do overlays in Cobol -- when resources are that tight, I tend to write
in assembler)

Does not "PERFORM A" begin execution at A? And "Perform A2" execute A2
until it completes? Then fall thru to A2. Then exit the initial
"Perform A"?

How do sections work?

>
> I show you why it cannot be done with CALL/RETURN and you complain.
>
> In fact it is not just THRU or SECTIONs:
>
> PROCEDURE DIVISION.
> A. PERFORM B.
> B. DISPLAY "B".
> C. STOP RUN.
>
> B is done twice, once it has to RETURN, the next time it has to drop
> through.

Fall-thru is an odd behavior, but does not make simple out of line
perform a semantically non-call. The 'Perform B' properly executes B
and returns control to the statement immediatly following the perform.

The riskyness of writing fall-thru code is a topic for (yet another)
thread...

Howard Brazee

2004-11-19, 3:55 pm

On 18-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> Are you sure about the same line? Placing the period on a line by
> itself is a common style.

I learned that it was a style, only by participating on this forum. I infer
that practitioners of this style have better vision than I have.

Richard

2004-11-20, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote

>
> I learned that it was a style, only by participating on this forum. I infer
> that practitioners of this style have better vision than I have.

Or maybe better text editors. Mine shows the full stop as white on
red while all else is various colours on a blue background.

Richard

2004-11-20, 8:55 am

Robert Wagner <spamblocker-robert@wagner.net> wrote

>
> I don't recall numeric labels. Here's some typical Intel assembly
> language:

WTF has Intel assembler the do with the issue ? that was 2 decades
after the time frame relevant to the issue.

Robert Wagner

2004-11-20, 8:55 am

On Sun, 14 Nov 2004 05:01:24 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Robert,
> Get REAL !!!!
>
>Do you ever check your fact before posting????

I checked 1.2.1.3 at
http://supportline.microfocus.com/s...2sp1/lrpubb.htm

"Section names and paragraph names begin in area A and are followed by
a period and a space. Level indicators FD, SD, CD and RD begin in area
A and are followed in area B

[ANS85] or area A

by the appropriate description. Level numbers 01 and 77 begin in area
A and are followed in area B

[ANS85] or area A

by the data description. Level numbers 02 through 49, 66 and 88 begin
in area B. "

I interpret that to mean ANS85 relaxed the columns where statements
continue and, to the point here, where they end. In other words, the
terminating period can be in area A.

>The '85 Standard *definitely* kept the A-/B- margin distinction. (I.e. column 8
>vs column 12). It is true that the '02 Standard removed this distinction.
>
>If you ever used the FLAGSTD directive with your Micro Focus compiler, you would
>see that it CORRECTLY flags statements starting in column 8 as "non-conforming
>and an extension".

What about statements ending in column 8? That was the original
question.

Peter Lacey

2004-11-20, 8:55 am

Robert Wagner wrote:
>
>
>
> 'Experts' say CORRESPONDING should be avoided. I don't want to open
> that debate.

There you have the entire style wars debate in a nutshell. Some people
like to use a construct or a method, others advise fiercely against it.
Both are right, from one point of view or another.

So far as I'm concerned, there are only two criteria that need to be
applied:
1) does the program work
2) is it easy to follow for TPB ("The Poor Bastard") who's doing
maintenance.

PL

Warren Simmons

2004-11-20, 3:55 pm

evolvED and ruler are two free programs I have recently found.
I've used the ruler, and for someone with failing eyesight, it's
great. I've looked at evolvED but not tried it yet. It covers
several languages, including Cobol, and has other tools for the
developer.

Warren Simmons

Richard wrote:
> "Howard Brazee" <howard@brazee.net> wrote
>
>
>
>
> Or maybe better text editors. Mine shows the full stop as white on
> red while all else is various colours on a blue background.

Howard Brazee

2004-11-21, 3:55 am

On 15-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

>
> Peter Lacey:
> So far as I'm concerned, there are only two criteria that need to be
> applied:
> 1) does the program work
> 2) is it easy to follow for TPB ("The Poor Bastard") who's doing
> maintenance.

Huh? That's a citation on how we support diversity? I have to admit
puzzlement here.