Cobol - change variables

Author

change variables

jferreira80@gmail.com

2006-07-04, 6:55 pm

Hi,

I have a little question...

supose that i have 99 variables loaded by a SQL statement, with names
VARIAxx where xx is 01 to 99.
supose other variable ORDER with a xx value, again with values from 01
to 99, so if ORDER = 55, then i chose VARIA55.

The question is how to make this without using a EVALUATE or IF
statement ?

I hope you understand....sorry for my bad english.....

Cheers

Richard

2006-07-04, 6:55 pm

jferreira80@gmail.com wrote:

> supose that i have 99 variables loaded by a SQL statement, with names
> VARIAxx where xx is 01 to 99.
> supose other variable ORDER with a xx value, again with values from 01
> to 99, so if ORDER = 55, then i chose VARIA55.
>
> The question is how to make this without using a EVALUATE or IF
> statement ?

You have them as a table:

01 All-the-Vars.
03 Varia01 PIC X(20).
03 Varia02 PIC X(20).
...
03 Varia99 PIC X(20).
01 All-as-table REDEFINES All-the-Vars.
03 Varia OCUURS 99 PIC X(20).

MOVE Varia(Order) TO ....

Of course all the VariaXX need to be identical in having the same
PICture else they won't match the alignment of the table. If they need
to be different types of data then this can be done by packing each
VariaXX out to the same size and having another table (or another field
in the table) that indicates the actual type:

01 All-the-Vars.
03 Varia01-Type PIC X VALUE "X".
03 Varia01 PIC X(20).
03 Varia02-Type PIC X VALUE "N".
03 Varia02 PIC S9(8)V99.
03 FILLER PIC X(10). *> packing to
20 characters
03 Varia03-Type PIC X VALUE "D".
03 Varia03 PIC X(10). *> format
2006-07-05
03 FILLER PIC X(10). *> packing to
20 characters
...
03 Varia99-Type PIC X VALUE "X".
03 Varia99 PIC X(20).
01 All-as-table REDEFINES All-the-Vars.
03 Varia-Item OCCURS 99.
05 Varia-Type PIC X.
05 Varia-X PIC X(20).
05 Varia-N-Item REDEFINES Varia-X.
07 Varia-N PIC S9(8)V99.
07 FILLER PIC X(10).
etc

IF ( Varia-Type(Order) = "X" )
MOVE Varia-X(Order) TO ....
ELSE
IF ( Varia-Type(Order) = "N" )
MOVE Varia-N(Order) TO ....
ELSE
etc

Pete Dashwood

2006-07-04, 9:55 pm

<jferreira80@gmail.com> wrote in message
news:1152052290.777938.169490@m79g2000cwm.googlegroups.com...
> Hi,
>
> I have a little question...
>
I have posted a little answer further down... :-)

> supose that i have 99 variables loaded by a SQL statement, with names
> VARIAxx where xx is 01 to 99.
> supose other variable ORDER with a xx value, again with values from 01
> to 99, so if ORDER = 55, then i chose VARIA55.
>
> The question is how to make this without using a EVALUATE or IF
> statement ?
>
> I hope you understand....sorry for my bad english.....
Your English was perfectly adequate for this task; thank you for using it.
>
> Cheers
>
Richard has already provided what is arguably the best solution, but I just
didn't want the possibility below to be overlooked either... :-)

go to
use-VARIA01
use-VARIA02
use-VARIA03
use-VARIA04
....
use-VARIA98
use-VARIA99
depending on ORDER

HeyBub

2006-07-05, 6:55 pm

Pete Dashwood wrote:

> Richard has already provided what is arguably the best solution, but
> I just didn't want the possibility below to be overlooked either...
> :-)
> go to
> use-VARIA01
> use-VARIA02
> use-VARIA03
> use-VARIA04
> ...
> use-VARIA98
> use-VARIA99
> depending on ORDER
> .
> order-was-invalid.
> (Code to deal with ORDER NOT being between 01 and 99)
> use-VARIA01.
> (Code to deal with ORDER being = 01 and VARIA01 being
> used... eg. move VARIA01 to something
> perform VARIA01-process
> ...whatever...
> go to end-of-VARIA-selection
> use-VARIA02.
> (Code to deal with ORDER being = 02 and VARIA02 being
> used... eg. move VARIA02 to something
> perform VARIA02-process
> ...whatever...
> go to end-of-VARIA-selection
> use-VARIA03.
> (Code to deal with ORDER being = 03 and VARIA03 being
> used... eg. move VARIA03 to something
> perform VARIA03-process
> ...whatever...
> go to end-of-VARIA-selection
> ...and so on...
> use-VARIA99.
> (Code to deal with ORDER being = 99 and VARIA99 being
> used... eg. move VARIA99 to something
> perform VARIA99-process
> ...whatever...
> .
> end-of-VARIA-selection.
> Program logic continues...
>
>

Arghhh! My brain exploded!

That's like using Arsenic to cure syphilis! Admittedly, it'll work (if it
doesn't kill you), but...

Abstinence is the answer.

2006-07-05, 6:55 pm

In article <12anigcstk8k5cd@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>Pete Dashwood wrote:
>

[snip]
[color=darkred]
>Arghhh! My brain exploded!
>
>That's like using Arsenic to cure syphilis! Admittedly, it'll work (if it
>doesn't kill you), but...
>
>Abstinence is the answer.

Abstinence might be an answer to reducing the spread of syphilis but it
doesn't seem to do much to cure it.

DD

Howard Brazee

2006-07-05, 6:55 pm

On Wed, 5 Jul 2006 14:22:08 +0000 (UTC), docdwarf@panix.com () wrote:

>
>Abstinence might be an answer to reducing the spread of syphilis but it
>doesn't seem to do much to cure it.

Are you implying that abstaining as an answer is not an answer at all?

2006-07-05, 6:55 pm

In article <3ljna2lql1d024075htcogrqosuf28ufsd@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Wed, 5 Jul 2006 14:22:08 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>Are you implying that abstaining as an answer is not an answer at all?

Implication is in the mind of the beholder, Mr Brazee... what I stated
that abstinence might be is included in your cite of my posting, above.

DD

Michael Mattias

2006-07-05, 6:55 pm

<docdwarf@panix.com> wrote in message news:e8ghug$jf9$1@reader2.panix.com...
> Abstinence might be an answer to reducing the spread of syphilis but it
> doesn't seem to do much to cure it.

For sure it didn't cure Al Capone.

MCM

Alistair

2006-07-05, 6:55 pm

HeyBub wrote:
>
> Arghhh! My brain exploded!
>
> That's like using Arsenic to cure syphilis! Admittedly, it'll work (if it
> doesn't kill you), but...
>

Do you have any references for the use of arsenic? I know that mercury
was used to cure syphilis but not arsenic. A quick browse of the
wikipedia entry ignores both treatments, promulgates one myth (that
syphilis is spread by sexual contact; the most common spread for
syphilis is the sharing of cutlery) and fails to resolve the origin of
the disease (Colombian or pre-Colombian).

Alistair

2006-07-05, 6:55 pm

In article <1152114423.098735.114900@a14g2000cwb.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>HeyBub wrote:
>
>Do you have any references for the use of arsenic?

I know by heart the names of Ehrlich and Salversan (compound 606)... but a
bit of web-work came up with
<http://www.ibms.org/index.cfm?metho..._liebigs_legacy>

--begin quoted text:

Therefore, there was a need for drugs with a selective action, and it was
here that Pasteur and Koch, and Ehrlich (who found that dyes could stain
organisms), came into the picture. Salversan, a compound containing two
arsenic atoms, was found to be active against syphilis.

--end quoted text

DD

Robert Jones

2006-07-05, 6:55 pm

>
> Abstinence is the answer.

can you abstain from using computers without branches and jumps?

Robert

Michael Mattias

2006-07-05, 6:55 pm

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1152126157.947009.296320@v61g2000cwv.googlegroups.com...
>
> can you abstain from using computers without branches and jumps?

Damn it. Now you've made me dig out something I wrote more than twelve
years ago...

(Be gentle, I was still on the Zoloft at this time).

MCM

SAFE MICROSOFT: WHEN ABSTINENCE DOESN'T WORK
By Michael Mattias

I recently participated in a message thread in one of the programming
forums here on CompuServe. That thread ended with one of the participants
very upset with MicroSoft, and urging fellow forum members to avoid that
firm. He used this battle cry:

" Uppity programmers unite....Just say no to MS!"

Well, I read that, and just had to reply:

========================================
============================
Just Say No?

Abstinence from MS?

C'mon, everyone knows that abstinence doesn't work. We're all going
to use MS, no matter how much we resist, or how hard we try to wait
until we are truly ready.

I've got a better idea: Practice "safe" MS instead. Never use MS
without a write-protect tab!

For the longest time, write-protect tabs were taboo - to the point
where no one would even use the word. Even today, who actually says
"write-protect-tab" on TV? No one!

A massive education campaign is in order. We could run TV spots like
this:

[Boy and Girl arrive at PC together, breathless with anticipation].

She: "Did you bring it?"

He: "Er, no, I forgot it."

She: "Well, then forget it! You're not running MS on my
computer without using a write-protect tab!"

Be honest - if we are going to teach our children how to write to
floppy disks, don't we owe it to them to educate them in the use of
write-protect tabs?

We taught them what to do at the keyboard - now we must teach them
what to do at the disk drive door.

If our education program doesn't get the message across, we can take
direct action: we can distribute free write-protect tabs in our schools.

Besides, write-protect tabs curb the spread of disk-transmitted
computer viruses, and reduce the number of unplanned diskettes.

So get with the times. Sure it's best to avoid MS until you are
really
ready, but if you can't, practice safe MS: Use a write-protect tab!

MCM
========================================
===============================

Michael C. Mattias, Glendale Heights, IL. CIS:72030,3563
February, 1994.

HeyBub

2006-07-05, 6:55 pm

Alistair wrote:
> HeyBub wrote:
>
> Do you have any references for the use of arsenic? I know that mercury
> was used to cure syphilis but not arsenic. A quick browse of the
> wikipedia entry ignores both treatments, promulgates one myth (that
> syphilis is spread by sexual contact; the most common spread for
> syphilis is the sharing of cutlery) and fails to resolve the origin of
> the disease (Colombian or pre-Colombian).

"Salvarsan," a compound of Arsenic, was first used in 1909 and remained the
most popular remedy well into the 1940's. It was developed by the same chap
who discovered the cures for Diptheria and sleeping sickness (among others).
He also won the 1906 Nobel Prize for Medicine.

I can tell you never had syphilis before 1940.

HeyBub

2006-07-05, 6:55 pm

Robert Jones wrote:
>
> can you abstain from using computers without branches and jumps?
>
> If you can abstain without branches and jumps in sex, you can do so in
> COBOL.

Pete Dashwood

2006-07-05, 6:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12anigcstk8k5cd@news.supernews.com...
> Pete Dashwood wrote:
>
>
> Arghhh! My brain exploded!
>
> That's like using Arsenic to cure syphilis! Admittedly, it'll work (if it
> doesn't kill you), but...
>
> Abstinence is the answer.
>

Given that your brain exploded it was obviously trying to expand enough to
embrace a concept that is "outside the square", at least, for you :-).

"Everybody knows" go to is bad. But is it ALWAYS?

Personally, I see no problem with the above code (I wouldn't have posted it
if I did) and would maintain it easily if I came across it in someone else's
program. From a style point of view, it is old fashioned, that's all.

Given that it has no problem with maintainability, is extremely efficient,
and flexible in what it allows, what exactly is the objection? It contains
"GO TO". Are we so conditioned that our minds stop working when we encounter
this in code?

But, don't listen to me... I reckon ALTER is OK too (when used under
specific circumstances and clearly documented). :-)

Or maybe syphilis has corrupted my thought process... (I never knew about
the arsenic...:-))

Pete.

Alistair

2006-07-06, 7:55 am

HeyBub wrote:
> Alistair wrote:
>
> "Salvarsan," a compound of Arsenic, was first used in 1909 and remained the
> most popular remedy well into the 1940's. It was developed by the same chap
> who discovered the cures for Diptheria and sleeping sickness (among others).
> He also won the 1906 Nobel Prize for Medicine.
>
> I can tell you never had syphilis before 1940.

I wasn't even a twinkle in my father's eye before 1957. I shall
overlook the implied slur, :-( , that I may have contracted
syphilis after 1940 (I have, so far, avoided contact with all STDs.)

2006-07-06, 7:55 am

In article <1152192660.039252.169540@s26g2000cwa.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>HeyBub wrote:

[snip]

>
>I wasn't even a twinkle in my father's eye before 1957. I shall
>overlook the implied slur, :-( , that I may have contracted
>syphilis after 1940 (I have, so far, avoided contact with all STDs.)

Mr Maclean, I believe it was Hippocrates of Kos who degraded the labelling
of epilepsy as 'the sacred sickness', pointing out that an illness was an
illness, none more sacred and none more profane than any other.

DD

HeyBub

2006-07-06, 6:55 pm

docdwarf@panix.com wrote:
> In article <1152192660.039252.169540@s26g2000cwa.googlegroups.com>,
> Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
> [snip]
>
>
> Mr Maclean, I believe it was Hippocrates of Kos who degraded the
> labelling of epilepsy as 'the sacred sickness', pointing out that an
> illness was an illness, none more sacred and none more profane than
> any other.

Times change.

"I will neither give a deadly drug to anybody who asked for it, nor will I
make a suggestion to this effect. Similarly I will not give to a woman an
abortive remedy."

2006-07-06, 6:55 pm

In article <12aq6j84ip4rtc0@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>docdwarf@panix.com wrote:
>
>Times change.

This was not, I believe, argued.

>
>"I will neither give a deadly drug to anybody who asked for it, nor will I
>make a suggestion to this effect. Similarly I will not give to a woman an
>abortive remedy."

Neither of these were, I believe, suggested. Are you s

ing to apply
some sort of 'falsus in unum, falsus in omnia' to such matters?

DD

HeyBub

2006-07-06, 6:55 pm

docdwarf@panix.com wrote:
>
> This was not, I believe, argued.
>
>
> Neither of these were, I believe, suggested. Are you s

ing to apply
> some sort of 'falsus in unum, falsus in omnia' to such matters?

No, I was simply pointing out that, unlike some Episcopalians, it's really
not fair to pick what parts have merit and ignore the others all the while
claiming reverence for the source.

Michael Wojcik

2006-07-06, 6:55 pm

In article <4h2vdgF1pa9voU1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> writes:
>
> "Everybody knows" go to is bad. But is it ALWAYS?

I've often argued in comp.lang.c that there are a number of cases
where goto is the most appropriate control structure in C programs.
It's very useful for single-point-of-return, for example, which is an
idiom that can be very useful for robust resource control, especially
since C lacks exceptions.

When Dijkstra kicked off the "goto wars" with "Go To Statement
Considered Harmful", he was actually making the rather more nuanced
point that more-specific control structures (still something of a
novelty for mainstream programming at the time) had advantages over
goto in most cases. Unfortunately the editor of CACM decided to
print his letter with a flame-bait title of his own invention, and so
polarized what should have been an uncontroversial issue.[1]

There *are* good reasons to avoid goto in most circumstances; its
flow of control is less clear than more-specific structures, and it
inhibits some optimizations, for example. But those who prefer
reason to dogma recognize that there are few tools that are never
the right choice.

(Now, all that said, I don't know that HeyBub was objecting
specifically to your use of GO TO, and I'm not arguing for or against
your specific use of GO TO here - just offering an opinion on the
general point.)

1. See for example David R. Tribble's excellent "Go To Statement
Considered Harmful: A Retrospective",
http://david.tribble.com/text/goto.html.

--
Michael Wojcik michael.wojcik@microfocus.com

However, we maintain that our mission is more than creating high-tech
amusement--rather, we must endeavor to provide high-tech, high-touch
entertainment with an emphasis on enkindling human warmth.
-- "The Ultimate in Entertainment", from the president of video game
producer Namco

Richard

2006-07-06, 6:55 pm

Michael Wojcik wrote:

> I've often argued in comp.lang.c that there are a number of cases
> where goto is the most appropriate control structure in C programs.
> It's very useful for single-point-of-return, for example, which is an
> idiom that can be very useful for robust resource control, especially
> since C lacks exceptions.

I have previously opined that the problem with gotos isn't the goto
itself, which is entirely clear as to its action, but the label that is
required. Given some code with a label in it, and that there may be
gotos in the program, it is impossible to know the flow of control
around that label with searching the whole program.

> (Now, all that said, I don't know that HeyBub was objecting
> specifically to your use of GO TO, and I'm not arguing for or against
> your specific use of GO TO here - just offering an opinion on the
> general point.)

The C switch statement could generate a jump table to its case labels
and this would be just like a GO TO DEPENDING ON. The difference would
be that the switch _must_ have all its labels in scope and the end
point of the flow is contrained to be the end of the switch block. Even
though one may forget a break it can only be a 'single-point-of-return'
structure. The problem with GO TO is that there is no such constraint.
It doesn't _have_ to jump to the designated point of return, and that
label can be jumped to from anywhere.

As designed by PECD, the GO TO DEPENDING ON is a useful and easy
structure, but there is nothing in the compiler or other tools that
will enforce this design.

I did propose a scheme to J4 some time ago that added qualifiers to
labels that could be used to enforce rules about the usage of labels.
For example if a section could be marked that only local go tos could
be used, ie to labels within the section, then this would simplify the
determining of flow. If labels could be marked so they could only be
used as a target of GOTO and not of a perform or drop-thru then more
bugs could be eliminated by the compiler.

Until such time I will use a scheme that I can verify. I can use text
tools to check that there are no use of keywords SECTION, THRU, GO TO,
ALTER, NEXT SENTENCE, EXIT PARAGRPH, ... in the PD, a simple
examination of the first paragraph will then show me all I need to know
about logic flow in every paragraph.

It isn't that GOTO is bad, but its presence in a program potentially
increases the complexity by an order of magnitude compared to the
simplest possible structure. I write code that is not positionally
dependent and this allows me to shuffle code around and reuse it
without having to do a range of checks that would make the tasks
several times longer to achieve.

Howard Brazee

2006-07-07, 7:55 am

On 6 Jul 2006 21:50:26 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>When Dijkstra kicked off the "goto wars" with "Go To Statement
>Considered Harmful", he was actually making the rather more nuanced
>point that more-specific control structures (still something of a
>novelty for mainstream programming at the time) had advantages over
>goto in most cases. Unfortunately the editor of CACM decided to
>print his letter with a flame-bait title of his own invention, and so
>polarized what should have been an uncontroversial issue.[1]

Without that title, we wouldn't have had the controversy and publicity
needed to get the discussion that was warranted.

Frank Swarbrick

2006-07-07, 6:55 pm

Richard<riplin@Azonic.co.nz> 07/06/06 6:07 PM >>>
>
>Until such time I will use a scheme that I can verify. I can use text
>tools to check that there are no use of keywords SECTION, THRU, GO TO,
>ALTER, NEXT SENTENCE, EXIT PARAGRPH, ... in the PD, a simple
>examination of the first paragraph will then show me all I need to know
>about logic flow in every paragraph.

I still don't understand your resistance to "EXIT PARAGRAPH". Take the
following three examples:

**************************************
* Example 1
CALCULATE-INTEREST.
IF INTEREST-BEARING
* 50 lines of code here
END-IF

Richard

2006-07-07, 9:55 pm

Frank Swarbrick wrote:

> I still don't understand your resistance to "EXIT PARAGRAPH". Take the
> following three examples:

Overly simplistic code designed to not show any problem do not
illustrate where the problems lie.

If I have:

> **************************************
> * Example 1
> CALCULATE-INTEREST.
> IF INTEREST-BEARING
> * 30 lines of code here
* blockA
IF ( something obscure )
15 lines of code
IF ( enough done )
EXIT PARAGRAPH
END-IF
some other lines of code
END-IF
> * 20 lines of code here
> END-IF
> .
> **************************************

If I want to reuse the code blockA or simply move it to another
paragraph and perform it because it is too deeply nested or something
then the exit is of the _WRONG_PARAGRAPH_.

> **************************************
> * Example 1
> CALCULATE-INTEREST.
> IF INTEREST-BEARING
> * 30 lines of code here
PERFORM Block-A
> * 20 lines of code here
> END-IF
> .
> **************************************

Block-A
IF ( something obscure )
15 lines of code
IF ( enough done )
EXIT PARAGRAPH
END-IF
some other lines of code
END-IF

Frank Swarbrick

2006-07-08, 3:55 am

Richard<riplin@Azonic.co.nz> 07/07/06 1:15 PM >>>
>
>Frank Swarbrick wrote:
>
>
>Overly simplistic code designed to not show any problem do not
>illustrate where the problems lie.

Touche'!

>If I have:
>
> * blockA
> IF ( something obscure )
> 15 lines of code
> IF ( enough done )
> EXIT PARAGRAPH
> END-IF
> some other lines of code
> END-IF
>
>If I want to reuse the code blockA or simply move it to another
>paragraph and perform it because it is too deeply nested or something
>then the exit is of the _WRONG_PARAGRAPH_.
>
> PERFORM Block-A
>
> Block-A
> IF ( something obscure )
> 15 lines of code
> IF ( enough done )
> EXIT PARAGRAPH
> END-IF
> some other lines of code
> END-IF
> .
>
>The code following the PERFORM Block-A is now incorrectly executed.
>
>I do not use anything which has positional significance. In this case
>the EXIT PARAGRAPH _must_ be positioned in the Calcualte-Interest
>paragraph.

I see your point. And in fact have run in to it before. But I've never
actually found a solution that I am happy with. At least not in COBOL.

Take, for example, a slight reworking of your example so that it does (I
think!) function correctly.

CALCULATE-INTEREST.
IF INTEREST-BEARING
30 lines of code here
PERFORM Block-A
IF NOT DONE
20 lines of code here
END
END-IF

Richard

2006-07-08, 7:55 am

Frank Swarbrick wrote:

> Take, for example, a slight reworking of your example so that it does (I
> think!) function correctly.
>
> CALCULATE-INTEREST.
> IF INTEREST-BEARING
> 30 lines of code here
> PERFORM Block-A
> IF NOT DONE
> 20 lines of code here
> END
> END-IF
> .
>
> Block-A
> IF ( something obscure )
> 15 lines of code
> IF ( enough done )
> SET DONE TO TRUE
> ELSE
> some other lines of code
> END-IF
> END-IF
> .
>
> Now we have an annoying extra switch. I hate them. (Not that I don't use
> them often; I do, which is why I hate them!)

Yes, but that is _your_ switch, not mine. You added the switch to
overcome the problem with the code that did an early exit. If the code
had originally been written without the EXIT PARAGRAPH then it would
have had to have been coded differently and would not require a kluge
to get around the problem.

> Since the "20 lines of code" are always executed after Block-A is performed,
> shouldn't block A just have those 20 lines in it. Or, perhaps better yet,
> put those 20 lines yet another paragraph and have Block-A perform it.

I may have done something that way if I had written it, yes.

> Don't you mean:
> Calculate-Interest.
> IF (Interest-Bearing )
> 50 lines of code or perform of some calculation
> ELSE
> MOVE ZERO TO Interest-Total
> END-IF
> .

I'm not frightened by negative tests. However I don't use 88 levels so
what I actually would do is probably more like:

IF ( Interest-Rate = ZERO )
MOVE ZERO TO ...
ELSE
....

> My issue with that, and I'll grant it's minor, is that I don't like the
> "main stream" of code in a paragraph to be (what I consider to be)
> unnecessarily indented.

I'm not frightened of indenting code. Pre-ANS85 one needed to keep the
indenting down because a full stop was required to end scope. It
became too clumsy to handle nested structures. Now that I only use one
full stop per paragraph I can code any number of indent levels, and if
I need to access the same code from several places or reduce the indent
level I can _any_ imperitive statement (a properly scope terminated
block of code) and shift it to a new paragraph to be performed.

I don't have to check the code for positional dependencies, or recode
with switches, I can just mark the block and move it.

> Anyway, I will once again say that I see your point, and even agree with it
> for the reasons you give. But I'm still not convinced that EXIT PARAGRAPH

That's OK, you prefer your code, I prefer mine. I used to code with
early exits in the pre-85 style. Slowly as I changed I realised the
benefits of restricting the number of different structures used (see
Python for a language that does this for you) but it is not until there
is a complete change that any benefits arise.

That is: if there is any possibility of a GOTO, EXIT PARAGRAPH,
dropthru, THRU, ... then you _have_ to do _all_ the checking. If there
is no possibility of these in the program then suddenly half the work
of coding is just gone, many of the bugs just don't occur. But it
requires that there is _no_ possibility.

> (or in C and Java, return as other than the last statement of a
> function/method) should never be used.

I don't use early return in other languages either.

In C switches, break is required at the end of each case. I would
prefer the Cobol EVALUATE mechanism, but that won't happen so I use
break. More often I will code if .. else if .. else if .. rather than
a switch because that is how Python does it - it deliberately does not
have a switch/case statement.

HeyBub

2006-07-08, 7:55 am

Frank Swarbrick wrote:
> **************************************
> * Example 3
> CALCULATE-INTEREST.
> IF NOT INTEREST-BEARING
> EXIT PARAGRAPH
> END-IF
> * 50 lines of code here
> .
> **************************************
>
> Which is your preference, and why? Number 3 is my preference. There
> is, of course, a number four, which assumes that CALCULATE-INTEREST
> will never be called for a non-interest bearing account. This is of
> course absolutely valid. But if CALCULATE-INTEREST is performed from
> several different places then each place has to have "IF
> INTEREST-BEARING PERFORM CALCULATE-INTEREST END-IF", which I like to
> avoid when possible.

Hey, whatsamatter with:

CALCULATE-INTEREST.
IF NOT INTEREST-BEARING
GO TO CALCULATE-INTEREST-EXIT
END-IF
*> 50 lines of code here
CALCULATE-INTEREST-EXIT.
EXIT.

I've got to have a lie-down.

Richard

2006-07-08, 7:55 am

HeyBub wrote:

> Hey, whatsamatter with:

Nothing, until someone codes:

PERFORM Calculate-Interest

which works perfectly on all test data and live data because all
accounts are marked as being interest bearing.

Pete Dashwood

2006-07-09, 3:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1152318164.228541.99210@m73g2000cwd.googlegroups.com...
>
> HeyBub wrote:
>
>
> Nothing, until someone codes:
>
> PERFORM Calculate-Interest
>
> which works perfectly on all test data and live data because all
> accounts are marked as being interest bearing.
>

Absolutely. That's one reason why I use SECTION with a single exit point,
but we don't want to start those wars again... :-)

Pete.

HeyBub

2006-07-09, 6:55 pm

Richard wrote:
> HeyBub wrote:
>
>
> Nothing, until someone codes:
>
> PERFORM Calculate-Interest
>
> which works perfectly on all test data and live data because all
> accounts are marked as being interest bearing.

A good programmer would have anticipated that about which you are worried
and included the comment:

*> WARNING: Do not PERFORM the CALCULATE-INTEREST paragraph.

See how easy it is to prevent blunders.

Richard

2006-07-09, 6:55 pm

HeyBub wrote:

> A good programmer would have anticipated that about which you are worried
> and included the comment:
>
> *> WARNING: Do not PERFORM the CALCULATE-INTEREST paragraph.
>
> See how easy it is to prevent blunders.

A good programmer would have created a structure in which such mistakes
could not be made. A poor programmer will disclaim responsibility with
'you should have read the comment'.

The point that I am trying to make is that it is possible to write
programs in a way that does not need these type of comments, does not
need the overhead of checking the code in this way, and does not give
these types of bugs. It may take a few seconds longer to construct the
code but it saves time of: writing the comment; having to check every
perform to see if there is a comment, or whether it hadn't been added;
finding the bugs.

A good compiler would have flagged the code, but cobol won't do that,
so until it does I will use code that doesn't need compiler checking.

Richard

2006-07-09, 6:55 pm

Pete Dashwood wrote:

> Absolutely. That's one reason why I use SECTION with a single exit point,

The problem that I have with SECTION is that there is no mechanism that
will automatically check that the word 'SECTION' was accidentally
omitted. There is no 'grep' that will find the places where section
should be but isn't. The compiler won't tell me. Granted that one
could write a program to do such checks.

A program that has the word 'section' missing may well appear to work
correctly until one day there is something that causes it to take the
'goto'.

> but we don't want to start those wars again... :-)

It isn't a war, I am not trying to invade your code and change it or
send it off to Siberia. I am merely explaining why I write code the
way I do.

(and why I would send yours off to Siberia if it tried to invade me).

HeyBub

2006-07-09, 6:55 pm

Richard wrote:
> HeyBub wrote:
>
>
> A good programmer would have created a structure in which such
> mistakes could not be made. A poor programmer will disclaim
> responsibility with 'you should have read the comment'.

In the alternative, a good programmer could assume that he will be followed
by another good programmer. Heck, I once wrote a subroutine in FORTRAN
wherein each variable was a different number of dollar-signs, viz:

$$ = (SQRT($$$ + $$))**$

Nary a grumble. 'Course I left the company shortly thereafter (it was all a
big misunderstanding coupled with a complete inability of some -- in
positions of authority -- to see the humor in a situation involving the
departmental secretary and a jar of mayonnaise).

>
> The point that I am trying to make is that it is possible to write
> programs in a way that does not need these type of comments, does not
> need the overhead of checking the code in this way, and does not give
> these types of bugs.

> It may take a few seconds longer to construct
> the code

Counts against my productivity.

> but it saves time of: writing the comment; having to check
> every perform to see if there is a comment, or whether it hadn't been
> added; finding the bugs.

Does not count against my productivity.

Hmm. Which should I do?

>
> A good compiler would have flagged the code, but cobol won't do that,
> so until it does I will use code that doesn't need compiler checking.

Richard

2006-07-09, 9:55 pm

HeyBub wrote:

> In the alternative, a good programmer could assume that he will be followed
> by another good programmer.

Actually a bad programmer will assume that no other programmer will
ever need to follow. A good programmer will not need to have another
programmer follow, but will ensure that if another programmer does then
there is no requirement for them to be 'good' is any specific way.

> Heck, I once wrote a subroutine in FORTRAN
> wherein each variable was a different number of dollar-signs, viz:
>
> $$ = (SQRT($$$ + $$))**$

Excuse me but are you presenting this as an example of what a _good_
programmer would do ?

>
> Counts against my productivity.
>
>
> Does not count against my productivity.
>
> Hmm. Which should I do?

Convince the ones who pay the bills that they are measuring the wrong
things.

I once heard of a site where productivity was measured by LoC per hour.

Instead of:

PERFORM Add-table VARYING ... UNTIL .. > Table-Limit

They would code:

MOVE ZERO TO Table-Total
IF ( Table-Limit > 0 )
ADD Table-item(1) TO Table-Total.
IF ( Table-Limit > 1 )
ADD Table-item(2) TO Table-Total.

Huge productivity, therfore must be a 'good' programmer.

HeyBub

2006-07-09, 9:55 pm

Richard wrote:
>
>
> Excuse me but are you presenting this as an example of what a _good_
> programmer would do ?
>

Well, yes... A good programmer (me) did it.

Are you implying a good programmer would not do such a thing?

Another good programmer -- at the same shop -- wrote a wonderful utility
subroutine named PHUQED. A common solution became "You need to get PHUQED."

Then there was the day we all came to work wearing clown shoes...

Richard

2006-07-10, 3:55 am

HeyBub wrote:

>
> Well, yes... A good programmer (me) did it.
>
> Are you implying a good programmer would not do such a thing?

When people refer to 'the good shepherd' they aren't discussing the
quality of the mutton. It seems that you may be using 'good' in this
way, because it certainly isn't the way I am using it.

> Then there was the day we all came to work wearing clown shoes...

That seems to fit.

Pete Dashwood

2006-07-10, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1152485114.193334.206870@m79g2000cwm.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
> The problem that I have with SECTION is that there is no mechanism that
> will automatically check that the word 'SECTION' was accidentally
> omitted. There is no 'grep' that will find the places where section
> should be but isn't. The compiler won't tell me. Granted that one
> could write a program to do such checks.
Or one could take care to write code that is correct... :-)

I have used SECTION for over 30 years and NEVER encountered the error you
describe, due to missing keyword.

I make sure I think of the code as a SECTION and the SECTION keyword
follows as the night the day...

Having said that, I think your point is fair, Richard. It COULD be a cause
fo error if it was omitted.

>
> A program that has the word 'section' missing may well appear to work
> correctly until one day there is something that causes it to take the
> 'goto'.
>
>
> It isn't a war, I am not trying to invade your code and change it or
> send it off to Siberia. I am merely explaining why I write code the
> way I do.

Fair enough. My comment was directed to the forum in general...:-)

>
> (and why I would send yours off to Siberia if it tried to invade me).
>

That would never happen; my code is peaceful... :-)

Pete.
>

Pete Dashwood

2006-07-10, 7:55 am

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12b3gh0hmccpv80@news.supernews.com...
> Richard wrote:
>
> Well, yes... A good programmer (me) did it.
>
> Are you implying a good programmer would not do such a thing?
>
> Another good programmer -- at the same shop -- wrote a wonderful utility
> subroutine named PHUQED. A common solution became "You need to get
> PHUQED."
>
> Then there was the day we all came to work wearing clown shoes...
Are there any vacancies on your site, Jerry? Sounds like my kinda place...
:-)

Pete.

Pete Dashwood

2006-07-10, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1152506636.466079.32250@m79g2000cwm.googlegroups.com...
>
> HeyBub wrote:
>
>
> When people refer to 'the good shepherd' they aren't discussing the
> quality of the mutton. It seems that you may be using 'good' in this
> way, because it certainly isn't the way I am using it.
>
>
> That seems to fit.
>
Only the ones who had big feet... right? :-)

Pete

Howard Brazee

2006-07-10, 7:55 am

On Fri, 7 Jul 2006 16:16:41 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>I see your point. And in fact have run in to it before. But I've never
>actually found a solution that I am happy with. At least not in COBOL.

Agreed. The main advantage of EXIT PARAGRAPH (which isn't available
at my shop), is when I am maintaining code with good reason to make as
small of a change as reasonable.

Restructuring is not what I am being paid for. But the new
condition needs to be checked for, and the rest of the paragraph needs
to be bypassed. There are lots of ways to do this, but the minimal
impact way with the least amount of confusion for the next programmer
is called for.

Howard Brazee

2006-07-10, 7:55 am

On 9 Jul 2006 15:45:14 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>The problem that I have with SECTION is that there is no mechanism that
>will automatically check that the word 'SECTION' was accidentally
>omitted. There is no 'grep' that will find the places where section
>should be but isn't. The compiler won't tell me. Granted that one
>could write a program to do such checks.
>
>A program that has the word 'section' missing may well appear to work
>correctly until one day there is something that causes it to take the
>'goto'.

Sections have drop-throughs. Add a paragraph to the end of your
program and it is part of a section.

PERFORM THRUs are almost as dangerous.

HeyBub

2006-07-10, 6:55 pm

Pete Dashwood wrote:
> Only the ones who had big feet... right? :-)

No, not really. Had you seen the crop of females working for a Geophysical
Survey company, there was no need to claim large, er, feet.

In addition, included in the crowd were those who, for reasons passing
understanding, had an almost clinical aversion to toenail-clipping. I think
there was one guy who was shooting for a mention in Guiness...

One day the programming staff returned from a company-wide meeting with our
hands on our heads.

Then there was the "Hawaiian-shirt day."

Michael Wojcik

2006-07-10, 6:55 pm

In article <1152230851.587557.254180@s13g2000cwa.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
> Michael Wojcik wrote:
>
>
> I have previously opined that the problem with gotos isn't the goto
> itself, which is entirely clear as to its action, but the label that is
> required. Given some code with a label in it, and that there may be
> gotos in the program, it is impossible to know the flow of control
> around that label with searching the whole program.

In COBOL, true, but not in C, where the scope of a label is the
enclosing function.

> ... The problem with GO TO is that there is no such constraint.
> It doesn't _have_ to jump to the designated point of return, and that
> label can be jumped to from anywhere.

I take your point, and I agree that this is one of the cases where a
language feature can easily be abused; but I prefer to recommend
against abuse rather than proscribing it entirely.

Obviously that doesn't help when we wish to read a program that *does*
abuse GO TO, but then neither does proscribing it.

I do agree that a mechanism for restricting the scope of labels to
something smaller than a program would be useful.

--
Michael Wojcik michael.wojcik@microfocus.com

[G]ood terrorist ideas are a dime a dozen. Anyone can figure out how
to cause terror. -- Bruce Schneier

Michael Wojcik

2006-07-10, 6:55 pm

In article <a9nsa2dq7ecrjpi9r0447i7dldejeg5iqc@4ax.com>, Howard Brazee <howard@brazee.net> writes:
> On 6 Jul 2006 21:50:26 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> Without that title, we wouldn't have had the controversy and publicity
> needed to get the discussion that was warranted.

Perhaps, but I am not persuaded. There are plenty of religious wars,
and even more productive discussions, that were launched without such
rhetorical flourish.

--
Michael Wojcik michael.wojcik@microfocus.com

Richard

2006-07-10, 6:55 pm

Michael Wojcik wrote:

> In COBOL, true, but not in C, where the scope of a label is the
> enclosing function.

That's probably true but I never needed to know that having never used
goto in C.

> Obviously that doesn't help when we wish to read a program that *does*
> abuse GO TO, but then neither does proscribing it.

The problem is knowing whether it does abuse GO TO or not, and whether
that is deliberate or accidental. If there _is_ a GO TO anywhere then
one has to check that there is no abuse.

It is similar to when there was an ALTER in the program. No GO TO could
ever be trusted until the whole program was checked, and then those
paragraphs referenced could never be trusted at any time.

Get rid of the ALTER and days of checking just disappears, those checks
are just not needed anymore. Get rid of GO TO, SECTION, THRU, and EXIT
...., and another chunk of code checking is just not needed.

> I do agree that a mechanism for restricting the scope of labels to
> something smaller than a program would be useful.

Not only the scope but also the usage. In C a function cannot be
dropped into, it can only be executed, a label can only be the target
of a goto (implied in a switch). If labels could be designated as only
a target of perform (no drop thru or goto) or only the target of a goto
(no drop thru or perform) then many types of errors could be found by
the compiler.

Pete Dashwood

2006-07-10, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:n7m4b2p8ontn272al54abo0p8obj0m7c25@
4ax.com...
> On 9 Jul 2006 15:45:14 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
> Sections have drop-throughs.

Mine don't.

> Add a paragraph to the end of your
> program and it is part of a section.
>
Why would I add ANYTHING to ANY section (never mind the last one in the
source) that WASN'T part of that section?

I wouldn't, I haven't, and I don't.

Please note I am not advocating that everyone should use sections. All I am
saying is that it works for me. I have never encountered the potential
problems described by you and Richard. Sectioning certainly eliminates the
original problem with the solution posted by HeyBub.

> PERFORM THRUs are almost as dangerous.

Code is only 'dangerous' when it is improperly understood, written by
somebody who improperly understands it, or written carelessly. All
programming is 'dangerous' if you do not take care with it.

Pete.

2006-07-10, 6:55 pm

In article <4hfuk4F1pbhe4U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>Code is only 'dangerous' when it is improperly understood, written by
>somebody who improperly understands it, or written carelessly. All
>programming is 'dangerous' if you do not take care with it.

All (objects) are (color) unless a successful attempt is completed to make
them (another color)... wow, how profound!

DD

Pete Dashwood

2006-07-11, 7:55 am

<docdwarf@panix.com> wrote in message news:e8um63$90l$1@reader2.panix.com...
> In article <4hfuk4F1pbhe4U1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> All (objects) are (color) unless a successful attempt is completed to make
> them (another color)... wow, how profound!
>
> DD
>
Well, it needed to be said... :-)

Pete

Howard Brazee

2006-07-11, 7:55 am

On Tue, 11 Jul 2006 09:20:03 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

[color=darkred]
>Mine don't.

As long as someone else doesn't touch them. (Since an EXIT paragraph
is a drop through, I wonder why you have SECTIONs now that memory
segmentation isn't needed)

....

>
>Code is only 'dangerous' when it is improperly understood, written by
>somebody who improperly understands it, or written carelessly. All
>programming is 'dangerous' if you do not take care with it.

This answer is where your mistake is. The person who wrote the
program isn't always the person who needs to understand it properly.

Lots of "best practices" aren't to make the very best program for now
- but they are to have the program that works best for the life of the
program and the system that the program belongs to.

If such an environment includes interns making modifications in the
middle of the night 5 years from now - then that is the environment
that the code should be designed for.

So the intern adds some code:
IF SSN='123456789'
PERFORM SPECIAL-CODE
END-IF

And adds that paragraph to the bottom of the program, then the problem
isn't just his problem, it is the company's problem.

I also put in redundant parenthesis in complex IF statements - to make
it harder for some future programmer to guess wrong about what my
intentions were.

Don't just code for the computer. Code for the total environment -
which includes future programmers.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Pete Dashwood

2006-07-11, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:sh87b2dnf21lnhag2d98d5movpboshvu6e@
4ax.com...
> On Tue, 11 Jul 2006 09:20:03 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
>
> As long as someone else doesn't touch them. (Since an EXIT paragraph
> is a drop through, I wonder why you have SECTIONs now that memory
> segmentation isn't needed)
>
Because a SECTION is a logical sub-division of a COBOL program. It has
nothing to do with segmentation, although that was a useful feature before
virtual memory was developed.

COBOL has a logical hierarchic structure:

DIVISION
SECTION
PARAGRAPH
Sentence (now replaced by scope delimitation for the most
part)
Statement
word

I have respect for the people who dreamed this up and I have found no reason
to violate it.

Long before OO it was convenient (at least for some of us) to encapsulate
functions within a program. They were SECTIONS of code that could never be
executed directly, but would be performed from the mainline, which had the
simple function of controlling the order in which sections were executed.

People who work in places where this kind of programming is implemented know
better than to mix different styles and add paragraphs when they should be
adding sections.(Apart from anythng else, the local standards on such sites
mandate that only a SECTION can be PERFORMed.) This is probably why the
problems identified by yourself and Richard have never been encountered in
my experience. I don't disagree these are problematic, in theory. In
practise, I have never found them so.
> ...
>
>
> This answer is where your mistake is. The person who wrote the
> program isn't always the person who needs to understand it properly.

This response is where YOUR mistake is... If you let people who are
incompetent loose on programs, then you deserve whatever you get. Don't
blame the language or the writer. ANYBODY who is going to maintain COBOL
code, needs to understand it properly. To do otherwise is to court disaster,
no matter what styles or conventions you put in place.
>
> Lots of "best practices" aren't to make the very best program for now
> - but they are to have the program that works best for the life of the
> program and the system that the program belongs to.

Certainly. One of the priorities for procedural code such as COBOL is that
it will require maintenance and this should be facilitated. That's why we
have local standards; so everybody is on the same wavelength.

BUT, (and this is where you and I part company) "facilitating maintenance"
does NOT mean coding for the lowest common denominator. I assume that anyone
required to maintain my code will be a competent COBOL practitioner. I
structure the code, comment it and don't do deliberately obscure things. I
also observe local standards.

In a working lifetime, no-one has ever had trouble maintaining code I wrote
(apart from me, in the first year or so of my career... :-)), whether it was
SECTIONED, PARAGRAPHED, PERFORMED THRU, or whatever. This has been on
something like 70 installations, across 3 continents. In fact, I've had
people come up to me later and say how they had enjoyed maintaining it and
in some instances adopted elements of style they found in it. COBOL is not
rocket science. You don't need to be a genius to maintain it or write it.
But you don't need to be an idiot either.
>
> If such an environment includes interns making modifications in the
> middle of the night 5 years from now - then that is the environment
> that the code should be designed for.

I absolutely and vehemently disagree. This is just an old chestnut about the
middle of the night maintenance. If it can be maintained in the light of
day, it can be maintained in the middle of the night. Why should we develop
code for the bottom of the pond? If that is what you require, then don't ask
me to write it. And while we're on this middle of the night thing, I have
seen more code stuffed up by hasty maintenance (without a proper
understanding of what it was doing or required to do) AT ANY TIME OF DAY,
than specifically in the middle of the night.

>
> So the intern adds some code:
> IF SSN='123456789'
> PERFORM SPECIAL-CODE
> END-IF
>
> And adds that paragraph to the bottom of the program, then the problem
> isn't just his problem, it is the company's problem.

The whole question of maintaining procedural code in-house is the Company's
problem and it is becoming non-viable. That's why companies are voting with
their feet and moving to packages, outsourcing, and component based
solutions (J2EE and .NET)

(Leaving the real world aside and getting back to COBOL...)

First off, he won't add that as a paragraph if the rest of the code is
sectioned, and the local standards require him to build sections and not mix
styles. He will add that code as a section. That is what he will have been
trained to do, and if he really is a rookie he will not be allowed to amend
production code without having his code checked and reviewed by a team lead
or senior, irrespective of what the standards are or how he has coded his
solution.

Second off, even if he didn't, it would become apparent very quickly that
the "fix" he made was causing more problems. So either, he'd look at it
again and realise his mistake, or someone else would.

>
> I also put in redundant parenthesis in complex IF statements - to make
> it harder for some future programmer to guess wrong about what my
> intentions were.

Redundant parentheses simply clutter the code and make it harder to read.
Necessary, or even optional, parentheses are extremely helpful. If there is
the slightest doubt or clarity is helped by adding them, then I would agree
that parentheses are a Good Thing; redundant "anything" is more often than
not counter productive.
>
> Don't just code for the computer. Code for the total environment -
> which includes future programmers.

Sorry. It takes me all my time to code for the best solution I can find
today. Sufficient unto the morrow the evils thereof.

We are going to have to differ on this one.

However, if it is any consolation, I no longer write COBOL for a living (it
is purely for fun now), so what I think about this issue is probably pretty
academic.

One thing I am sure of is that if you write to the lowest common denominator
(and I have worked on sites where they banned negated IF, PERFORM...VARYING,
SEARCH, STRING/UNSTRING, INSPECT..except the simplest forms, and so on...)
you will not necessarily improve ease of maintenance anyway. What you will
do is lose the brightest people you have, because they are stifled by the
installation. And such shops (at least in my experience) are usually managed
by unimaginative, tyrannical little Jobsworth's who are much more concerned
with ticks in boxes than innovative or 'different' approaches. As I'm
writing this, I'm seeing faces I would rather forget...talk about the ghosts
of Xmas past... :-)

Write the best code you can write and encourage others to do so too. Aim
high and try to make each program better than the last one you wrote. If
some people have difficulty with it, maybe they should drive a truck and
leave programming to the programmers...

Pete.

charles hottel

2006-07-11, 6:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4hhu9bF1qvpvvU1@individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:sh87b2dnf21lnhag2d98d5movpboshvu6e@
4ax.com...
> Because a SECTION is a logical sub-division of a COBOL program. It has
> nothing to do with segmentation, although that was a useful feature before
> virtual memory was developed.
>
> COBOL has a logical hierarchic structure:
>
> DIVISION
> SECTION
> PARAGRAPH
> Sentence (now replaced by scope delimitation for the
> most part)
> Statement
> word
>
> I have respect for the people who dreamed this up and I have found no
> reason to violate it.
>
> Long before OO it was convenient (at least for some of us) to encapsulate
> functions within a program. They were SECTIONS of code that could never be
> executed directly, but would be performed from the mainline, which had the
> simple function of controlling the order in which sections were executed.
>
> People who work in places where this kind of programming is implemented
> know better than to mix different styles and add paragraphs when they
> should be adding sections.(Apart from anythng else, the local standards on
> such sites mandate that only a SECTION can be PERFORMed.) This is probably
> why the problems identified by yourself and Richard have never been
> encountered in my experience. I don't disagree these are problematic, in
> theory. In practise, I have never found them so.
>
> This response is where YOUR mistake is... If you let people who are
> incompetent loose on programs, then you deserve whatever you get. Don't
> blame the language or the writer. ANYBODY who is going to maintain COBOL
> code, needs to understand it properly. To do otherwise is to court
> disaster, no matter what styles or conventions you put in place.
>
> Certainly. One of the priorities for procedural code such as COBOL is that
> it will require maintenance and this should be facilitated. That's why we
> have local standards; so everybody is on the same wavelength.
>
> BUT, (and this is where you and I part company) "facilitating maintenance"
> does NOT mean coding for the lowest common denominator. I assume that
> anyone required to maintain my code will be a competent COBOL
> practitioner. I structure the code, comment it and don't do deliberately
> obscure things. I also observe local standards.
>
> In a working lifetime, no-one has ever had trouble maintaining code I
> wrote (apart from me, in the first year or so of my career... :-)),
> whether it was SECTIONED, PARAGRAPHED, PERFORMED THRU, or whatever. This
> has been on something like 70 installations, across 3 continents. In fact,
> I've had people come up to me later and say how they had enjoyed
> maintaining it and in some instances adopted elements of style they found
> in it. COBOL is not rocket science. You don't need to be a genius to
> maintain it or write it. But you don't need to be an idiot either.
>
> I absolutely and vehemently disagree. This is just an old chestnut about
> the middle of the night maintenance. If it can be maintained in the light
> of day, it can be maintained in the middle of the night. Why should we
> develop code for the bottom of the pond? If that is what you require, then
> don't ask me to write it. And while we're on this middle of the night
> thing, I have seen more code stuffed up by hasty maintenance (without a
> proper understanding of what it was doing or required to do) AT ANY TIME
> OF DAY, than specifically in the middle of the night.
>
>
>
> The whole question of maintaining procedural code in-house is the
> Company's problem and it is becoming non-viable. That's why companies are
> voting with their feet and moving to packages, outsourcing, and component
> based solutions (J2EE and .NET)
>
> (Leaving the real world aside and getting back to COBOL...)
>
> First off, he won't add that as a paragraph if the rest of the code is
> sectioned, and the local standards require him to build sections and not
> mix styles. He will add that code as a section. That is what he will have
> been trained to do, and if he really is a rookie he will not be allowed to
> amend production code without having his code checked and reviewed by a
> team lead or senior, irrespective of what the standards are or how he has
> coded his solution.
>
> Second off, even if he didn't, it would become apparent very quickly that
> the "fix" he made was causing more problems. So either, he'd look at it
> again and realise his mistake, or someone else would.
>
>
> Redundant parentheses simply clutter the code and make it harder to read.
> Necessary, or even optional, parentheses are extremely helpful. If there
> is the slightest doubt or clarity is helped by adding them, then I would
> agree that parentheses are a Good Thing; redundant "anything" is more
> often than not counter productive.
>
> Sorry. It takes me all my time to code for the best solution I can find
> today. Sufficient unto the morrow the evils thereof.
>
> We are going to have to differ on this one.
>
> However, if it is any consolation, I no longer write COBOL for a living
> (it is purely for fun now), so what I think about this issue is probably
> pretty academic.
>
> One thing I am sure of is that if you write to the lowest common
> denominator (and I have worked on sites where they banned negated IF,
> PERFORM...VARYING, SEARCH, STRING/UNSTRING, INSPECT..except the simplest
> forms, and so on...) you will not necessarily improve ease of maintenance
> anyway. What you will do is lose the brightest people you have, because
> they are stifled by the installation. And such shops (at least in my
> experience) are usually managed by unimaginative, tyrannical little
> Jobsworth's who are much more concerned with ticks in boxes than
> innovative or 'different' approaches. As I'm writing this, I'm seeing
> faces I would rather forget...talk about the ghosts of Xmas past... :-)
>
> Write the best code you can write and encourage others to do so too. Aim
> high and try to make each program better than the last one you wrote. If
> some people have difficulty with it, maybe they should drive a truck and
> leave programming to the programmers...
>
> Pete.
>

I agree with Pete on this. Most of the programs that I maintain (and not
originally written by me) use the PERFORM xxx-para1 THRU xxx-para1-EXIT
style. Yes there are theoretically ways that this can cause problems but I
do not see them in practice. One thing that I like about this style is the
ability to place IF statements at the beginning of the paragraph that check
for error situations and then do GO TO the exit if there is an error. Before
you flame me, I will state that I know that the logic can be written without
GO TO, but usually it means coding nested IF statements. I have known a lot
of smart people and otherwise competent programmers who cannot follow nested
IF statements very well beyond one or two levels of nesting.

A lot of the people posting here are experts but in the real world you do
not always have the luxury of working only with experts. In my experience
even non-experts have no problem avoiding some of the theoretical problems
mentioned in this thread. I am certain that management does not want me
rewriting programs to follow Richards style even if I could get them to
agree that it was better. We seldom get a chance to start out clean in a new
environment and to establish the coding style for an entire business or
department. Most of the time we have to adapt ourselves to follow the
conventions already in place. When I first started at my current job about
15 years ago I found the style of their CICS programs appalling. I made some
suggestions for improvement and was rebuffed. Eventually I made an
investment of time to understand their style and it was worthwhile because
by understanding one example I pretty much understood the structure of all
of their CICS programs. I still think that there are better ways to do some
things but I do them in the way that my co-workers will understand because
that is the way management wants things done. Also I realize that many of
these programs have a long history dating from the early days of command
level CICS when the environment was more restricted.

I have seen many people come and go here in the last 15 years. Almost
everyone who tried writing their CICS programs from scratch in their own
preferred style, because they could not adapt to the local style, is now
gone. I know one person who worked for more that six w

s on a simple
program and never got it to work. A co-worker used an existing program as a
template, modified it, and had a working program after only three days. Of
course this story also illustrates the exception in that the unsuccessful
person is now a manager and the successful person left because she could not
get promoted, mainly because she was a woman.

2006-07-12, 7:55 am

[apologies in advance for inaccurate or dropped attributions]

In article <380b$44b44600$4f9c60a$15883@DIALUPUSA.NET>,
charles hottel <jghottel@yahoo.com> wrote:
>
>"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
>news:4hhu9bF1qvpvvU1@individual.net...

[snip]
[color=darkred]

This seems to be a definition which assumes a single value for the
condition of 'competence'; it may be more useful to consider the condition
to be a gradient (something more like the more-common experiences of
temperature, given that experiencing absolute zero is a less-common
experience) rather than a binary.

[snip]
[color=darkred]

If, as posited above, competence is a gradient then 'a competent COBOL
programmer' makes as much sense as saying 'a heated liquid'... heated from
what point to which?

[snip]
[color=darkred]

Our experiences are different, Mr Dashwood. In the same shop, for the
same program, I have had coders tell me they've had no trouble with what
I've cobbled together... and I have heard - not been told directly, I
wonder why - that other coders have spent long periods cursing 'that
horrid consultant' who left them with 'a pile of crap' that they could not
make heads or tails of and had to rewrite from the ground up.

[snip]
[color=darkred]

That 'old chestnut', Mr Dashwood, seems to have been confirmed by the
experiences of just a few other programmers, some of them having,
possibly, levels of skill and expertise which even you might label
'considerable'.
[color=darkred]

There may be a variety of reasons for this, Mr Dashwood... consider:

The one who signs the timesheets requests it.

There is a kind of joy which is generated by having a corner-office idiot
look at some code and say 'this is simple... why did we pay so much for
the guy who developed it?'

It avoids the difficulties which have been seen as being caused by 'Look,
Mom, I'm a Programmer!' code which delights in complexity for complexity's
sake.

.... and others.
[color=darkred]

Nothing is required of everyone at all times, Mr Dashwood... including
this statement. It may be that A Sensitive Artist may find a certain kind
of work degrading... while an Artist of equal capacity but lesser
Sensitivity might take pleasure in unravelling how to make the complex
more readily apprehensible.

[snip]
[color=darkred]

[snip]
[color=darkred]

My experience differs from yours, Mr Dashwood, and as for your bandying
about 'he won't', 'he will' and 'they will/won't'... I barely know what
*I* will or won't do, let alone anyone else.

I *do* have some vague recollections of what I have seen and what I have
done... and I try to keep those in mind.
[color=darkred]

Once again, Mr Dashwood, you readily assert something which is contrary to
my experience, the 'it would become apparent very quickly'... but, of
course, I don't know what you are calling 'very quickly'. Imagine. if you
can, an error that is introduced into an update that is run quarterly...
or annually... and ask yourself how 'very quickly' this will be found.

(I once misplaced a set of parentheses in an equation that was used to
calculate tax rates in an online program used daily by several tens of
technicians... 'very quickly', in that case, was two months.)
[color=darkred]

Oh, I *cannot* resist...

.... perhaps it does, Mr Dashwood, for those at the bottom of the pond.

[snip]
[color=darkred]

But never put off until tomorrow what can be done today... oh boy,
duelling aphorisms! Many hands make light broth!
[color=darkred]

It might be, Mr Dashwood, that the views of academics and the views of
day-to-day practioners might differ.
[color=darkred]

Forget the faces for a moment, Mr Dashwood, and think about the
companies... not just the DP/IS/MIS departments. Did they stay in
business for a few years? Did they return profit to the shareholders?
Code is supposed to help companies do these things, companies do not exist
in order to stimulate the minds of programmers.

[snip]
[color=darkred]
>I have known a lot
>of smart people and otherwise competent programmers who cannot follow nested
>IF statements very well beyond one or two levels of nesting.

Ahhhhh... notice the shift to 'otherwise competent', rather than referring
to 'competence as binary'. I recall being taught, years ago, that nesting
should be kept to three levels.

[snip]

>When I first started at my current job about
>15 years ago I found the style of their CICS programs appalling. I made some
>suggestions for improvement and was rebuffed. Eventually I made an
>investment of time to understand their style and it was worthwhile because
>by understanding one example I pretty much understood the structure of all
>of their CICS programs.

Hmmmmm... perhaps, Mr Hottel, you gained an idea of the context of the
programs which facilitated what you call 'understanding'... no, that's too
complicated, it must be that what you gained was... negative competence...
and I am the King of England, you know.

[snip]

>I have seen many people come and go here in the last 15 years. Almost
>everyone who tried writing their CICS programs from scratch in their own
>preferred style, because they could not adapt to the local style, is now
>gone. I know one person who worked for more that six w

s on a simple
>program and never got it to work. A co-worker used an existing program as a
>template, modified it, and had a working program after only three days.

But think, Mr Hottel, of how stimulated the first programmer was during
those six w

s... isn't that worth more to the company than having a mere
running program that does what it is supposed to?

>Of
>course this story also illustrates the exception in that the unsuccessful
>person is now a manager and the successful person left because she could not
>get promoted, mainly because she was a woman.

The story illustrates an exception... how? The unsuccessful one is a
manager... hnmmmmm... I recall someone posting here about how 'I cannot
lower the quality of my thinking far enough to be a manager', that seems
right in line with this experience.

DD

Pete Dashwood

2006-07-12, 7:55 am

"charles hottel" <jghottel@yahoo.com> wrote in message
news:380b$44b44600$4f9c60a$15883@DIALUPU
SA.NET...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4hhu9bF1qvpvvU1@individual.net...
<snipped discussion between Howard and Pete>[color=darkred]
>
> I agree with Pete on this. Most of the programs that I maintain (and not
> originally written by me) use the PERFORM xxx-para1 THRU xxx-para1-EXIT
> style. Yes there are theoretically ways that this can cause problems but I
> do not see them in practice. One thing that I like about this style is the
> ability to place IF statements at the beginning of the paragraph that
> check for error situations and then do GO TO the exit if there is an
> error. Before you flame me, I will state that I know that the logic can be
> written without GO TO, but usually it means coding nested IF statements. I
> have known a lot of smart people and otherwise competent programmers who
> cannot follow nested IF statements very well beyond one or two levels of
> nesting.
>
I wouldn't mind a dollar for every time I've been asked to explain nested
IFs to a non-expert audience. I don't actually use them a lot myself, but
when I do, I never nest beyond 4 or 5 levels, I indent the code to match the
nesting, and I never nest into the FALSE branch. Here's a typical one of
mine:

if c1 *> note that only the TRUE branches will have nesting...
if c2
if c3
perform all-3-were-TRUE
else
perform only-the-first-2-were-TRUE *> Note NO nesting in
the FALSE branch
end-if
else
perform only-the-first-1-was-TRUE
end-if
else
perform the-first-one-wasnt-TRUE
end-if

This represents a decision tree.

If you DIDN'T use nesting then you could express it in English as:

If c1 is true and c2 is true and c3 is true do all-3-were-TRUE.
If c1 is true and c2 is true and c3 is NOT true do
only-the-first-2-were-TRUE.
If c1 is true and c2 is NOT true do only-the-first-1-was-TRUE
If c1 is NOT true do the-first-one-wasnt-TRUE

The equivalent COBOL statements for this are much less elegant than the
nested structure.

I have contrived the last part of the abve to make it more readable. In
practice, the last action is not required and it would simply pass to the
next statement. The nested code then looks like this:

if c1 *> note that only the TRUE branches will have nesting...
if c2
if c3
perform all-3-were-TRUE
else
perform only-the-first-2-were-TRUE *> Note NO nesting in
the FALSE branch
end-if
else
perform only-the-first-1-was-TRUE
end-if
end-if

> A lot of the people posting here are experts but in the real world you do
> not always have the luxury of working only with experts. In my experience
> even non-experts have no problem avoiding some of the theoretical problems
> mentioned in this thread.

Thanks for posting this, Charles. I didn't make that point in my original
post and I should have. Non-expert people do not, in my experience either,
fall into the theoretical traps.

> I am certain that management does not want me rewriting programs to follow
> Richards style even if I could get them to agree that it was better. We
> seldom get a chance to start out clean in a new environment and to
> establish the coding style for an entire business or department. Most of
> the time we have to adapt ourselves to follow the conventions already in
> place. When I first started at my current job about 15 years ago I found
> the style of their CICS programs appalling. I made some suggestions for
> improvement and was rebuffed. Eventually I made an investment of time to
> understand their style and it was worthwhile because by understanding one
> example I pretty much understood the structure of all of their CICS
> programs.

Investing time to understand a different way of doing something has even
more important spin-offs than finding you can do things quicker on that
site...it broadens your experience and understanding, even if you don't
agree with it!

> I still think that there are better ways to do some things but I do them
> in the way that my co-workers will understand because that is the way
> management wants things done. Also I realize that many of these programs
> have a long history dating from the early days of command level CICS when
> the environment was more restricted.
>
> I have seen many people come and go here in the last 15 years. Almost
> everyone who tried writing their CICS programs from scratch in their own
> preferred style, because they could not adapt to the local style, is now
> gone. I know one person who worked for more that six w

s on a simple
> program and never got it to work. A co-worker used an existing program as
> a template, modified it, and had a working program after only three days.

Only three days, huh? :-)

> Of course this story also illustrates the exception in that the
> unsuccessful person is now a manager and the successful person left
> because she could not get promoted, mainly because she was a woman.
Oh Man, that just sucks so bad... I have to say I'd have trouble working on
a site with such blatant sexism. Still, I'm sure in the long term, they'll
get what they deserve, and the lady in question is probably more gainfully
employed in a place where they recognise her ability, rather than which
restroom she uses...

Pete.

charles hottel

2006-07-12, 7:55 am

<docdwarf@panix.com> wrote in message news:e92s4v$dke$1@reader2.panix.com...
> [apologies in advance for inaccurate or dropped attributions]
>
> In article <380b$44b44600$4f9c60a$15883@DIALUPUSA.NET>,
> charles hottel <jghottel@yahoo.com> wrote:

<snip>

>
> The story illustrates an exception... how? The unsuccessful one is a
> manager... hnmmmmm... I recall someone posting here about how 'I cannot
> lower the quality of my thinking far enough to be a manager', that seems
> right in line with this experience.
>
> DD
>
It is an exception to "most of them are none no longer working here".

2006-07-12, 6:55 pm

In article <477de$44b4fd9e$4f9c653$20632@DIALUPUSA.NET>,
charles hottel <jghottel@yahoo.com> wrote:
>
><docdwarf@panix.com> wrote in message news:e92s4v$dke$1@reader2.panix.com...
>
><snip>
>
>It is an exception to "most of them are none no longer working here".

Ummmmm... the story was about two people, Mr Dashwood, one of whom stayed,
one of whom left. Perhaps a Manager is needed to explain how 50% of a
sample of two might be considered as 'most'.

DD

charles hottel

2006-07-12, 9:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4hkcjnF9b0U1@individual.net...
>

<snip>

> I wouldn't mind a dollar for every time I've been asked to explain nested
> IFs to a non-expert audience. I don't actually use them a lot myself, but
> when I do, I never nest beyond 4 or 5 levels, I indent the code to match
> the nesting, and I never nest into the FALSE branch. Here's a typical one
> of mine:
>
> if c1 *> note that only the TRUE branches will have nesting...
> if c2
> if c3
> perform all-3-were-TRUE
> else
> perform only-the-first-2-were-TRUE *> Note NO nesting in
> the FALSE branch
> end-if
> else
> perform only-the-first-1-was-TRUE
> end-if
> else
> perform the-first-one-wasnt-TRUE
> end-if
>
> This represents a decision tree.
>
> If you DIDN'T use nesting then you could express it in English as:
>
> If c1 is true and c2 is true and c3 is true do all-3-were-TRUE.
> If c1 is true and c2 is true and c3 is NOT true do
> only-the-first-2-were-TRUE.
> If c1 is true and c2 is NOT true do only-the-first-1-was-TRUE
> If c1 is NOT true do the-first-one-wasnt-TRUE
>
> The equivalent COBOL statements for this are much less elegant than the
> nested structure.
>
> I have contrived the last part of the abve to make it more readable. In
> practice, the last action is not required and it would simply pass to the
> next statement. The nested code then looks like this:
>
>
> if c1 *> note that only the TRUE branches will have nesting...
> if c2
> if c3
> perform all-3-were-TRUE
> else
> perform only-the-first-2-were-TRUE *> Note NO nesting in
> the FALSE branch
> end-if
> else
> perform only-the-first-1-was-TRUE
> end-if
> end-if
>
<snip>
Here is a typical nest IF example that I think most non-experts would be
challenged by. It is typical in nesting levels though perhaps longer than
most. It is not the worst I have seen by a long shot.

IF SMOREI NOT = 'Y'
INITIALIZE COMM-VIOPEN-TABLE
EDITED-PENALT
PERFORM AA700-INITIALIZE-ADD-DATA
MOVE ALL '_' TO SVIOLCDO, SVIOLIDO, SVIONAMO,
SPRIVIOO, SPENALTO
MOVE SPACES TO SVIODESO
MOVE SPACES TO COMM-SVIOLCD, COMM-SVIOLID
MOVE NEG-ONE TO SVIOLCDL
MOVE SVIOSEQI TO WS-VIOL-SEQ-ALPHA
ADD ONE TO WS-VIOL-SEQ
MOVE WS-VIOL-SEQ-ALPHA TO SVIOSEQO
MOVE '2' TO COMM-PAGE-TYPE
RBL09 MOVE FPA01-CASE-NBR TO WS-CASE-NBR-2
MOVE SVIOSEQI TO WS-VIOL-SEQ-1-2-ALPHA
MOVE '02' TO WS-VIOL-SEQ-2-2
MOVE WS-FPV-KEY2 TO COMM-DB-KEY-VALUE
MOVE 'FPV' TO COMM-DB-FILE
MOVE 'FPVK1' TO COMM-DB-KEY-NAME
MOVE 'FPV01' TO COMM-ELT-LIST
MOVE 'LOCKY' TO COMM-DB-COMMAND
MOVE 'N' TO COMM-NEXT-VIO-SEQ-FOUND-SW
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
MOVE COMM-DB-KEY-VALUE TO WS-FPV-KEY2-COMPARE
RBL09 IF WS-CASE-NUMBER-CMP = WS-CASE-NBR-2
IF WS-VIOL-SEQ-2-CMP NOT = '02'
PERFORM UNTIL WS-VIOL-SEQ-2-CMP = '02'
RBL09 OR WS-CASE-NUMBER-2 NOT = WS-CASE-NUMBER-CMP
OR NOT REC-FOUND
MOVE 'LOCNX' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL
THRU AA600-EXIT
IF REC-FOUND
MOVE COMM-DB-KEY-VALUE
TO WS-FPV-KEY2-COMPARE
END-IF
END-PERFORM
RBL09 IF WS-CASE-NUMBER-2 = WS-CASE-NUMBER-CMP
AND WS-VIOL-SEQ-2-CMP = '02'
MOVE 'REDLE' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL
THRU AA600-EXIT
MOVE 'Y' TO COMM-NEXT-VIO-SEQ-FOUND-SW
END-IF
ELSE
MOVE 'REDLE' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
MOVE 'Y' TO COMM-NEXT-VIO-SEQ-FOUND-SW
END-IF
ELSE
IF SEE-FUNCTION
MOVE COMM-SCREEN-2-FUNC TO COMM-SFUNCT
COMM-CALLER-FCD
RBL09** MOVE FPA01-CASE-NUMBER TO COMM-SKEY
RBL09 MOVE FPA01-CASE-NBR TO COMM-SKEY
GO TO TS100-WRITE-QUEUE-1
END-IF
END-IF
END-IF
IF NEXT-VIO-SEQ-FOUND
MOVE COMM-DB-REQUEST TO COMM-DB-REQ-SAV
MOVE FPV01-PENALTY-AMT TO COMM-SPENALT
AMOUNTS-WORK-AREA
MOVE AMOUNTS-WORK-AREA-ALPHA TO SPENALTO
MOVE FPV01-VIOLATION TO SPRIVIOO
COMM-SPRIVIO
COMM-DB-KEY-VALUE
MOVE FPE01-RECORD TO FPE-SAVE-AREA
MOVE 'FPE' TO COMM-DB-FILE
MOVE 'FPE01' TO COMM-ELT-LIST
MOVE 'FPEK1' TO COMM-DB-KEY-NAME
MOVE 'REDKX' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
MOVE FPE01-ABV-TEXT TO SVIODESO
END-IF
MOVE FPE-SAVE-AREA TO FPE01-RECORD
MOVE FPV01-VIOLATOR-SEQ TO SVIOSEQO
COMM-SVIOSEQ
MOVE FPV01-VIOL-CODE TO SVIOLIDO
COMM-SVIOLID
MOVE FPV01-VIOL-TYPE TO SVIOLCDO
COMM-SVIOLCD
MOVE SVIOLIDI TO WS-VIOL-ID
MOVE SVIOLCDI TO WS-VIOL-TYPE
ALB02 MOVE SPORTI TO WS-VIOL-DIST
MOVE WS-FPC-KEY TO COMM-DB-KEY-VALUE
MOVE 'FPCK4' TO COMM-DB-KEY-NAME
MOVE 'FPC' TO COMM-DB-FILE
MOVE 'FPC01' TO COMM-ELT-LIST
MOVE 'REDKX' TO COMM-DB-COMMAND
MOVE FPC01-RECORD TO FPC-SAVE-AREA
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
MOVE FPC01-VIOL-NAME TO SVIONAMO
COMM-SVIONAM
ELSE
MOVE SPACES TO SVIONAMO
COMM-SVIONAM
END-IF
MOVE FPC-SAVE-AREA TO FPC01-RECORD
MOVE COMM-DB-REQ-SAV TO COMM-DB-REQUEST
MOVE 'FPV01' TO COMM-ELT-LIST
MOVE 'REDNX' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
RBL09 AND FPV01-CASE-NBR = WS-CASE-NUMBER-CMP
AND FPV01-VIOLATOR-SEQ = WS-VIOL-SEQ-1-CMP
MOVE ONE TO SUB1
PERFORM UNTIL NOT-FOUND OR SUB1 > TEN
MOVE COMM-DB-RECID TO COMM-VIO-RECID (SUB1)
VGS08 MOVE COMM-DB-URI-BLOCK TO COMM-VIO-URI (SUB1)
MOVE FPV01-VIOLATION TO COMM-VIO (SUB1)
SCR-VIOLATION (SUB1)
MOVE FPV01-PENALTY-AMT TO COMM-PEN (SUB1)
AMOUNTS-WORK-AREA
MOVE AMOUNTS-WORK-AREA TO SCR-PENALTY (SUB1)
MOVE 'REDNE' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
ADD ONE TO SUB1
END-PERFORM
IF SUB1 > TEN
IF REC-FOUND
MOVE 'Y' TO SMOREO
COMM-MORE-VIOLATIONS-SW
ELSE
MOVE 'N' TO SMOREO
COMM-MORE-VIOLATIONS-SW
END-IF
ELSE
MOVE 'N' TO SMOREO
COMM-MORE-VIOLATIONS-SW
END-IF
END-IF
END-IF
ELSE
MOVE '3' TO COMM-PAGE-TYPE
PERFORM AA700-INITIALIZE-ADD-DATA THRU AA700-EXIT
IF SEE-FUNCTION AND COMM-VIO-RECID (TEN) NOT = SPACES
OR COMM-CHG-FUNCTION AND WS-SAVE-RECID NOT = SPACES
MOVE 'FPV01' TO COMM-ELT-LIST
MOVE 'FPV' TO COMM-DB-FILE
MOVE 'FPVK1' TO COMM-DB-KEY-NAME
IF COMM-CHG-FUNCTION
MOVE WS-SAVE-RECID TO COMM-DB-RECID
VGS08 MOVE WS-SAVE-URI TO COMM-DB-URI-BLOCK
ELSE
MOVE COMM-VIO-RECID (TEN) TO COMM-DB-RECID
VGS08 MOVE COMM-VIO-URI (TEN) TO COMM-DB-URI-BLOCK
END-IF
MOVE 'REDID' TO COMM-DB-COMMAND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
INITIALIZE COMM-VIOPEN-TABLE
EDITED-PENALT
RBL09 MOVE FPV01-CASE-NBR TO WS-CASE-NBR-2
MOVE FPV01-VIOLATOR-SEQ TO WS-VIOL-SEQ-1-2
MOVE FPV01-VIOLATION-SEQ TO WS-VIOL-SEQ-2-2
MOVE WS-FPV-KEY2 TO COMM-DB-KEY-VALUE
MOVE FPV01-VIOLATION TO WS-SAVE-VIOLATION
MOVE 'REDKY' TO COMM-DB-COMMAND
MOVE SPACES TO FPV01-VIOLATION
PERFORM UNTIL FPV01-VIOLATION = WS-SAVE-VIOLATION
OR NOT REC-FOUND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
MOVE 'REDNE' TO COMM-DB-COMMAND
END-PERFORM
IF REC-FOUND
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
CONTINUE
ELSE
MOVE 'ENTER ADDITIONAL VIOLATIONS' TO SCOMPLO
MOVE 'N' TO SMOREO
MOVE NEG-ONE TO SVIOL01L
GO TO AA800-SEND-SCREEN
END-IF
ELSE
MOVE 'ENTER ADDITIONAL VIOLATIONS' TO SCOMPLO
MOVE 'N' TO SMOREO
MOVE NEG-ONE TO SVIOL01L
GO TO AA800-SEND-SCREEN
END-IF
MOVE 'N' TO SMOREO
IF REC-FOUND
MOVE ONE TO SUB1
PERFORM UNTIL NOT REC-FOUND OR SUB1 > TEN
IF SUB1 NOT = ONE
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
END-IF
IF REC-FOUND
MOVE COMM-DB-RECID TO COMM-VIO-RECID (SUB1)
VGS08 MOVE COMM-DB-URI-BLOCK TO COMM-VIO-URI (SUB1)
MOVE FPV01-VIOLATION TO COMM-VIO (SUB1)
SCR-VIOLATION (SUB1)
MOVE FPV01-PENALTY-AMT TO COMM-PEN (SUB1)
AMOUNTS-WORK-AREA
MOVE AMOUNTS-WORK-AREA TO SCR-PENALTY (SUB1)
ADD ONE TO SUB1
END-IF
END-PERFORM
IF SUB1 > TEN
PERFORM AA600-DATABASE-CALL THRU AA600-EXIT
IF REC-FOUND
MOVE 'Y' TO SMOREO,
COMM-MORE-VIOLATIONS-SW
ELSE
MOVE 'N' TO SMOREO,
COMM-MORE-VIOLATIONS-SW
END-IF
ELSE
MOVE 'N' TO SMOREO,
COMM-MORE-VIOLATIONS-SW
END-IF
END-IF
ELSE
MOVE 'ENTER ADDITIONAL VIOLATIONS' TO SCOMPLO
MOVE 'N' TO SMOREO
END-IF
MOVE NEG-ONE TO SVIOL01L
END-IF.

charles hottel

2006-07-12, 9:55 pm

<docdwarf@panix.com> wrote in message news:e930ll$e68$1@reader2.panix.com...
> In article <477de$44b4fd9e$4f9c653$20632@DIALUPUSA.NET>,
> charles hottel <jghottel@yahoo.com> wrote:
>
> Ummmmm... the story was about two people, Mr Dashwood, one of whom stayed,
> one of whom left. Perhaps a Manager is needed to explain how 50% of a
> sample of two might be considered as 'most'.
>
> DD
>
This was a reply from me, Charlie Hottel, not from Pete Dashwood. I was
referring to this part of my original reply:

"I have seen many people come and go here in the last 15 years. Almost
everyone who tried writing their CICS programs from scratch in their own
preferred style, because they could not adapt to the local style, is now
gone."

It is an exception to the part of my statement "Almost everyone ... is now
gone." This manager is not gone. Actually he is the best of a IMNSHO bad
lot. I have heard anecdotal evidence from Pete of competent, good management
but I have not seen it in practice. My experience has been more along the
lines that you have expressed in the past. I try not to reflect or comment
on it too much as it does not make me feel better and I need to stay out of
trouble until I reach retirement.

I think you may be expecting a precision of expression from me that if often
missing.

dashwood@enternet.co.nz

2006-07-12, 9:55 pm

docdwarf@panix.com wrote:
> In article <477de$44b4fd9e$4f9c653$20632@DIALUPUSA.NET>,
> charles hottel <jghottel@yahoo.com> wrote:
>
> Ummmmm... the story was about two people, Mr Dashwood, one of whom stayed,
> one of whom left. Perhaps a Manager is needed to explain how 50% of a
> sample of two might be considered as 'most'.
>
Ummm... you are talking to yourself. I did not respond here and never
made the post you attribute to me. A cursory glance at the above shows
it is from Charles, not me.

As your experience varies so widely from mine, and as the word
'competence' seems to have a different meaning for each of us, I saw no
point in pursuing this.

Pete.

2006-07-13, 3:55 am

In article <cef7b$44b59fcf$4f9c65e$25820@DIALUPUSA.NET>,
charles hottel <jghottel@yahoo.com> wrote:
>
><docdwarf@panix.com> wrote in message news:e930ll$e68$1@reader2.panix.com...