COBOL ain't quite dead - yet ! - cobol

<docdwarf@panix.com> wrote in message news:geeipb$1jb$1@reader1.panix.com...
> In article <6muradFirp0kU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>
>>
>><docdwarf@panix.com> wrote in message
>>news:gec9p1$9b1$1@reader1.panix.com...
>
> [snip]
>
>>> How curious... I recall reading, decades on back, in a Very Reputable
>>> Source (I think it was 'The Reader's Digest') that there was a
>>> telephone-number one could dial in Austria and get - granted, with the
>>> quality available in the late 1960s, rotary-dial telephones and actual
>>> copper-wire connections - a 'concert A', 440 cycles, in the same way
>>> that
>>> one could, during those days, call a local number in some parts of the
>>> USA
>>> and get the time of day.
>>
>>I never heard about that. It's impressive, for the time.
>
> What I drew from it was that different societies consider *very* different
> Should Be available from a given technology... but I was a bit younger
> then.
>
> [snip]
>
>>> It has been my experience, Mr Dashwood, that *very* few people are
>>> sufficiently creative to want something Truly New... in the
>>> business-world
>>> I inhabit I usually see 'Well, what I want is more-or-less what Jim gets
>>> for the quarterlies and Jane gets for the semi-annuals... but sorted
>>> differently... and could you somehow get it to underline the deleted
>>> entries that aren't there any more?'
>>
>>Yes, but we should live in hope... right, Doc? :-)
>
> One may desire the finest of chicken-meat, Mr Dashwood, but it is not a
> bad idea to be ready to deal with the meanest of sausages...
>
> ... so hope for the breast but prepare for the wurst.
>
Ja, freilich... :-)

Good one, old sausage.

Pete.
--
"I used to write COBOL...now I can do anything."

Richard <riplin@azonic.co.nz> wrote in message
news:18e8bb27-c836-4a0e-b611-04c111a41ee8@r37g2000prr.googlegroups.com...
> On Oct 30, 10:12 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
> > "Howard Brazee" <how...@brazee.net> wrote in message
> >
> > news:747hg4965hgegcuojhe10um7ic1f5lnccg@4ax.com...
> >
> > >I have seen
> >
> > > PERFORM AAA THRU AAA-EXIT.
> >
> > > AAA SECTION.
> > > AAA-PARAGRAPH.
> > > ...
> > > AAA-EXIT.
> > > EXIT.

> The problem with that it that breaking down the sections in a logical
> way is too much effort. Putting in a paragraph label is a lightweight
> solution that makes you feel that the code is properly structured when
> it is not. The style of having 3 labels and an EXIT for everything
> makes it too laborious to properly compose, the style gets in the way
> of expression.

Not if you're used to it. See your own comment below.

> Unreferenced paragraph labels (ie drop-through) causes additional time
> for the next programmer who has to check whether this would cause a
> logic change. For example if the PERFORM had been done in error to the
> first paragraph name instead of the section name then the spurious
> paragraph label would end the perform while a comment line would not.
>
> Having the section and first paragraph labels 'costs' the possibility
> of the wrong one being performed. Having an exit label 'costs' the
> possibility of errors such as goto the wrong one, or having a goto
> added when the paragraph was performed in error.
>
> Some of those errors would still have the program perform perfectly
> _until_, for example, a goto exit was added.
>
> As the only validation for the correctness of the style is by visual
> inspection of the whole program then it is not a style that I would
> use.
>

The possibility of the errors you mention is obviated by testing, isn't it?
Surely you don't think that people using this style don't perform the
obvious checks? As for the "correctness of the style" - I don't fully
understand what you mean by that; it strikes me as an esthetic matter rather
than a functional one - there are tools to format the listing, to flowchart
it, to determine execution paths, to show the usage of labels. A purely
visual inspection of any non-trivial program would be too laborious and
error-prone to trust.

>
> What is 'easy' is entirely what you are used to. When one writes code
> in a particular style one knows exactly the idiom and thus makes no
> (or fewer) mistakes. I have worked on code that is as you describe
> that had many errors and bug-traps. It was obvious that some other
> programmer had later worked on the code and didn't understand the
> idiom, or didn't adhere to the style correctly.
>

So it wasn't the style that was to blame, was it? Just as you say, "What is
'easy' is entirely what you are used to.".

My opinion is that the only persons qualified to judge styles are the ones
that have worked with many. Many times I have had to maintain or make
changes to programs written in styles that I didn't like, but by conforming
to that style I almost always did the job properly and learned something in
the process. I STILL don't like goto-less programming but I'm not about to
say that it shouldn't be used for that reason.

(My one unsuccessful maintenance experience was on a program that neither I
nor the previous SIX people that tried could understand how it worked at
all. I gave up and rewrote it).

PL

Typically the GO TO PARAGRAPH-EXIT command is a way to get around a
bad record in a batch run that aborted in the middle of the night, and
the on-call programmer needed a quick fix.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison

On Nov 1, 9:14 am, "tlmfru" <la...@mts.net> wrote:
> Richard <rip...@azonic.co.nz> wrote in message
>
> news:18e8bb27-c836-4a0e-b611-04c111a41ee8@r37g2000prr.googlegroups.com...
>
>
>
> > On Oct 30, 10:12 am, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
> > > "Howard Brazee" <how...@brazee.net> wrote in message
>
> > >news:747hg4965hgegcuojhe10um7ic1f5lnccg@4ax.com...
>
> > > >I have seen
>
> > > > PERFORM AAA THRU AAA-EXIT.
>
> > > > AAA SECTION.
> > > > AAA-PARAGRAPH.
> > > > ...
> > > > AAA-EXIT.
> > > > EXIT.
> > The problem with that it that breaking down the sections in a logical
> > way is too much effort. Putting in a paragraph label is a lightweight
> > solution that makes you feel that the code is properly structured when
> > it is not. The style of having 3 labels and an EXIT for everything
> > makes it too laborious to properly compose, the style gets in the way
> > of expression.
>
> Not if you're used to it. See your own comment below.

It is _still_ more work to add the additional lines, and make the
'obvious checks' on them than would be done without them.


> > Unreferenced paragraph labels (ie drop-through) causes additional time
> > for the next programmer who has to check whether this would cause a
> > logic change. For example if the PERFORM had been done in error to the
> > first paragraph name instead of the section name then the spurious
> > paragraph label would end the perform while a comment line would not.
>
> > Having the section and first paragraph labels 'costs' the possibility
> > of the wrong one being performed. Having an exit label 'costs' the
> > possibility of errors such as goto the wrong one, or having a goto
> > added when the paragraph was performed in error.
>
> > Some of those errors would still have the program perform perfectly
> > _until_, for example, a goto exit was added.
>
> > As the only validation for the correctness of the style is by visual
> > inspection of the whole program then it is not a style that I would
> > use.
>
> The possibility of the errors you mention is obviated by testing, isn't it?
> Surely you don't think that people using this style don't perform the
> obvious checks?

I think that they _DO_ perform the necessary checks, and do the
necessary testing, in fact they _have_ to perform those checks and
tests if they want to ensure that the program is correctly following
the style and that the various pieces are in place and used correctly.

I am advocating that a different style does not require many of those
'obvious checks' to be done because the errors and omissions that the
checks are for cannot be made. The checks are usually done visually
while I would like the compiler tell me when I do something wrong.

I have seen programs where a goto in a section went to the wrong exit
paragraph but it was for an exception that was quite rare and probably
never got tested.

What mechanism do you have to find such errors ? Judson had a program
that read through the source and checked for correctness including
that labels had the name according to a defined structures and that
gotos were only to the exit within the section.

It may be that the checks you perform are 'obvious' to you, but may
not be so obvious to the next programmer.

> As for the "correctness of the style" - I don't fully
> understand what you mean by that; it strikes me as an esthetic matter rather
> than a functional one

The 'style' is the one being discussed, or similar, where there is a
section, first paragraph, exit label and exit. Perhaps I should have
said "the correctness of the program in following the style".

> - there are tools to format the listing, to flowchart
> it, to determine execution paths, to show the usage of labels. A purely
> visual inspection of any non-trivial program would be too laborious and
> error-prone to trust.

And checking the formatted listing and the flowchart and the execution
path is done how ? Visually ??? Laboriously ?? Error prone ? Do you
think that merely printing a flowchart proves the program to be
correct.

What I am advocating is automated checking as far as possible. It is
simple to prove that there are no GO TOs, SECTION headers, EXIT
SECTION, NEXT SENTENCE or certain other structure. While the absence
of these doesn't prove that the program is correct it eliminates a
number of 'obvious checks' that would otherwise have to be made.

> > What is 'easy' is entirely what you are used to. When one writes code
> > in a particular style one knows exactly the idiom and thus makes no
> > (or fewer) mistakes. I have worked on code that is as you describe
> > that had many errors and bug-traps. It was obvious that some other
> > programmer had later worked on the code and didn't understand the
> > idiom, or didn't adhere to the style correctly.
>
> So it wasn't the style that was to blame, was it? Just as you say, "What is
> 'easy' is entirely what you are used to.".

What I was saying is that many people claim that their style is
'easy', that the checks they do make are 'obvious', and that they do
not make mistakes with it, and they expect that others, including the
'next programmer' to find it just as easy and mistake free.

In fact the 'obvious checks' you refer to may well be obvious to you,
the question is: will the next programmer know that those checks are
'obvious' and do them ?

> My opinion is that the only persons qualified to judge styles are the ones
> that have worked with many.

Over the last 40 years of working with Cobol and several other
languages I have worked with many styles, including the one that Peter
uses.

> Many times I have had to maintain or make
> changes to programs written in styles that I didn't like, but by conforming
> to that style I almost always did the job properly and learned something in
> the process. I STILL don't like goto-less programming but I'm not about to
> say that it shouldn't be used for that reason.

Cobol went beyond goto-less programming 20 years ago.

What other languages, modern ones, have you also used ?

I suggest that if you learned to use Java, C#, Python, Ruby or similar
you may find that you change your mind about how programs should be
written.

> (My one unsuccessful maintenance experience was on a program that neither I
> nor the previous SIX people that tried could understand how it worked at
> all. I gave up and rewrote it).

I've done that too, including one where I designed the system and was
supposed to have all the programs written by the programmers. One
struggled with the program they were given for 3 weeks. When it was
required to be working at the end of the week I took it over, couldn't
understand what he had written (even though it was my spec), tossed it
away and wrote a working program overnight. It went live the next day.
That programmer never worked again on the same projects that I did.

In article <4qpmg49o239sugsi78gi1194doruec3g6l@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>Typically the GO TO PARAGRAPH-EXIT command is a way to get around a
>bad record in a batch run that aborted in the middle of the night, and
>the on-call programmer needed a quick fix.

Typically the GO TO -EXIT is a way to transfer control of the program's
execution to the statement (or end-of-paragraph/section) which follows the
invoking PERFORM THRU -EXIT... at least, that is what a PMAP/LIST of the
code has shown me this is what it does.

How/why/when/where this is invoked is up to the programmer/shop.

DD

Richard <riplin@azonic.co.nz> wrote in message
news:d0354600-0c9f-4979-ac64-84127e96412b@q26g2000prq.googlegroups.com...
>
> What other languages, modern ones, have you also used ?
>
> I suggest that if you learned to use Java, C#, Python, Ruby or similar
> you may find that you change your mind about how programs should be
> written.
>

I have used one you might not be familar with: Progress. Nothing
particularly special about it but it's still being enhanced (I think). It
made me very, very leery about nesting!

PL

On Thu, 30 Oct 2008 10:12:14 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>"Howard Brazee" <howard@brazee.net> wrote in message
>news:747hg4965hgegcuojhe10um7ic1f5lnccg@4ax.com...
>>I have seen
>>
>> PERFORM AAA THRU AAA-EXIT.
>>
>> AAA SECTION.
>> AAA-PARAGRAPH.
>> ...
>> AAA-EXIT.
>> EXIT.
>>
>>
>> I hate that, but apparently it works. When I maintain this,
>> sometimes I will replace the EXIT. with CONTINUE, when I add debugging
>> statements.
>
>Back in the late 60s as we started to evolve into "best practices", having
>tried all the various permutations of PERFORM.. PERFORM.. THRU... SECTIONs
>and paragraphs, the place where I was working decided (by general consensus)
>that SECTIONs would be used. They would be structured as you showed above,
>except that they could contain multiple paragraphs, the last of which would
>be an EXIT. It was permitted to code GO TO as long as the target was within
>the SECTION, but not outside of it, and any premature exit from the SECTION
>was via the last paragraph.
>
>The rule was you must ONLY PERFORM a SECTION, NOT a paragraph. You rightly
>picked up that mixing PERFORMS of paragraphs AND SECTIONs just leads to
>chaos. (The primary purpose of any paragraphs other then the first and last
>one in the section was to aid documentation; most of the time SECTIONS did
>not contain paragraphs other then the first and last one. Most of the time
>the last paragraph was never referenced,

When I work under such a rule, I code the -EXIT paragraph, but never go to it. I always
fall into it. The program would work the same without it.

>but it served to tie up everything

What does that mean?

>and was there should you ever need it.

You never need it, if the program is written well.

>It costs you nothing...

It costs two lines of code, three if you code an unnecessary paragraph after the section
header, and the time to enforce a pointless rule.

> This is very
>similar conceptually to PERFORMing a single paragraph, but the SECTIONing of
>code simply documents specific functionality better than a paragraph.

How? The section name contains no more information than a paragraph name.

Comments are the place to document functionality.

>A series of paragraphs is just a program. A series of SECTIONS delineates
>specific functions more visibly, in my opinion.)

No, a nested program delineates specific functions more visibly. Plus, you can see what
its inputs and outputs are.

>Some of us who were fond of PERFORM... THROUGH grumbled a bit and pointed
>out that the "range" of a SECTION was not specifc and things could be added
>to the wrong SECTION, or a SECTION PERFORMED from different places might
>sometimes need the new paragraph and other times not need it; with PERFORM
>...THRU you always knew exactly what was being performed. However, we all
>agreed to give the new idea a try.
>
>After a few weeks of implementing the new standard we all agreed it was
>excellent. It is simple, and clear. It avoided spaghetti code in a time when
>most COBOL sites were like Italian restaurants.
>
>To this day I code COBOL In that way and I don't apologise for it. With OO
>COBOL each SECTION often becomes a METHOD and gets invoked on SELF, rather
>than PERFORMED. This has the advantage that you can pass parameters to it
>and keep data within the code that uses it, rather than everything having to
>be global like it is if you PERFORM it.

The same arguments apply to nested functions.

>For "internal" (private) methods
>like this I don't mind sending them parameters, but I don't generally do
>this for public methods which are visible to the outside world, because that
>complicates the interface and has knock on effects on general maintenance. I
>use Properties, GETters and SETters for these instead.

By doing that, you've returned to everything global. You might as well write:

01 working-storage-section external.
02 customer-record.
...
02 product-record.
...
02 internal-variables.
...

In article <6lnng45rlarsqhpcfkj0sg2qeq8hfsr6pn@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 30 Oct 2008 10:12:14 +1300, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz>
>wrote:

[snip]

>When I work under such a rule, I code the -EXIT paragraph, but never go
>to it. I always
>fall into it. The program would work the same without it.

I'm not sure what you're calling 'the same', Mr Wagner. Consider a
program to process transactions across installations in a given region; a
Classic Method - down to the CAPS LOCK, of course - might have it:

E07172-READ-N-PROCESS.

PERFORM G76420-READ-TRANS-FILE THRU G76420-RTF-EX.
IF NO-MORE-TRANSACTIONS
GO TO E07172-RNP-EX
END-IF

IF NOT VALID-REGION-NO
MOVE '**** INVALID REGION NO IN E07172 FILE' TO ERRMSG-1
MOVE E07172-REC-CTR TO ERR-REC-CTR
MOVE 'REGION NO IN FILE BUT NOT VERIFY-TBL' TO ERRMSG-3
MOVE '**** CONTACT PROGRAMMING & ACCOUNTING' TO ERRMSG-3
MOVE '**** TERMINATING RUN - ENJOY THE EVENING' TO ERRMSG-4
MOVE 878 TO RETURN-CODE
GO TO 9999-ABEND-RTN
END-IF.

IF SOUTHERN-REGION
PERFORM E1000-DIXIE-STUFF THRU E1000-DS-EX
GO TO E07172-RNP-EX
END-IF.

IF MIDWEST-REGION
PERFORM E2000-CORN-BELT THRU E20000-EX
IF GULF-COAST
PERFORM E3000-KATRINA-DEVALUATION
THRU E3000-KD-EX
END-IF
GO TO E07172-RNP-EX
END-IF.

.... et and cetera. Now, see... it contains scope-delimiters for those who
just *have* to have the latest and greatest in twenty-years old
constructs, it has periods so you can stuff in new... stuff in the middle
of things and know where the effects will end AND those handy GO TOs save
you time and money on your condition checks... those IFs, minimally, cost
you a CLI and those pile up after a while.

Now sure, someone can say 'Pfooie... that's how folks coded thirty years
ago!'... to which the response might be 'yep... might there be something
in the water now-a-days which would make it not work?'

>
>>but it served to tie up everything
>
>What does that mean?
>
>>and was there should you ever need it.
>
>You never need it, if the program is written well.

You never need a fire extinguisher, if buildings are made well.

>
>>It costs you nothing...
>
>It costs two lines of code, three if you code an unnecessary paragraph
>after the section
>header, and the time to enforce a pointless rule.

No rule which results in a paycheck may be said to be 'pointless', Mr
Wagner... and if a couple of extra lines of code in order to be in line
with shop standards is too much for a person then it might be that such a
person is Too Delicate for the situation and would do better finding work
elsewhere.

DD

Richard <riplin@azonic.co.nz> wrote in message
news:d0354600-0c9f-4979-ac64-84127e96412b@q26g2000prq.googlegroups.com...
> And checking the formatted listing and the flowchart and the execution
> path is done how ? Visually ??? Laboriously ?? Error prone ? Do you
> think that merely printing a flowchart proves the program to be
> correct.

That is a rather superficial reply, don't you think? There is a vast
difference between reading a program listing and reading a formatted summary
of same.

>
>
> In fact the 'obvious checks' you refer to may well be obvious to you,
> the question is: will the next programmer know that those checks are
> 'obvious' and do them ?

The obvious checks I referred to are those involved in testing. Less
precise than I should have been.

>
>
> > Many times I have had to maintain or make
> > changes to programs written in styles that I didn't like, but by
conforming
> > to that style I almost always did the job properly and learned something
in
> > the process. I STILL don't like goto-less programming but I'm not about
to
> > say that it shouldn't be used for that reason.
>
> Cobol went beyond goto-less programming 20 years ago.
>
> What other languages, modern ones, have you also used ?
>
> I suggest that if you learned to use Java, C#, Python, Ruby or similar
> you may find that you change your mind about how programs should be
> written.
>

I didn't say I didn't use it. I did say I don't like it. Your statement
"Cobol went beyond goto-less programming 20 years ago" is too generalized.
The controversy started in the '70's, as I recall, and has never been
settled in a decisive sense - i.e, a step-by-step logical argument which
leads to an inescapable conclusion. It HAS been proved that you can write
perfectly well without using GOTO's - well, almost, because there was a
lengthy discussion in this group some time ago about a verb to break out of
loops - which was all about replacing a GOTO with something that did the
same function but wasn't called a GOTO. And the chosen construct lacked the
unerring explicitness of the GOTO.

It is not my intention to start another style war, especially over a subject
which will never be settled until everyone is dead - or perhaps, as PD
posits, there comes a time when programming as we inderstand it will no
longer exist. Style wars generally - i.e., most of the time - boil down to
"I do it this way and everyone else should too". I have argued with people
who won't use COMPUTE for stylistic reasons of their own! Way back when -
in the '70's when I was with Univac - one of our customers upgraded to a
9480 from a 9300 (for those who weren't there - a 9300 was a 32k machine
with disk & tape; a 9480 was 256k with disks & tapes and multiprogramming.
The customer would not use multiprogramming for love or money because he
didn't trust it - he was always afraid that the programs would interfere
with each other, corrupt each other's data, if they ran simultaneously. He
was soon replaced, because the 9480 cost considerably more than the 9300,
and the only advantage he got was that it used a faster printer; that would
have been OK but the machine was also replaced, because the new guy was a
Honeywell groupie. Both of them had a "style" - a way of doing things -
which weren't necessarily common. Anyway, the point is that people will
stake out their own undertanding and practice, and defend it with might and
main if attacked over it. Most people will change, albeit slowly and
secretly, if given time to retreat with dignity - IF the change is worth
making. If a programming style works well, and is readily maintainable (and
I don't plan to get involved in defining either of those, so don't bother
poking me), then nothing more needs to be said. When it comes time for the
program to be replaced, rewritten, or enhanced significantly - then styles
may become important.

PL