More Structure.. Perform from Read
Lynn Randall
At the risk of starting another religious discussion, I would like to
solicit some opinions (the civil ones).
In my job, I have the task of reviewing programs of my co-workers before the
programs are allowed to go to production. My expectations are for
efficiency, understandability, adherence to standards, and maintainability
(the "understandable" and "maintainable" requirements are admittedly
related).
Part of the "maintainabiliy", is creating "structured" programs. There has
already been a certain amount of philosophical discussion about "structure"
in recent days in this newsgroup; and I don't really want to rehash all
that. I just would like some feedback on a couple of my "guidelines" -- I
need to determine if I'm still looking for "structure", or if I've crossed
the line to imposing my "style" upon my co-workers.
Here is the current issue...
When coding a read paragraph, is it appropriate to perform another paragraph
from within the Read? (Same question goes for Fetch paragraphs when dealing
with an SQL cursor).
For example:
0000-Mainline.
Perform 1000-Initialization
Perform 2000-Read
until file-eof
Perform 9000-Finalization
1000-Initialization.
... some init stuff..
2000-Read
Read Input-File into WS-Input-File
at end
set file-eof to true
not at end
Perform 3000-Process-records
end-read
3000-Process-records
... main processing logic here...
9000-Finalization
... control totals, etc. here....
The way Paragraph 2000- is coded, in my mind, violates the structured
programming principle of cohesion. That is, each paragraph should perform
one and only one function. Here, 2000- performs the Read AND it drives the
rest of the processing. That seems wrong to me, but one of co-workers
showed me a textbook where this "structure" was advocated. I've seen the
"structure" recently (let's say the last 3 years) from various programmers,
whereas previously (the prior 12 years or so), NO ONE I knew coded that way.
Have standards changed? In addition, I was originally taught that all file
I-O should be isolated in its own paragraph to ease dump-solving. How that
might help is not very clear from this example; so consider if the "not at
end" condition led to an Evaluate statement, or a series of If/Else
statements.
Just for grins... here is how I would have coded it traditionally...
0000-Mainline.
Perform 1000-Initialization
If file-eof
next sentence
else
Perform 2000-Process-Records
until file-eof
end-if
Perform 9000-Finalization
1000-Initialization.
... some stuff..
Perform 2000-Read
2000-Read
Read Input-File into WS-Input-File
at end
set file-eof to true
end-read
3000-Process-records
... main processing logic here...
Perform 2000-Read
9000-Finalization
... control totals, etc. here....
As you can see, one of my other "expectations" is that all paragraphs are
numbered. Judging by the posts to this newsgroup, that also seems to be out
of vogue. Years ago, I would not have coded a priming read in the
1000-Init paragraph; but I was persuaded otherwise...
I might add that, where COBOL is concerned, I am purely a mainframe
programmer (though I have some training in VB, and web stuff). So stuff
specific to Fujitsu or MicroFocus Cobol are of less interest to me.
Thanks..
James J. Gavan
Lynn Randall wrote:
> Here is the current issue...
> When coding a read paragraph, is it appropriate to perform another paragraph
> from within the Read? (Same question goes for Fetch paragraphs when dealing
> with an SQL cursor).
>
First off, you really didn't want to *know* about Micro Focus. Well...... vive
le difference! Now I wish I could just get the J4 guys to recognize that too,
(i.e. mainframe and PC 'special' requirements') !
> Just for grins... here is how I would have coded it traditionally...
>
> 0000-Mainline.
> Perform 1000-Initialization
> If file-eof
> next sentence
> else
> Perform 2000-Process-Records
> until file-eof
> end-if
> Perform 9000-Finalization
>
> 1000-Initialization.
> ... some stuff..
> Perform 2000-Read
>
> 2000-Read
> Read Input-File into WS-Input-File
> at end
> set file-eof to true
> end-read
>
> 3000-Process-records
> ... main processing logic here...
> Perform 2000-Read
>
> 9000-Finalization
> ... control totals, etc. here....
>
Using OO I don't see that I do anything dramatically different from your code
above. Ignore all the OO BS, but just like a factory making cookies, there's a
production line, and for Business Classes it is procedural just like you have.
(It is only random Windows events which make an OO/Structured program do a hop,
skip and a jump).
The only major difference, and this is being used by others not into OO, is that
your paragraph 2000-Read, to me becomes :-
invoke MyFileClass "read-primekey"
using thisKey returning fileStatusResult and data
OR invoke MyFileClass "read-next"
returning fileStatusResult and data
All reference to accessing a file is in one Class - prove that right and can be
reused over and over again. Whether the retrieved record is relevant is
determined in the Business Class - which is in response to your, "When coding a
read paragraph, is it appropriate to perform another paragraph from within the
Read? ".
Although at the experimental stage with SQL, essentially I'm doing the same
thing - a separate class per Table. From my initial scribblings, looks like the
same approach will work out nicely. As regards your FETCH using cursor, I cheat.
I stay within the Class Table method doing the Fetching, building up a
collection, (equivalent of a Table occurs x times, without having to specify 'x
times'), of rows or columns required until I hit 'No more rows' - the
collection gets returned to the Business class. A subtle difference between
COBOL file handling and SQL FETCH. Selectively choosing rows/columns is
determined from the parameters passed to the fetch-method.
Purely preference - but I wouldn't do that Initial Read up front in your
Initialization processes - but largely depends on what the program is doing.
>
> As you can see, one of my other "expectations" is that all paragraphs are
> numbered. Judging by the posts to this newsgroup, that also seems to be out
> of vogue. Years ago, I would not have coded a priming read in the
> 1000-Init paragraph; but I was persuaded otherwise...
>
> I might add that, where COBOL is concerned, I am purely a mainframe
> programmer (though I have some training in VB, and web stuff). So stuff
> specific to Fujitsu or MicroFocus Cobol are of less interest to me.
>
I'm beyond paragraph numbering, now using method-names which one can remember,
but would suggest it is primarily a question of style. When I first started I
used to segment :-
A010-DO-THIS, A020-DO-SOMETHING-ELSE
P010-PRINT-REPORT, P020-GET-REPORT-LINE etc....
but my thinking tied back to memory limitations and the 'alpha' numbering
mentally gave me my resident segments and overlays.
Two cents worth from one of the little guys on PCs <G>
Jimmy, Calgary AB
Richard Plinston
>
> Just for grins... here is how I would have coded it traditionally...
>
> 0000-Mainline.
> Perform 1000-Initialization
> If file-eof
> next sentence
> else
> Perform 2000-Process-Records
> until file-eof
> end-if
> Perform 9000-Finalization
!!!! SERIOUS BUG ALERT !!!
You have coded a NEXT SENTENCE in an IF ... END-IF. This is invalid
Cobol code and a bug looking for a place to happen. The effect of the
NEXT SENTENCE is that it is a GO TO next-full-stop. This means that
9000-Finalisation may or may not be done depending on whether someone
puts a full-stop on the END-IF or takes it off.
I can't tell whether you intended the NEXT SENTENCE to be used to skip
Finalisation or not because you haven't affed the full-stops, but the
next programmer won't be able to tell either as some fastidious zealot
may have added or removed full-stops wherever possible without regard to
this 'feature'.
It is best to avoid NEXT SENTENCE even though the compiler hasn't
flagged it as non-standard.
The IF file-eof is actually redundant anyway. The program will work
with:
PERFORM Initialisation
PERFORM Process-Records
UNTIL file-eof
PERFORM Finalisation
becasue the PERFORM is by default WITH TEST BEFORE.
> As you can see, one of my other "expectations" is that all paragraphs are
> numbered. Judging by the posts to this newsgroup, that also seems to be out
> of vogue.
Paragraph numbering was really useful when you had to find your way
around a box of several thousand punched cards. It was probably also
useful when text editors were 'forwards only', as in the 70s. When I
got my first full screen editor that went backwards and forwards 30 odd
years ago the whole point of numbering disappeared. I suspect some
still organise their programs that way though, especially when rewriting
the same batch program over again.
Willem Clements
>
Lynn,
Although I prefer your solution, I don't think the other one is too bad. I
don't think that any programmer who has to modify one of those programs will
have trouble understanding it.
Also, don't forget that the READ ... AT END ... NOT AT END construction
didn't exist when you started programming.
My reason to prefer your solution is another one to start a religious war, I
hate switches.
Of course, you can argue about what is a switch and what is not, but for end
of file conditions, I always use the file's status field.
You can call this a switch, but the important thing to me is that I never
touch it, so I can't forget setting or resetting it.
I would prefer it this way
0000-Mainline.
Perform 1000-Initialization
Perform 2000-Read.
Perform 2000-Process-Records
until file-status = '10'
Perform 9000-Finalization
1000-Initialization.
... some stuff..
2000-Read
Read Input-File into WS-Input-File
3000-Process-records
... main processing logic here...
Perform 2000-Read
9000-Finalization
... control totals, etc. here....
Of course, an 88 level on the file status is perfectly acceptable.
Just my $0.02
Willem Clements
Brainbench MVP for COBOL II
http://www.brainbench.com
Ross Klatte
>Date: 2001-06-05 03:10 Eastern Daylight Time
>On Mon, 4 Jun 2001 18:07:28 -0700, Lynn Randall wrote:
>>2000-Read
>> Read Input-File into WS-Input-File
>> at end
>> set file-eof to true
>> not at end
>> Perform 3000-Process-records
>> end-read
>>
I don't like this. It is a very popular approach, though, and I
have seen it at several places. To me, it represents a good
example of structured code without structured logic.
Logically, "Process-records" is not a natural subfunction
of "Read." The only thing I would like to see after "not at end"
is "add 1 to input-counter" or things of that ilk.
Reading input, on the other hand, is a natural subfunction
of procesing records.
>0000-Mainline.
> Perform 1000-Initialization
> Perform 2000-Read.
> Perform 2000-Process-Records
> until file-status = '10'
> Perform 9000-Finalization
>
>1000-Initialization.
> ... some stuff..
>
>2000-Read
> Read Input-File into WS-Input-File
>
>3000-Process-records
> ... main processing logic here...
> Perform 2000-Read
I like this.
However, Lynn Randall asked whether one or the other should
be enforced. By the manager? Absolutely not. One thing
you can do is call a shop coding standards meeting and call
for a vote. The important thing about a structuring standard
is not that it be structured but that it be standard.
Ross
http://www.geocities.com/ross_klatte/
Tim Coffey
I`m a big fan of putting all I/O in "black boxes" (ie, separate
paragraphs).
For files with variant record types, each 'write' of a type would also
get it's
own paragraph. For VSAM files using direct/browsed retrieval, each
kind of
'start/read' (full or partial key) would get it's own paragraph also.
So to answer your question, it seems that '2000-READ' should only
READ, and not
process records. In this sense it is mislabeled. It shouid be
'2000-PROCESS', which calls 'XXXX-READ'.
Robaire
<rip...@Azonic.co.nz> a écrit:
I expect that this was a slip-up ( admittedly a nasty one to detect )-
that the author would have written CONTINUE, instead of NEXT SENTENCE.
I suppose that the author will address this eventually.
CONTINUE would have been syntactically and logically acceptable here;
I also expect that another religious war will be started ( déjà-vu? )
concerning the use of CONTINUE versus negating the condition in the IF
test.
Robaire
Howard Brazee
Richard Plinston wrote:
> Lynn Randall wrote:
> >
> > Just for grins... here is how I would have coded it traditionally...
> >
> > 0000-Mainline.
> > Perform 1000-Initialization
> > If file-eof
> > next sentence
> > else
> > Perform 2000-Process-Records
> > until file-eof
> > end-if
> > Perform 9000-Finalization
>
> !!!! SERIOUS BUG ALERT !!!
>
> You have coded a NEXT SENTENCE in an IF ... END-IF. This is invalid
> Cobol code and a bug looking for a place to happen.
While it probably is a bug, it is valid CoBOL code. Certainly it is a bad idea
to stop using full stop periods and continue to use NEXT SENTENCE. Since I use a
pre-compiler which automatically inserts NEXT SENTENCE in its IDMS commands, I am
not even tempted to remove periods from my coding style.
> The IF file-eof is actually redundant anyway. The program will work
> with:
>
> PERFORM Initialisation
> PERFORM Process-Records
> UNTIL file-eof
> PERFORM Finalisation
>
> becasue the PERFORM is by default WITH TEST BEFORE.
That's what I would have done (with periods), but a little redundancy doesn't
hurt.
> > As you can see, one of my other "expectations" is that all paragraphs are
> > numbered. Judging by the posts to this newsgroup, that also seems to be out
> > of vogue.
>
> Paragraph numbering was really useful when you had to find your way
> around a box of several thousand punched cards. It was probably also
> useful when text editors were 'forwards only', as in the 70s. When I
> got my first full screen editor that went backwards and forwards 30 odd
> years ago the whole point of numbering disappeared. I suspect some
> still organise their programs that way though, especially when rewriting
> the same batch program over again.
I can't remember the last mainframe shop I worked in which didn't use them.
Reading a listing, they are nice, and it is easy to see "PERFORM 9000-FINALIZE"
will point to a paragraph at the end of the program.
Howard Brazee
> "Lynn Randall" <LERa...@yahoo.com> wrote in message news:<3b1c3...@news1.prserv.net>...
>
> I`m a big fan of putting all I/O in "black boxes" (ie, separate
> paragraphs).
> For files with variant record types, each 'write' of a type would also
> get it's
> own paragraph. For VSAM files using direct/browsed retrieval, each
> kind of
> 'start/read' (full or partial key) would get it's own paragraph also.
I have never been a fan of this, unless the I/O paragraph is large. I would rather see the
line of code when I get to it in the logic than assume it to be correct.
Joseph J Katnic
<LERa...@yahoo.com> wrote:
<snip>
> 0000-Mainline.
> Perform 1000-Initialization If file-eof
> next sentence
> else
> Perform 2000-Process-Records
> until file-eof
> end-if Perform 9000-Finalization
>
> 1000-Initialization.
> ... some stuff..
> Perform 2000-Read
>
> 2000-Read
> Read Input-File into WS-Input-File
> at end
> set file-eof to true
> end-read
>
> 3000-Process-records
> ... main processing logic here...
> Perform 2000-Read
>
> 9000-Finalization
> ... control totals, etc. here....
>
The above is harder to immediately understand as you have
to notice that the Intialization does a read before you
can understand why a test for EOF is done after Initializtion.
Binyamin Dissen
<jos...@josephk.iinet.net.au> wrote:
:>In article <3b1c3...@news1.prserv.net>, "Lynn Randall"
:><LERa...@yahoo.com> wrote:
And it is unnecessary (though I guess NEXT SENTENCE might skip
9000-Finalization - I don't use it) since the PERFORM of 2000-Process has it
as the UNTIL clause.
--
Binyamin Dissen <bdi...@dissensoftware.com>
Binyamin Dissen <bdi...@netvision.net.il>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
SkippyPB
enlightened us:
While I've used the style of having paragraphs that are performed for
all I/O and each file in its own paragraph, I am reminded of what the
prime directive of using a perform is. That is to group code that is
used more than once in a program in one place to avoid duplication of
code.
In your example, you only need to read the file in one place (process
paragraph). What purpose does putting the read into a paragraph by
itself then performing it, if that read is only needed for location?
Is it more readable? Not necessarily. Is it more efficient.
Absolutely not (you're generating a store, and a branch and link to
another location in your program which must also do a store and a
branch and link to a location outside of your program then a restore
then another branch).
So you're writing in this style because it "looks" structured? Not a
good reason.
Regards,
////
(o o)
-oOO--(_)--OOo-
Last night I played a blank tape full blast.
The mime next door went nuts.
DON'T DRILL in the Artic National Wildlife Refuge
Read the real facts at:
http://www.worldwildlife.org/arctic-refuge/
also
http://www.savepolarbears.org/
Remove nospam to email me.
Steve
Lynn Randall
Ross Klatte <klatt...@aol.commmm> wrote in message
news:20010605053853...@ng-ca1.aol.com...
>snippage>
> I like this.
>
> However, Lynn Randall asked whether one or the other should
> be enforced. By the manager? Absolutely not. One thing
> you can do is call a shop coding standards meeting and call
> for a vote. The important thing about a structuring standard
> is not that it be structured but that it be standard.
>
> Ross
> http://www.geocities.com/ross_klatte/
>
>
I'm not a manager (thank heavens!)... my title is "technical specialist"
(ie: a programmer with enough experience and pushiness to get to the top of
the heap of programmers in my team). And I do plan on bringing this up for
discussion.. I just wanted to see if anyone "out there" could give me some
good, coherent arguments for each side. Just trying to be prepared.
thanks much for your feedback. :-)
Lynn
William M. Klein
The use of NEXT SENTENCE in an IF statement that is terminated by an END-IF
is *NON* Standard - whether it is or is not "valid" COBOL, depends entirely
on the compiler vendor (and whether or not they have such an extension).
IBM and MERANT definitely *do* have (documented - and flagged if using
FLAGSTD) extensions allowing NEXT SENTENCE before END-IF (and END-SEARCH).
I believe that Realia also supports this extension. I am LESS certain about
AcuCOBOL, Liant, PerCOBOL, and Fujitsu.
In Richard's "original" note he started talking about it being "invalid
COBOL <sic> source code" but later on talks about it not being "flagged".
Any vendor that allows this syntax (as an extension) and does NOT flag it as
an extension is violating the ANSI/ISO ('85) Standard. However, any vendor
that DOES explicitly allow (and flag) this as an extension is FULLY ANSI
conforming.
P.S. The "classic" (confirmed by ANSI/J4) example of how to get around this
restriction and STILL be ANSI conforming is to code something like the
following:
Let's say you want to code:
Read ABC
At End
If A = "B"
Next Sentence
Else
Display "A doesn't equal 'B'"
End-IF *> this is non-standard
Not At End
Display "Not at end"
End-Read
Display "Still in same sentence"
.
Display "Next Sentence is here"
.
The way that you can code this EXACT same logic and be ANSI Standard is as
follows:
01 Next-Sentence-Flag Pic X Value "X".
...
Read ABC
At End
If Next-Sentence-Flag = "X"
If A = "B"
Next Sentence
Else
Display "A doesn't equal 'B'"
Else
Display "never executed"
End-IF *> this is now standard as the END-IF is not for the same
"IF"
*> as the NEXT SENTENCE
Not At End
Display "Not at end"
End-Read
Display "Still in same sentence"
.
Display "Next Sentence is here"
.
****
I do *not* recommend this 2nd approach as being "self-documenting" or not
"error-prone" - but it is ANSI/ISO conforming.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:3B1CE496...@brazee.net...
Lynn Randall
Joseph J Katnic <jos...@josephk.iinet.net.au> wrote in message
news:3b1ceb6b$0$73...@echo-01.iinet.net.au...
Yes.. that was my initial objection to using a priming read in the Init
paragraph. But the alternative is to start the Processing paragraph with a
Read and immediately follow it with an If statement, such as:
2000-Process
Perform 2010-Read
If file-eof
next sentence
esle
.... the entire main processing in the middle of the if ....
end-if.
I don't like having the entire logic of any paragraph buried in an IF
statement (this, I suspect, is merely personal preference); therefore, I
went to the priming read in the Init (I made that change years ago).
The other alternative... (this will start another religious debate)... is
to perform-thru-exit. Then you could have
"If file-eof,
goto 2000-exit".
And actually, I prefer perform-thru's for that reason. That means goto is
*only* used to goto the paragraph exit... I expect this to go away when we
get an "exit paragraph" verb added to Cobol. In this way, you could also
avoid the priming read.
Lynn
Lynn Randall
Lynn
Binyamin Dissen <post...@dissensoftware.com> wrote in message
news:burphtc9gffkd8vnn...@4ax.com...
Willem Clements
>
>2000-Process
> Perform 2010-Read
> If file-eof
> next sentence
> esle
> .... the entire main processing in the middle of the if ....
> end-if.
>
>I don't like having the entire logic of any paragraph buried in an IF
>statement (this, I suspect, is merely personal preference); therefore, I
>went to the priming read in the Init (I made that change years ago).
>
>The other alternative... (this will start another religious debate)... is
>to perform-thru-exit. Then you could have
>
>"If file-eof,
> goto 2000-exit".
>
> And actually, I prefer perform-thru's for that reason. That means goto is
>*only* used to goto the paragraph exit... I expect this to go away when we
>get an "exit paragraph" verb added to Cobol. In this way, you could also
>avoid the priming read.
>
>Lynn
Lynn,
Your PERFORM ..... UNTIL contains an implicit IF. You don't have to code it
Just code
PERFORM 2010-READ.
PERFORM 3000-PROCESS
UNTIL END-OF-FILE.
Richard Plinston
> > next sentence
> > else
> > Perform 2000-Process-Records
> > until file-eof
> > end-if
> >
> > You have coded a NEXT SENTENCE in an IF ... END-IF. This is invalid
> > Cobol code and a bug looking for a place to happen.
>
> While it probably is a bug, it is valid CoBOL code.
In the rules for IF in ANS85:
"If the END-IF phrase is specified, the NEXT SENTENCE phrase must not
be specified."
It is a compiler extension that allows these to be together in the same
IF statement.
There have been some who contrive a 'valid' structure where IFs are
nested and the innermost has a NEXT SENTENCE and the outer has END-IF in
order to defeat the rule and mix these just so they can 'punish' any
later programmer who may change the full-stops or naively add a
statement between the IF and the target full-stop in the expectation
they are outside the control of the IF.
This case, however is not even nested and thus is not valid standard
Cobol.
David P. Bretz
see no harm in putting the command in with the program logic. If there are a bunch of files to
be read or written, or if one file is read from more than one place in the program, then it
makes more sense to put it in a separate paragraph.
I think the important thing to remember when coding is that there is no hard and fast "rule"
for any situation. Sometimes, even something that may seem "illogical" may make perfect sense
in the context of a particular problem resolution. I've done things in programs I swore I'd
never do because to work around them was much more confusing and in the long run would have
made the program harder to maintain.
The only "rules" I go by when examining my programmer's code are:
1. Does it do what it's supposed to do?
2. Does it make sense?
3. Could I come back in a year and modify it easily?
Other than that, unless there is some glaringly inefficient or confusing code, I let them code
the way they want. About the only hard and fast rules I have are that every paragraph has to
be numbered and they paragraphs have to appear in numerical order in the program.
Dave
P.S. OH yes.............and meaningful data and paragraphs names.
Sff5ky
SkippyPB <swie...@neo.rr.com.nospam> writes:
>
>In your example, you only need to read the file in one place (process
>paragraph). What purpose does putting the read into a paragraph by
>itself then performing it, if that read is only needed for location?
>Is it more readable? Not necessarily. Is it more efficient.
>
Placing the access logic in a separate performed area, allows for changing
the access method/file structure without a major impact on the detail
processing.
I 'prefer' the style where the access logic for each file is separated into
individual paragraphs that can be performed from any area that needs
to 'touch' the file in some way. It sets up the code to permit reasonably
easy transition from standard COBOL file access verbs to CALL USING
syntax of external file handlers or whatever other destination may be
dreamed up in the future.
Lynn Randall
"other side". <g>
See below for more....
SkippyPB <swie...@neo.rr.com.nospam> wrote in message
news:DA048FC8927CDDE5.500B8062...@lp.airnews.net...
> On Tue, 05 Jun 2001 07:58:36 -0600, Howard Brazee <how...@brazee.net>
> enlightened us:
>
> >Tim Coffey wrote:
> >
> >> "Lynn Randall" <LERa...@yahoo.com> wrote in message
news:<3b1c3...@news1.prserv.net>...
> >>
> >> I`m a big fan of putting all I/O in "black boxes" (ie, separate
> >> paragraphs).
> >> For files with variant record types, each 'write' of a type would also
> >> get it's
> >> own paragraph. For VSAM files using direct/browsed retrieval, each
> >> kind of
> >> 'start/read' (full or partial key) would get it's own paragraph also.
> >
> >I have never been a fan of this, unless the I/O paragraph is large. I
would rather see the
> >line of code when I get to it in the logic than assume it to be correct.
>
> While I've used the style of having paragraphs that are performed for
> all I/O and each file in its own paragraph, I am reminded of what the
> prime directive of using a perform is. That is to group code that is
> used more than once in a program in one place to avoid duplication of
> code.
>
I'm not sure I agre with your assessment of "prime directive". Yes, "To
group code" -- that is the essence of cohesion... but "that is used more
than once..to avoid duplication"... I think not necessarily. It seems to
me that grouping code for the purpose of structure, thus making it easier to
understand and maintain, has merits on its own.
> In your example, you only need to read the file in one place (process
> paragraph). What purpose does putting the read into a paragraph by
> itself then performing it, if that read is only needed for location?
> Is it more readable? Not necessarily. Is it more efficient.
> Absolutely not (you're generating a store, and a branch and link to
> another location in your program which must also do a store and a
> branch and link to a location outside of your program then a restore
> then another branch).
>
Ahh.. processing efficiency... there, you've scored some points. That is
certainly a consideration, and I appreciate your perspective. However,
taken to an extreme, one could argue that fall-thru (and goto) logic is more
efficient than structured programming in general. Somewhere along the way,
you have to weigh the benefits of structure against what you give up in
efficiency. I'm guessing my threshhold for that trade-off is just a bit
different from yours. However, my original question was whether this was a
matter of "style" or "structure"; and by offering a cogent argument from the
"opposition", you've caused me to take a few more steps to the "style"
option. Thanks a bunch. <g>
> So you're writing in this style because it "looks" structured? Not a
> good reason.
>
Actually, I disagree (re: earlier comments). I think good structure (and
resulting ease of maintenance) is a good reason to write code a certain way.
thanks.... Lynn
Michael Mattias
news:9fj83e$g45$1...@slb7.atl.mindspring.net...
> Just to "end" the debate before it gets too heated,
Ooh, ooh, may I try, too?
SELECT ABC
FILE STATUS IS INPUT-FILE-STATUS
.....
01 FILE-STATII.
05 INPUT-FILE-STATUS PIC X(02).
88 INPUT-FILE-AT-END VALUE '10'.
...
[paragraph-name.]
Read ABC
IF INPUT-FILE-AT-END
badda bing
ELSE
badda bang
END-IF
MCM
Jerry P
"Lynn Randall" <LERa...@yahoo.com>
Maybe I'm missing something, but isn't the problem you describe one of
paragraph naming?
Original:
Perform 1000-Init.
Perform 2000-Read until file-eof.
Perform 9000-Quit
2000-Read
Read Input-file
not at-end Perform 3000-process
end-read.
vs.
Perform 1000-Init.
Perform 2000-Process until file-eof
Perform 9000-Quit
2000-Process.
Perform 3000-Read
If not file-eof
(do some things)
End-if.
3000-Read
Read (etc.)
The hierarchy difference seems: Is the read subordinate to the
processing or is the processing subordinate to the read? Inasmuch as
the processing code could have many elements under its control, I
would vote for the processing code to contain the read routine as a
subset. That is, the processing drives the reading rather than the
read driving the processing. To me this makes more logical sense, but
I suppose others may differ. There are those who are opposed to hot
water.
By the way, we preface paragraph numbers with a letter (i.e.,
"P1000-"). This makes them easier to 'Find,' although I suppose, now
that I think on it, that we COULD look for "1000-". Oh well.
Lynn Randall
to code when they were still required, there were no end-of-scope
terminators, and no "continue" verb. Also, as a woman, I find missing a
period to be very disconcerting. <G> But that's a discussion of a different
sort of "standard".
Anyway, I apologize to all for leaving off the periods in my example (and
indeed, for the poor coding in general), although I have found this
discussion interesting.
By the way, our compiler (IBM mainframe) option is set at NOFLAGSTD,
courtesy of our systems programmers. My guess is they didn't want all our
really old code to get flagged all over the place. Anyway, the way my
original example was coded (with NEXT SENTENCE in the IF statement before
the END-IF) goes through our compiler without a squawk -- does that make it
"existentially" valid (albeit buggy) COBOL?
ler.
William M. Klein <wmk...@nospam.ix.netcom.com> wrote in message
news:9fj83e$g45$1...@slb7.atl.mindspring.net...
> *> > "IF" as the NEXT SENTENCE
> Not At End
> Display "Not at end"
> End-Read
> Display "Still in same sentence"
> .
> Display "Next Sentence is here"
> .
>
> ****
>
> I do *not* recommend this 2nd approach as being "self-documenting" or not
> "error-prone" - but it is ANSI/ISO conforming.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Howard Brazee" <how...@brazee.net> wrote in message
> news:3B1CE496...@brazee.net...
> >
>snip<
DBuck
> At the risk of starting another religious discussion, I would like to
> solicit some opinions (the civil ones).
>
> In my job, I have the task of reviewing programs of my co-workers before
the
> programs are allowed to go to production. My expectations are for
> efficiency, understandability, adherence to standards, and maintainability
> (the "understandable" and "maintainable" requirements are admittedly
> related).
>
> Part of the "maintainabiliy", is creating "structured" programs. There
has
> already been a certain amount of philosophical discussion about
"structure"
> in recent days in this newsgroup; and I don't really want to rehash all
> that. I just would like some feedback on a couple of my "guidelines" -- I
> need to determine if I'm still looking for "structure", or if I've crossed
> the line to imposing my "style" upon my co-workers.
>
> Here is the current issue...
>
> When coding a read paragraph, is it appropriate to perform another
paragraph
> from within the Read? (Same question goes for Fetch paragraphs when
dealing
> with an SQL cursor).
>
I think that there are times when it is appropriate. Consider the
following:
0000-MAIN.
PERFORM 1000-INIT.
PERFORM 2000-READ-FILE UNTIL EOF.
PERFORM 9000-FINAL.
1000-INIT.
...
2000-READ-FILE.
READ INPUT-FILE INTO INPUT-RECORD
AT END
SET EOF TO TRUE
NOT AT END
PERFORM 3000-CHECK-STATUS
END-READ.
3000-CHECK-STATUS.
EVALUATE INPUT-STATUS
WHEN '00'
CONTINUE
WHEN
.... you get the picture ..
END-EVALUATE.
9000-FINAL.
...
In this example, the check file status paragraph was related to the read.
Therefore, I would consider it valid (although unnecessary)....
This is how I would code it...
0000-MAIN.
PERFORM 1000-INIT.
PERFORM 2000-READ-FILE.
PERFORM 3000-PROCESS-RECORDS UNTIL EOF.
PERFORM 9000-FINAL.
1000-INIT.
...
2000-READ-FILE.
READ INPUT-FILE INTO INPUT-RECORD
AT END
SET EOF TO TRUE
NOT AT END
check file status -- we always check our file status, don't
we????
END-READ.
3000-PROCESS-RECORDS.
...
PERFORM 2000-READ-FILE.
9000-FINAL.
...
> As you can see, one of my other "expectations" is that all paragraphs are
> numbered. Judging by the posts to this newsgroup, that also seems to be
out
> of vogue. Years ago, I would not have coded a priming read in the
> 1000-Init paragraph; but I was persuaded otherwise...
>
I tend to code the prime read in the main paragraph -- to make it stand out
a bit better. I also use numbered paragraphs. I don't think there is
anything wrong about not numbering the paragraphs - just my preference. To
me, it makes the paragraph easier to find within the program.
> I might add that, where COBOL is concerned, I am purely a mainframe
> programmer (though I have some training in VB, and web stuff). So stuff
> specific to Fujitsu or MicroFocus Cobol are of less interest to me.
>
> Thanks..
>
Oh, just as a note, the PERFORM until EOF will first check the end condition
(unless you specify WITH TEST AFTER), making the IF structure unnecessary...
James J. Gavan
Lynn Randall wrote:
> I should probably add that I always use periods. Mostly because I learned
> to code when they were still required, there were no end-of-scope
> terminators, and no "continue" verb. Also, as a woman, I find missing a
> period to be very disconcerting. <G> But that's a discussion of a different
> sort of "standard".
>
Well..... I did wunder. Thought perhaps maybe 'Lynn' was one of the guys. Had it
been 'Lynne', then definitely you're a lady <G>
Yes I also learned to code using full stops, (that avoids any ambiguity !), plus
of course miserable UPPERCASE only, even on the first desktops. But I hate red
tape and reduce my coding to as little as possible.
There are very few instances required for full stops in OO. The significant one
is if a method performs paragraphs, (i.e. paragraphs contained within the
method).
The last line before the next paragraph name must contain one or Net Express
will give me a compiler error, (unlike as Bill Klein just pointed out, IBM gives
you options and I think he said a warning flag for this one).
Jimmy
YukonMama
noted somewhere else so I won't reiterate) I really don't care as long as:
1) It does what it's supposed to do.
2) If by some chance it doesn't do what it is supposed to do at 2am I can
figure it out while still 1/2 asleep or
3) Figure it out in the morning after 1 cup of coffee.
Any program that requires 2 or more cups of coffee to be understood should be
rewritten.
Eileen
Russell Styles
>
<< snip >>
remember that it
will not get you out of a perform thru (unless you happen to be
in the
last paragraph anyway). Since I always have the last paragraph
contain
only an "EXIT" statement, that is not helpfull.
I suppose that the exit section verb might work, if you
can retrain your head around sections instead of paragraphs.
I have had best results by eliminating the perform thru. But
I don't really want to.
Lynn Randall
programmers tho... after all, what takes you and me only 1 cup of coffee to
figure out, might take a MAN several pots of coffee....
(although... given the poor quality of my original example code, I suppose
I'm not in a position to throw male-bashing stones...)
ler.
YukonMama <yuko...@aol.com> wrote in message
news:20010605231759...@ng-ca1.aol.com...
Thane Hubbell
<LERa...@yahoo.com> wrote:
In your original message you mentioned that you considered a perform
of a loop that then controlled another process to be potentially
unstructured - because a perform should handle only a single task.
I see nothing wrong with a loop like this:
Perform until all-done
Read input-file
at end
set all-done to true
not at end
perform process-the-record
End-Perform
when the "read loop" is the mainline function.
At any rate, a lot of this is a matter of preference, perception and
experience. The paragraph that triggers off other paragraphs that
might trigger off other paragraphs can still be considered "Single
funciton" paragraphs. You could have:
Perform Process-The-File
Then in Process-the-file
Perform Open-File
Perform Read-And-Do until End-of-File
Perform Close-Fille
Process-the-file performs only "process the file" function. Even
though it might have subroutines - that doesn't make it unstructured.
I'm not being critical, just sharing my observation. Additionally, I
don't use numbered paragraphs and don't see any reason to do so in
todays environemt where text searches are easy. If the argument is
that you want to be able to visualize the entire structure I would
argue that once you break it down into the individual routines, your
focus need only be on the individual section of code you are working
on and who cares what the number of the paragraph is.
This is simply preference, however.
Michael Mattias
> (although... given the poor quality of my original example code, I suppose
> I'm not in a position to throw male-bashing stones...)
Please do not use the words, "male", "stones" and "bashing" in the same
sentence.
MCM
Howard Brazee
Russell Styles wrote:
> I like the exit paragraph too, but it is important to
> remember that it
> will not get you out of a perform thru (unless you happen to be
> in the
> last paragraph anyway). Since I always have the last paragraph
> contain
> only an "EXIT" statement, that is not helpfull.
>
> I suppose that the exit section verb might work, if you
> can retrain your head around sections instead of paragraphs.
>
> I have had best results by eliminating the perform thru. But
> I don't really want to.
I don't really see any advantage in having an EXIT SECTION over a GO TO
THIS-SECTION-EXIT. If you have multiple paragraphs in a perform (why
else have a section), then you have drop through code. The EXIT
PARAGRAPH seems designed to facilitate getting rid of drop through
code. If someone moves to using the EXIT verb, why keep using sections?
William M. Klein
compiler option that allows you to "omit" the period before paragraph names.
HOWEVER, to use this feature, you must turn on A-/B-margin "checking" which
most NE users are HAPPY to get rid of.
("Logically" it is impossible for a compiler to BOTH get rid of A-/B-margin
restrictions and the requirement for periods before paragraph names. You
can get rid of either - as an extension to the '85 Standard - but not both
at the same time.)
--
Bill Klein
wmklein <at> ix.netcom.com
"James J. Gavan" <jjg...@home.com> wrote in message
news:3B1DA0AC...@home.com...
James J. Gavan
"William M. Klein" wrote:
> Jimmy - I think you will find that MERANT (NetExpress) actually has a
> compiler option that allows you to "omit" the period before paragraph names.
> HOWEVER, to use this feature, you must turn on A-/B-margin "checking" which
> most NE users are HAPPY to get rid of.
>
> ("Logically" it is impossible for a compiler to BOTH get rid of A-/B-margin
> restrictions and the requirement for periods before paragraph names. You
> can get rid of either - as an extension to the '85 Standard - but not both
> at the same time.)
Bill, thanks for the tip - but as I've said before I just DO NOT mess around
with default settings ! Having now delved into SQL - that's the first time
I've started using "$set..........", but that's obligatory for the pre-processor
to kick in.
Jimmy
cham...@lc.cc.il.us
>I have been lurking for a bit... but now I need some input...
>At the risk of starting another religious discussion, I would like to
>solicit some opinions (the civil ones).
>
>In my job, I have the task of reviewing programs of my co-workers before the
>programs are allowed to go to production. My expectations are for
>efficiency, understandability, adherence to standards, and maintainability
>(the "understandable" and "maintainable" requirements are admittedly
>related).
>
>Part of the "maintainabiliy", is creating "structured" programs. There has
>already been a certain amount of philosophical discussion about "structure"
>in recent days in this newsgroup; and I don't really want to rehash all
>that. I just would like some feedback on a couple of my "guidelines" -- I
>need to determine if I'm still looking for "structure", or if I've crossed
>the line to imposing my "style" upon my co-workers.
>
>Here is the current issue...
>
>When coding a read paragraph, is it appropriate to perform another paragraph
>from within the Read? (Same question goes for Fetch paragraphs when dealing
>with an SQL cursor).
>
>
>0000-Mainline.
> Perform 1000-Initialization
> Perform 2000-Read
> until file-eof
> Perform 9000-Finalization
>
>1000-Initialization.
> ... some init stuff..
>
>2000-Read
> Read Input-File into WS-Input-File
> at end
> not at end
>numbered. Judging by the posts to this newsgroup, that also seems to be out
>of vogue. Years ago, I would not have coded a priming read in the
>1000-Init paragraph; but I was persuaded otherwise...
>
>programmer (though I have some training in VB, and web stuff). So stuff
>specific to Fujitsu or MicroFocus Cobol are of less interest to me.
>
>Thanks..
>
>
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email ab...@newsone.net
cham...@lc.cc.il.us
writes:
>I have been lurking for a bit... but now I need some input...
>At the risk of starting another religious discussion, I would like to
>solicit some opinions (the civil ones).
>
you go ballistic maybe you should have an open meeting and discuss your
standards. Either that, or send everyone what you think is wrong or what
your key points are and solicit feedback. Then you can discuss why you
think the way you do. If I was told I couldn't do something a certain way I
would be asking for some kind of SOP or training manual or an example book or
something. You could take the program in question and rewrite it the way you
think it should be written and then use it as an example for a training
session. You can not enforce a standard you have not established and train
the programmers to adhere to. The standard has to be established before it
can be enforced.
Richard Plinston
>
> Jimmy - I think you will find that MERANT (NetExpress) actually has a
> compiler option that allows you to "omit" the period before paragraph names.
But why would you want to (unless you have a whole load of source where
the programmers relied on this dubious non-standard 'feature'). It
doesn't 'defeat' the NEXT SENTENCE going to the end of the current
paragraph because the 'next full stop' is on the paragraph name.
It would be preferable to process the source to make it 'valid COBOL',
using, say, a PERL or Python script (or even ReXX).
Tom McFarland
"Howard Brazee" <how...@brazee.net <mailto:how...@brazee.net>> wrote in
bad idea
> to stop using full stop periods and continue to use NEXT SENTENCE. Since
I use a
> pre-compiler which automatically inserts NEXT SENTENCE in its IDMS
commands, I am
> not even tempted to remove periods from my coding style.
>
Howard,
While I only lurk here occasionally, I've seen you make this statement
before
about the IDMS pre-compiler. I've never seen the IDMS precompiler insert
NEXT SENTENCE (or even CONTINUE) in the code generated for the calls. Can
you provide an example? What versions of IDMS & COBOL are you using?
Batch/DC/CICS?
I've been period-less (except for ending paragraphs) for several years in
many IDMS shops without incident.
Tom McFarland
Thane Hubbell
the deal.....
First-Section Section.
...
...
Sect-Exit. Exit.
Second-Section Section.
...
...
Sect-Exit. Exit.
Third-Section Section.
...
...
Sect-Exit. Exit.
When one performs any of these sections one may, anywhere in any
section, code : Go To Sect-Exit.
This will cause you to exit the present section WITHOUT "fall through"
code - and has existed for a long time. This is the functionality
more formally supported in the next standard by "Exit Section" - with
the addition fo Exit Paragraph, etc.
I agree with Howard - this type of Section construct will no longer be
necessary, but I wanted to show how it could be done today (And 20+
years ago) using standard COBOL.
On Wed, 06 Jun 2001 07:16:23 -0600, Howard Brazee <how...@brazee.net>
wrote:
Russell Styles
"Howard Brazee" <how...@brazee.net> wrote in message
news:3B1E2D27...@brazee.net...
When
I do this, I can get everything, the open, the close, and the
loop in one
locical area, with a perform thru. I am carefull to insure that
all paragraphs
in this perform range start the same (Ie DOIT, DOIT-LOOP,
DOIT-END, DOIT-X).
I also insure that nobody uses any of these paragraphs in any
other manner.
No, it is not idiot proof. Yes, there are many other ways to
do it, and
some may well be better in some ways. My complaint was that if
you are in a
perform thru, the EXIT PARAGRAPH only exits the current
paragraph, not
the entire range, and EXIT PERFORM is not legal.
Frankly, I don't trust myself enough to risk using a perform
section.
Howard Brazee
Tom McFarland wrote:
I just checked - all of my supplied NEXT SENTENCE are in IDMS COPY
statements. These could easily be fixed.
But the precompiler still does create IF logic without END-IF. I suppose it
is possible to understand what the generated statements will be sufficiently
to put the correct number of END-IF statements after an IDMS command, but it
makes it easier for a new maintenance programmer to see a full stop period.
Illustrating for non IDMS programmers:
Source code:
****** HJBDEBUG START
OBTAIN CALC IABRCAA
ON ANY-ERROR-STATUS
DISPLAY 'SKIPPING ' FINDER-ID ' NOT FOUND' (yes, I know this
doesn't make sense)
IF IABRCAA-IABRCBD EMPTY
DISPLAY 'IABRCAA-EMPTY'
****** HJBDEBUG END
Generated code:
****** HJBDEBUG START
* OBTAIN CALC IABRCAA
* ON ANY-ERROR-STATUS
MOVE 8 TO DML-SEQUENCE
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (32)
SR1406
IDBMSCOM (43)
IF NOT ANY-ERROR-STATUS PERFORM IDMS-STATUS;
ELSE
DISPLAY 'SKIPPING ' FINDER-ID ' NOT FOUND'
* IF IABRCAA-IABRCBD EMPTY
MOVE 9 TO DML-SEQUENCE
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (64)
IABRCAA-IABRCBD;
IF ERROR-STATUS EQUAL TO '0000'
DISPLAY 'IABRCAA-EMPTY'
****** HJBDEBUG END
Obviously, the lack of generated END-IFs mean that this above code isn't what
was wanted.
We could change shop standards so that the status checking isn't implicit - If
you're using periodless code, your standards have to proscribe the use of
AUTOSTATUS and ON statements.
The use of full stop periods though mean the commands will work no matter what
standards are applied. That is a big advantage, where I haven't seen any
particular advantage to leaving periods out.
Tony
I wanna try too. ;']
SELECT ABC
...
[paragraph-name.]
READ ABC
AT END
BADDA BANG
NOT AT END
BADDA BING
END-READ
>
>
>MCM
>
>
>
Thanks,
Tony
===================================
Should have been easy, but its golf
===================================
"A day without hitting golf balls,
is a day longer to getting better"
- Hennie Bogan
"Hogan was really talkative today.
Yeah? What'd he say? You're still
out!"
===================================
Howard Brazee
>
> >[paragraph-name.]
> > Read ABC
> > IF INPUT-FILE-AT-END
> > badda bing
> >ELSE
> > badda bang
> >END-IF
>
> I wanna try too. ;']
>
> SELECT ABC
> ...
> [paragraph-name.]
> READ ABC
> AT END
> BADDA BANG
> NOT AT END
> BADDA BING
> END-READ
So you guys can't agree on whether to bing or to bang?
James J. Gavan
Howard Brazee wrote:
>
> The use of full stop periods though mean the commands will work no matter what
> standards are applied. That is a big advantage, where I haven't seen any
> particular advantage to leaving periods out.
Hey that's neat. As a result of Lynn's monthly cycles have we now coined a new
Anglo/American programming phrase :-
full stop period <G>
Jimmy
Michael Mattias
Howard Brazee <how...@brazee.net> wrote in message
news:3B1FA4EA...@brazee.net...
>
> So you guys can't agree on whether to bing or to bang?
Do I gets my druthers?
MCM
Tom McFarland
Howard Brazee <how...@brazee.net> wrote in message
news:3B1F80D1...@brazee.net...
There is no mystery as to the number of END-IFs that would be required to
terminate the IDMS ON. It's 1. If any more are required, it's because
there is/are additional programmer coded IFs subordinate to the ON.
The precompiler never inserts terminating logic for the generated IF-ELSE
statement. It uses whatever you use to terminate the IDMS ON statement. So
if you terminate it with an END-IF, that's what you'll get. If you
terminate with a period, you'll get a period.
code this:
OBTAIN CALC CUSTOMER-RECORD
ON DB-REC-NOT-FOUND
imperative statement
END-IF
and you will get:
* OBTAIN CALC CUSTOMER-RECORD
* ON DB-REC-NOT-FOUND
CALL 'IDMS' USING etc
IF NOT DB-REC-NOT-FOUND ----generated
PERFORM IDMS-STATUS ---generated
ELSE ---generated
imperative statement ---your code
END-IF ---your code
Replace the END-IF with a period, and the resultant IF-ELSE will end with a
period.
Not sure I understand your example, but if you didn't want the IDMS IF to be
subordinate to the ON, then that's just a coding error, not a compiler
unpredictability issue.
> We could change shop standards so that the status checking isn't
implicit - If
> you're using periodless code, your standards have to proscribe the use of
> AUTOSTATUS and ON statements.
Not at all. This duscussion would be moot if we weren't assuming the use of
AUTOSTATUS.
> The use of full stop periods though mean the commands will work no matter
what
> standards are applied. That is a big advantage, where I haven't seen any
> particular advantage to leaving periods out.
I don't wan't to get into a religious war on the use or non-use of periods,
but using them in every case to terminate your IDMS calls kind of prevents
you from coding any IDMS statements at any level you choose within a nested
IF structure. Obviously, if you have shop standards that require you to use
copied code containing NEXT SENTENCE, your options are limited. But it's
definitely not the pre-compiler's fault.
Tom McFarland
Richard Plinston
> full stop period <G>
I never did understand why the Americans [mis]used the term 'period' to
refer the full-stop.
With every other usage of the word period, such as 'historical period'
or 'musical period' this refers to the content or time from the start to
the end. The 'period of a sentence of words' should be 'from the first
word to the last' just as the 'period of a prison sentence' refers to
the 'first day to the last'.
Yet Americans use 'period' to refer to the character that lies beyond
'the period of the sentence', the character that stops the sentence, the
full-stop.
(it is a full stop because a comma, semi-colon or colon are only partial
stops).
Robaire
<rip...@Azonic.co.nz> a écrit:
F.Y.I. ( and quite off topic )
I won't deny that Americans (and anglophone Canadians, for that
matter) favour the word "period" over "full stop" but, in this case,
that doesn't mean it is incorrect usage.
The Concise Oxford Dictionary 7th ed. describes the period as "6. full
pause at end of sentence; =FULL stop..."
"Modern American Usage" (Wilson Follett, 1966) describes "THE PERIOD"
in a 20+ line paragraph without ever mentioning the expression full
stop.
R. Miller
_______________________________
Do people who prefer their spaghetti " al dante " (sic)
also prefer their lasagna " al inferno " ?
cham...@lc.cc.il.us
>James J. Gavan wrote:
>
>> full stop period <G>
>
>I never did understand why the Americans [mis]used the term 'period' to
>refer the full-stop.
>
However I can not seem to locate the term "FULL STOP" anywhere in my IBM COBOL
manual.
The definition in my IBM manual of a "STATEMENT" says it is one or more
commands ending with a separator period.
I don't know where the term "FULL STOP" originates is it in the COBOL
Standard?
Where does the term originate?
COBOL is suppose to be a language that is readable. In other words, if it is
readable you would end any command just like a sentence with a period.
NA
Robaire <rmi...@linux.ca> wrote:
>Le Fri, 08 Jun 2001 16:58:31 +0100, Richard Plinston
><rip...@Azonic.co.nz> a écrit:
>
>>James J. Gavan wrote:
>>
>>> full stop period <G>
>>
>>I never did understand why the Americans [mis]used the term 'period' to
>>refer the full-stop.
[snippage]
>The Concise Oxford Dictionary 7th ed. describes the period as "6. full
>pause at end of sentence; =FULL stop..."
The not-Concise OED gives, from
--begin quoted text:
11. a. A full pause such as is properly made at the end of a sentence.
b. The point or character that marks the end of a complete sentence; a
full stop (.).
1609 J. DAVIES Holy Roode (1878) 20/2 No Commaes but thy Stripes; no
Periods But thy Nailes. 1612 BRINSLEY Lud. Lit. 95 In reading, that he
[the scholar] doe it distinctly, reading to a Period or full point, and
there to stay.
--end quoted text
Both these citings appear to antedate anything which might accurately be
labelled 'American' use.
DD
James J. Gavan
Robaire wrote:
> >> full stop period <G>
> >
> >Yet Americans use 'period' to refer to the character that lies beyond
> >'the period of the sentence', the character that stops the sentence, the
> >full-stop.
> >
> >(it is a full stop because a comma, semi-colon or colon are only partial
> >stops).
>
> F.Y.I. ( and quite off topic )
>
> I won't deny that Americans (and anglophone Canadians, for that
> matter) favour the word "period" over "full stop" but, in this case,
> that doesn't mean it is incorrect usage.
>
Well be careful of that phrase 'anglophone Canadians' - I would use
'Americanized Canadians' due to the fact that I'm told the majority of our
schoolbooks are printed in the U.S. Here in Calgary you will see signs to
the local shopping mall "South Center Mall" or "South Centre Mall".
Seems like we really don't know 'which way is up' - we should - seeing as we
mockingly refer to ourselves as the Great White North <G>
Jimmy
PS: Just so long as we don't let 'em print our history books. Haven't seen
it, but a lady some ten years younger than me was very disappointed with
'Pearl Harbor', note deference to our "cousins" - 'Harbour'. (When in
Rome.....).
A THREE hour film about a spectacular ONE hour air attack First hour devoted
to our two heroes who had the hots for the same heroine. The actual 'battle'
filming was spectacular. Then, (my friend's observation), they spoiled it by
including a US attack on Japan - I'm assuming this was the sixteen Jimmy
Doolittle B25-Mitchells taking off from aircraft carriers - in April 1942.
This appeared to add a 'jingoistic' flavour to the film.
Pity - so far as I'm concerned, and am aware, Holywood had already produced
two balanced and excellent movies, "Tora, Tora, Tora" and "Midway". And FDR's
famous words to Congress still echo down the passages of time.
Richard Plinston
> COBOL is suppose to be a language that is readable. In other words, if it is
> readable you would end any command just like a sentence with a period.
Do you mean like this: ?
ADD 1 TO LINE-COUNT.
IF LINE-COUNT GREATER THAN 55
THEN MOVE PAGE-END-TEXT TO PRINT-LINE.
WRITE PRINT-LINE BEFORE PAGE.
MOVE 1 TO LINE-COUNT.
MOVE PAGE-HEAD TO PRINT-LINE.
etc
What you probably mean is that you would 'end any command [sic] .. with
a period (full-stop)' except in conditions where this wouldn't work.
The use of the full-stop in Cobol is flawed. It was intended to make
the language more English-like, but unlike the use of the semi-colon in
C as a statement separator, it also is used as a means of terminating
blocks of code, such as in the IF statement. In C blocks are surrounded
by curly braces {}, in Pascal they use BEGIN .. END (but the language is
broken too because the semi-colon is statement a terminator not a
separator).
Because the full-stop terminates the conditional statement it means that
the rules of use should vary depending on whether it is in a conditional
or out of it. If it becomes necessary to change some code, or copy it,
to be under the control of an IF then all the full-stops must be
removed, conversely if the IF can be removed then you add all the
full-stops back.
This always seemed to me to in the class of: 'if you don't know what you
are doing then do it neatly'.
If the English sentence structure had been done properly in the first
place there would be mechanisms to indicate blocks of code as is done
with BEGIN .. END in Pascal. I will call these blocks 'paragraphs' and
what is now paragraphs should be called 'chapters', with chapter
headings (labels). Paragraph ends are indicated by blank lines. Then we
would have the much more English like:
ADD 1 TO LINE-COUNT.
IF LINE-COUNT GREATER THAN 55 THEN MOVE PAGE-END-TEXT
TO PRINT-LINE. WRITE PRINT-LINE BEFORE PAGE. MOVE 1
TO LINE-COUNT. MOVE PAGE-HEAD TO PRINT-LINE. WRITE
PRINT-LINE BEFORE 1.
< end of IF 'paragraph'
WRITE DATA-LINE FROM PRINT-LINE BEFORE 1.
This doesn't make it more readable to me, how about you ?
Richard Plinston
>
> >I never did understand why the Americans [mis]used the term 'period' to
> >refer the full-stop.
>
> I won't deny that Americans (and anglophone Canadians, for that
> matter) favour the word "period" over "full stop" but, in this case,
> that doesn't mean it is incorrect usage.
>
> The Concise Oxford Dictionary 7th ed. describes the period as "6. full
> pause at end of sentence; =FULL stop..."
So, perhaps it is 'the period of the pause'. That is, the use of some
punctuation is to indicate where pauses should be placed when speaking
the words and how long thay should be (I don't think that schools teach
this anymore).
The '.' indicates a 'long period pause' and the ',' indicates a short
period pause.
> "Modern American Usage" (Wilson Follett, 1966) describes "THE PERIOD"
> in a 20+ line paragraph without ever mentioning the expression full
> stop.
No, it wouldn't.
Richard Plinston
>
> 1609 J. DAVIES Holy Roode (1878) 20/2 No Commaes but thy Stripes; no
> Periods But thy Nailes. 1612 BRINSLEY Lud. Lit. 95 In reading, that he
> [the scholar] doe it distinctly, reading to a Period or full point, and
> there to stay.
> Both these citings appear to antedate anything which might accurately be
> labelled 'American' use.
Yes, of course. I should have realised that it was archaic English (in
England).
Quite a number of 'Americanisms', or 'Australianisms', or similar were
actually common usage in the country of origin of the immigrants at the
time they left. England (and some other Europeans) have always evolved
their language, which is why we no longer speak middle-English or
Normandy-French.
James J. Gavan
Richard Plinston wrote:
Still off topic - but it can be fascinating.
As an extension to that regarding the former colonies - they don't have any
problem with GLOUCESTER in New England, like you and me they *know* all about
Dr. Foster. Also in New Hampshire they pronounce PORTSM'TH the same way I do.
I was initially puzzled when I first came over here why our American friends
pronounce it 'erbs as opposed to herbs - logic it's the Cockneys who are
supposed to drop their 'aitches'. Alistair Cooke on PBS Masterpiece Theatre
wised me up - seems the they took the word directly from the French whereas we
anglicized it.
Richard, you may not know about PBS/Masterpiece Theatre, but recall the BBC's
weekly "Letter from America" - might still be done, but I'm reckoning he has
to be in his 90s by now, if still alive. Now a US citizen, apart from
Churchill, he was the only other Brit given the distinction of addressing the
US Congress. Still even Alistair made boo-boos, said Charles Dickens was born
in Chatham, (where his dad moved for work) - correction - Commercial Road,
Portsmouth; still a museum.
Quiz time - any takers ? Guess how this (Norman French) is pronounced in
England - Hatch Beauchamp. Boy! Did I get stuck once here in Calgary. I asked
the girl bean counters, "Who has the ledger sheets for Dauphin ?" Blank looks,
then, "Oh, you mean Dolfin".
You shouldn't be wasting your time programming if you know the origin of this
street name I once lived in - Amwell Street, Islington, N.London - believe it
or not 'Amwell' is corrupted from three words ! (Clues for Bill - the English
were much more into religion in the Middle Ages, and remember telling me
"Repeat after me, it is...... <G>).
Jimmy.
Ross Klatte
>Date: 2001-06-09 03:04 Eastern Daylight Time
>So, perhaps it is 'the period of the pause'. That is, the use of some
>punctuation is to indicate where pauses should be placed when speaking
>the words and how long thay should be (I don't think that schools teach
>this anymore).
>
>The '.' indicates a 'long period pause' and the ',' indicates a short
>period pause.
>
Personally, I like the recent introduction of the term "dot" for the
little round punctuation mark that has so many overloaded
constructors.
What do the British call the dots in St. Ives, or Mr. Ed,
or N. Ireland, or 3.14, or...?
Drifting off topic for this newsgroup, which is supposed to
be limited to critical analysis of British misusage of the
American language, one poster mentioned alternate
spellings of "centre" or "center" in shopping malls as
meaningful. I don't think shopping malls, stores, or pricey
specialty shoppes are a good source of spelling information.
A local mall calls itself "Pointe West." (I suppose our
British friends would have this as "Full Stoppe West.")
Ross
http://www.geocities.com/ross_klatte/
James J. Gavan
Ross Klatte wrote:
>
> Personally, I like the recent introduction of the term "dot" for the
> little round punctuation mark that has so many overloaded
> constructors.
> What do the British call the dots in St. Ives, or Mr. Ed,
> or N. Ireland, or 3.14, or...?
>
Dunno - but 'decimal point' for the last one <G> Having visited Canada in
'74 and returned home, a business acquaintance sent me a letter. The little
lass who typed it, assumed it made far more sense to address it, "Creech
Street Michael, Taunton', rather than "Creech St. Michael, Taunton".
>
> Drifting off topic for this newsgroup, which is supposed to
> be limited to critical analysis of British misusage of the
> American language, one poster mentioned alternate
> spellings of "centre" or "center" in shopping malls as
> meaningful. I don't think shopping malls, stores, or pricey
> specialty shoppes are a good source of spelling information.
> A local mall calls itself "Pointe West." (I suppose our
> British friends would have this as "Full Stoppe West.")
>
Hey the Centre/Center bit ISN'T the retailers - it's the City's road sign
department !
Or you could say General Douglas McArthur did his cadet training at West
Full Stop <G>
Richard Plinston
>
> >So, perhaps it is 'the period of the pause'.
>
> What do the British call the dots in St. Ives, or Mr. Ed,
> or N. Ireland, or 3.14, or...?
Well they certainly are not 'periods', or 'full stops', in the sense of
creating a pause.
> Drifting off topic for this newsgroup, which is supposed to
> be limited to critical analysis of British misusage of the
> American language, one poster mentioned alternate
> spellings of "centre" or "center" in shopping malls as
> meaningful.
Here in the antipodes we officially don't really care which spelling is
used. I myself will use alternates as I see fit. If a particular place
is called 'center', or 'centre' then that is its name and that is how it
should be spelt. It can use 'sentre' if it chooses.
Stephen J Spiro
>
> When coding a read paragraph, is it appropriate to perform another paragraph
> from within the Read? (Same question goes for Fetch paragraphs when dealing
> with an SQL cursor).
>
> For example:
>
> 0000-Mainline.
> Perform 1000-Initialization
> Perform 2000-Read
> until file-eof
> Perform 9000-Finalization
>
> 1000-Initialization.
> ... some init stuff..
>
> 2000-Read
> Read Input-File into WS-Input-File
> at end
> set file-eof to true
> not at end
> Perform 3000-Process-records
> end-read
>
> 3000-Process-records
> ... main processing logic here...
>
> 9000-Finalization
> ... control totals, etc. here....
>
This is essentially the way I would do it, with one serious exception.
NOT AT END works ONLY if there is a successful READ. Unless you are
using DECLARATIVES (which are absolutely non-structured), there is no
provision for error-recovery. Testing the file status (even for
sequential files) provides for more structured code.
Additionally, there is the issue that use of AT END ... NOT AT END
makes the processing subordinate to the READ, which bothered a number
of people conceptually (including Ms Randall), particularly the OO
programmers. Using file statuses makes the syntax agree with concept.
2000-READ-AND-PROCESS.
READ INPUT FILE INTO WS-INPUT-FILE.
* (this is the first "process" at this level. There is
* no need
* to perform a paragraph containing only one statement.
* This single statement would be diagrammed as a
"module"
* just as much as a performed routine.)
* (Note that if the sequential READ were to be changed to
* a different kind of access, this single statement
could
* easily be replaced with a different sentence or even a
* PERFORM statement.)
EVALUATE INPUT-FILE-STATUS
WHEN '00'
PERFORM 3000-PROCESS-RECORDS
THRU 3000-EXIT
WHEN '10'
* (at end)
CONTINUE
WHEN OTHER
go to or perform exception/abend processing
END-EVALUATE.
* (this is the second "process" at this level. The
* CONTINUE will fall thru to the paragraph end or
* an explicit EXIT.)
* (Note that if the sequential READ were to be changed
* to a different kind of access, structure still
* contains the complete processing logic, even tho
* the codes may have to be changed.)
*-------------------- related rant ---------------------
CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
which have already implemented this "feature". DON'T DO IT!
EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
tell them to get rid of these abominations before they get into the
new official standard!
*-------------------- END-RANT ---------------------
Stephen J Spiro
Wizard Systems
PS: HEY! YOU could be on the J4 Committee and help our language!
E-mail me!
James J. Gavan
Stephen J Spiro wrote:
> This is essentially the way I would do it, with one serious exception.
>
> NOT AT END works ONLY if there is a successful READ. Unless you are
> using DECLARATIVES (which are absolutely non-structured), there is no
Well I agree with you about the DECLARATIVES - but watch it ! Bill is big fan of
Declaratives <G>. As regards the intended list of Exception Conditions (120 plus ?) -
no comment. I'll await their arrival, and when I've coded - then make comment.
>
> provision for error-recovery. Testing the file status (even for
> sequential files) provides for more structured code.
> Additionally, there is the issue that use of AT END ... NOT AT END
> makes the processing subordinate to the READ, which bothered a number
> of people conceptually (including Ms Randall), particularly the OO
> programmers. Using file statuses makes the syntax agree with concept.
As regards OO - how about a 'belt and braces approach' :-
*>--------------------------------------------------------------
Method-ID. "access-file".
*>--------------------------------------------------------------
input-output section.
copy "clients1.cpy" replacing ==(tag)== by ==Data==.
File Section.
FD Data-File.
01 Data-record.
copy "clients2.cpy" replacing ==(tag)== by ==Data==.
Linkage Section.
copy "fileactn.cpy".
01 lnk-PrimeKey pic x(06).
01 lnk-result pic x(4) comp-5.
Procedure Division Using file-action
lnk-PrimeKey
returning lnk-result.
set file-result-ok to true
initialize ws-Error-Data
Evaluate TRUE
When read-PrimeKey
move lnk-PrimeKey to Data-PrimeKey
Read Data-File
Invalid key
Set record-not-found to True
Not invalid key
Move Data-record to os-record
End-Read
When read-next
.......
When start-PrimeKey
........
When etc.......
......
When other
invoke super "invalid-action" using file-action
set file-error to true
End-evaluate
if ws-filestatus <> "00"
move os-PrimeKey to ws-error-key
move os-Shortname to ws-error-name
invoke super "check-file-status"
using ws-ErrorFields
file-action
ws-file-result
returning lnk-result
else move ws-file-result to lnk-result
End-if
End Method "access-file".
*>--------------------------------------------------------------
The above is old code, and thanks to my good friend Mr. Hubbell , inclusion of file
definition in methods is now a No-No ! Same applies to Declaratives. (But Thane's
reasoning was sound).
Reviewing that code above I would now break it out into separate methods per type of
file access; then I can zero-in more closely on the file-status associated with the
particular file VERB. I think you could interpret the phrase "break it out into separate
methods" as being the non-OO parlance, 'more structured'.
Jimmy
Liam Devlin
>
> On Tue, 5 Jun 2001 11:26:56 -0700, "Lynn Randall"
> <LERa...@yahoo.com> wrote:
> In your original message you mentioned that you considered a perform
> of a loop that then controlled another process to be potentially
> unstructured - because a perform should handle only a single task.
>
> I see nothing wrong with a loop like this:
>
> Perform until all-done
> Read input-file
> at end
> set all-done to true
> not at end
> perform process-the-record
> End-Perform
>
> when the "read loop" is the mainline function.
Thane, I'm with you. I really don't see any need for the older ways of
coding read loops since the '85 standard was implemented because the
READ is now a balanced construct, before all we had was the "at end"
clause which is what lead to the other solutions, e.g., priming reads,
etc.
As always, YMMV,
LiamD
Liam Devlin
>
(snip)
> > >
> > The above is harder to immediately understand as you have
> > to notice that the Intialization does a read before you
> > can understand why a test for EOF is done after Initializtion.
>
> Yes.. that was my initial objection to using a priming read in the Init
> paragraph. But the alternative is to start the Processing paragraph with a
> Read and immediately follow it with an If statement, such as:
>
> 2000-Process
> Perform 2010-Read
> If file-eof
> next sentence
> esle
> .... the entire main processing in the middle of the if ....
> end-if.
See Thane's post from 06 Jun 2001, at 7:08 GMT. It's no longer necessary
to code READ loops this way and, IMHO, it's a bad idea to continue to do
so.
LiamD
Liam Devlin
>
(snip)
>
> I expect that this was a slip-up ( admittedly a nasty one to detect )-
> that the author would have written CONTINUE, instead of NEXT SENTENCE.
> I suppose that the author will address this eventually.
>
> CONTINUE would have been syntactically and logically acceptable here;
> I also expect that another religious war will be started ( déjà-vu? )
> concerning the use of CONTINUE versus negating the condition in the IF
> test.
I work with a great number of people who stubbornly code NEXT SENTENCE
instead of CONTINUE even though they're coding END-IF nowadays. They're
probably lucking out because they're also coding periods everywhere they
can.
LiamD
Liam Devlin
>
(snip)
>
>
> Quiz time - any takers ? Guess how this (Norman French) is pronounced in
> England - Hatch Beauchamp.
"aitch beecham"? ("hatch" just seems way too obvious)
Well?
LiamD
Liam Devlin
> > (although... given the poor quality of my original example code, I suppose
> > I'm not in a position to throw male-bashing stones...)
>
> Please do not use the words, "male", "stones" and "bashing" in the same
> sentence.
>
> MCM
Right! <shudder>
James J. Gavan
Liam Devlin wrote:
Bloody good guess Liam. Comes out 'HATCH BEECHAM'. One of the UK
pharmaceutical firms was/is called Beechams - fair bet it started out as
Beauchanmp - might even have ben an 's' on the end. With those weirdos that
occur in UK, the name Auchinleck comes out 'AFFLECK'. There are family members
who use the spelling 'Affleck'.
Now when it comes to Celtic names, even with roots back to the 'Auld Sod' - I
get real tounge-tied. So how does your first name come out phonetically., (I
prefer Christian name - but what the hell). I'd been inclined to say LEE-AM
but I suspect it's more like L'EEM.
Jimmy (Seamus if you like <G>).
Richard Plinston
>
> 2000-READ-AND-PROCESS.
> READ INPUT FILE INTO WS-INPUT-FILE.
> WHEN '00'
> PERFORM 3000-PROCESS-RECORDS
> THRU 3000-EXIT
Just one tiny criticism. They may be (in fact are) cases were a valid
[sic] read returns a status that is not '00'. For example an indexed
file with a duplicate key being read sequentially may give a status of
'02' to indicate that the next record has the same key.
It is important to only check the first byte for being zero as a means
of detecting successful reads.
> *-------------------- related rant ---------------------
>
> CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
> which have already implemented this "feature". DON'T DO IT!
> EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
> GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
> tell them to get rid of these abominations before they get into the
> new official standard!
>
> *-------------------- END-RANT ---------------------
I quite agree.
However, you used an example of:
> PERFORM 3000-PROCESS-RECORDS
> THRU 3000-EXIT
Now the _only_ point of doing a PERFORM THRU (or a PERFORM SECTION) is
to allow for using GO TOs (explanation available upon request), so I
don't know if your objection to EXIT-something is because it is a GO TO
or because it is disguised.
Tim Scrivens
"James J. Gavan" <jjg...@home.com> wrote in message
news:3B240F19...@home.com...
How about some of the old standards, name-wise
Chomondoley
Coughtry (5 pronunciations)
Dondall
even Powell
James J. Gavan
Richard Plinston wrote:
For Stephen - not you Richard <G>
> > *-------------------- related rant ---------------------
> >
> > CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
> > which have already implemented this "feature". DON'T DO IT!
> > EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
> > GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
> > tell them to get rid of these abominations before they get into the
> > new official standard!
> >
> > *-------------------- END-RANT ---------------------
>
I only read your 'rant' in detail as a result of Richard's message. Might be
the case in non-OO, but for OO I would say you are out to lunch <G>
Given that a method is a 'mini-program' - I regularly use EXIT PERFORM and
my equivalent of your EXIT PARAGRAPH/EXIT SECTION is the OO EXIT METHOD. .
Again OO-wise, why loop through a Perform if you can jump out immediately on
a given condition. Same with the EXIT METHOD.
EXIT METHOD and EXIT PERFORM (depending on how you have coded for the
latter), get you directly to END METHOD - and you are out of there !
(Thane's on record - he LUVS the Exit Method).
Stephen, as and when UDFs(User Defined Functions) become available with
mainframe compilers - would you still contend your No-No approach is valid ?
I'm only aware of UDFs in passing as they have no application to me in OO -
but I would have thought EXIT PERFORM was just as valid. I'm pretty sure
there isn't an EXIT FUNCTION - might have been a nice feature.
PS:
Did search CD 1.10 to try and confirm about the UDF format, but gave up in
frustration - I know you guys are used to it, but how I hate that document
when attempting to zero-in on something - and that crappy Acrobat 'Search
Box" rather than a simple F3 (forward) or F4(backwards) to repeat the
search. I suppose, other than currently conforming to ISO format, the actual
document presentation has existed since time immemorial. I just think
somebody should hand this one over to a bunch of technical writers with NO
PROGRAMMING experience and get their reactions.
Of course, I could make EXACTLY the same comments about Vendors' on-line
help - i.e. use a bunch of computer illiterates and you might just finish up
with something that is literate !
(Don't use WMK - he's already 'confessed' to performing as a technical
writer - but with prior computer knowledge <G>)
Jimmy
James J. Gavan
Tim Scrivens wrote:
Still off topic :
> How about some of the old standards, name-wise
>
> Chomondoley
> Coughtry (5 pronunciations)
> Dondall
> even Powell
Yes Chomondoley = Chumley. But guess you kinda got me on the rest, don't recall
them. The only reference I can think of is the Boy Scout founder "My name is
Baden-Powell as in Garden Trowel" - but there he's stressing the German origin.
Just thought - there's always Featherstonhaugh = Fanshaw. I knew a Univac
salesman here in Calgary who was unaware it came out Fanshaw - still pronounced
it as officially written. I suppose it was enough of a challenge, that having
mentally noted it, people ALWAYS wrote/typed his surname correctly !
Jimmy.
Arnold Trembley
>
> How about some of the old standards, name-wise
>
> Chomondoley
> Coughtry (5 pronunciations)
> Dondall
> even Powell
Cholmondoley = Chumley? Sounds like a P.G. Wodehouse festival.
How do you pronounce Mainwaring?
Howard Brazee
> I work with a great number of people who stubbornly code NEXT SENTENCE
> instead of CONTINUE even though they're coding END-IF nowadays. They're
> probably lucking out because they're also coding periods everywhere they
> can.
>
> LiamD
Do they state any reasons for using NEXT SENTENCE?
Howard Brazee
Stephen J Spiro wrote:
> This is essentially the way I would do it, with one serious exception.
>
> NOT AT END works ONLY if there is a successful READ. Unless you are
> using DECLARATIVES (which are absolutely non-structured), there is no
> provision for error-recovery. Testing the file status (even for
> sequential files) provides for more structured code.
> Additionally, there is the issue that use of AT END ... NOT AT END
> makes the processing subordinate to the READ, which bothered a number
> of people conceptually (including Ms Randall), particularly the OO
> programmers. Using file statuses makes the syntax agree with concept.
Good point - but this is a flaw in our CoBOL. CoBOL should have English language
commands which do everything that status code checking does. The spirit of CoBOL is
that a non-programmer should be able to read what it does. Status codes are cryptic and
require expertise to read. (not much expertise, but nevertheless it is not English).
> *-------------------- related rant ---------------------
>
> CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
> which have already implemented this "feature". DON'T DO IT!
> EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
> GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
> tell them to get rid of these abominations before they get into the
> new official standard!
>
> *-------------------- END-RANT ---------------------
EXIT-PARAGRAPH will be used to replace GO TO XXXX-EXIT. When this is adopted, more
sites will adjust their standards to proscribe PERFORM THRU statements. This will be a
good thing. They aren't letting go of their GO TO xxxx-EXIT statements yet.
The hard thing though is the line "When this is adopted". Lots of sites were using
ANSI-68 code until they were forced to upgrade to handle the century changes. They
might not feel a need to spend money to upgrade compilers at all.
Howard Brazee
Richard Plinston wrote:
> Stephen J Spiro wrote:
> >
> > 2000-READ-AND-PROCESS.
> > READ INPUT FILE INTO WS-INPUT-FILE.
> > EVALUATE INPUT-FILE-STATUS
> > WHEN '00'
> > PERFORM 3000-PROCESS-RECORDS
> > THRU 3000-EXIT
>
> Just one tiny criticism. They may be (in fact are) cases were a valid
> [sic] read returns a status that is not '00'. For example an indexed
> file with a duplicate key being read sequentially may give a status of
> '02' to indicate that the next record has the same key.
>
> It is important to only check the first byte for being zero as a means
> of detecting successful reads.
I was maintaining a purchased system where our I/O would call a program
which called a program. The called program would return a '7' when the
VSAM file failed to open. I pulled down that program and found out '7' was
"not '00'". Rerunning the job would work correctly. I traced down this
intermittent problem to find out that VSAM returned a '97', which means OPEN
statement execution successful: File integrity verified. Since this
program gets called by everybody and his brother, making this minor fix
would mean significant testing and signing off, giving operators
instructions to restart, or adding a verify step before the program. This
system had the worst features of OO without the benefits.
Robaire
"James J. Gavan" <jjg...@home.com> a écrit:
>Still off topic - but it can be fascinating.
>
>As an extension to that regarding the former colonies - they don't have any
>problem with GLOUCESTER in New England, like you and me they *know* all about
>Dr. Foster. Also in New Hampshire they pronounce PORTSM'TH the same way I do.
>
>I was initially puzzled when I first came over here why our American friends
>pronounce it 'erbs as opposed to herbs - logic it's the Cockneys who are
>supposed to drop their 'aitches'. Alistair Cooke on PBS Masterpiece Theatre
>wised me up - seems the they took the word directly from the French whereas we
>anglicized it.
<large snip>
>Jimmy.
Continuing fff-topic ( just mentioning this - I've heard that some
people use this newsgroup to discuss COBOL).
The French exerted a strong influence in England in the vocabulary
( and improvement, I expect ) of the culinary arts. When several big
wigs were losing their heads during the French Revolution, many chefs
(french) were, as a corollary, losing their jobs. They emigrated "en
masse" to England where they set up restaurants, or worked for the
British aristocracy. Apparently, that is why, today, anglophones do
not eat pig, but pork (from the French "porc"), not sheep, but mutton
("mouton"), not calf, but veal ("veau") and not cow, but beef ("boeuf)
- I'm sure you get the picture.
As for herbs losing its leading "h" when pronounced by Americans, I
can't see that - the influence of the French on american "cuisine"
can't possibly have been that great, apart from Cajun cooking, which
apparently reached Louisiana via French Canada.
What I can see in "erbs" is the american "penchant" for efficiency.
At the beginning of the century, Henry Fowler , besides warning us
against the dangers of using gallicisms in English (French-Candian
will get a big charge out of that), he also stated:
"There is a real danger of our literature's veing americanized, and
that not merely in details of vocabulary ... but in its general tone."
He then gives an example of Rudyard Kipling's work, pointing out its
"...sort of remorseless and scientific efficiency..."
Alistair Cook dropping his h's - it seems to me he dropped mostly
crumbs - oh no! - that was Alistair Cookie on Monsterpiece Theatre.
"The Monsters of Venice" was my favourite play!
R. Miller
Howard Brazee
> The French exerted a strong influence in England in the vocabulary
> ( and improvement, I expect ) of the culinary arts. When several big
> wigs were losing their heads during the French Revolution, many chefs
> (french) were, as a corollary, losing their jobs. They emigrated "en
> masse" to England where they set up restaurants, or worked for the
> British aristocracy. Apparently, that is why, today, anglophones do
> not eat pig, but pork (from the French "porc"), not sheep, but mutton
> ("mouton"), not calf, but veal ("veau") and not cow, but beef ("boeuf)
> - I'm sure you get the picture.
I thought this was from the Normans who spoke French, while their farmers were
Anglo-Saxon.
> As for herbs losing its leading "h" when pronounced by Americans, I
> can't see that - the influence of the French on american "cuisine"
> can't possibly have been that great, apart from Cajun cooking, which
> apparently reached Louisiana via French Canada.
>
> What I can see in "erbs" is the american "penchant" for efficiency.
> At the beginning of the century, Henry Fowler , besides warning us
> against the dangers of using gallicisms in English (French-Candian
> will get a big charge out of that), he also stated:
This is an exception - for the most part Americans pronounce words much more
phonetically than do the Brits. After all, most of our (American) ancestors were
literate when they first learned English.
Stephen J Spiro
> Stephen J Spiro wrote:
> >
> > 2000-READ-AND-PROCESS.
> > READ INPUT FILE INTO WS-INPUT-FILE.
> > EVALUATE INPUT-FILE-STATUS
> > WHEN '00'
> > PERFORM 3000-PROCESS-RECORDS
> > THRU 3000-EXIT
>
> Just one tiny criticism. They may be (in fact are) cases were a valid
> [sic] read returns a status that is not '00'. For example an indexed
> file with a duplicate key being read sequentially may give a status of
> '02' to indicate that the next record has the same key.
>
> It is important to only check the first byte for being zero as a means
> of detecting successful reads.
**-----------------------
Very easy to say
WHEN '00' OR '02'
Some of the '9x' (user-defined) codes may be OK, as well.
Additionally, one or more '0x' codes may be unacceptable in a
particular, programmer-defined case. Thus, I prefer testing for all
applicable codes, in full.
**-----------------------
>
> > *-------------------- related rant ---------------------
> >
> > CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
> > which have already implemented this "feature". DON'T DO IT!
> > EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
> > GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
> > tell them to get rid of these abominations before they get into the
> > new official standard!
> >
> > *-------------------- END-RANT ---------------------
>
> I quite agree.
>
> However, you used an example of:
>
> > PERFORM 3000-PROCESS-RECORDS
> > THRU 3000-EXIT
>
> Now the _only_ point of doing a PERFORM THRU (or a PERFORM SECTION) is
> to allow for using GO TOs (explanation available upon request), so I
> don't know if your objection to EXIT-something is because it is a GO TO
> or because it is disguised.
*LOL* NEVER say the ONLY reason for doing something is "xxx"!
In the Old, Original COBOL, you performed a paragraph THRU a parahraph
and a section THRU a section. I got in the habit a long time ago.
When I started programming, many people (myself included) performed
multiple paragraph groups, and an EXIT paragraph was a nice, clean way
to show the end of the performed group, even if there was only one
paragraph, or even if you did not use GO TO. At this point, I do not
use GO TO, and I never perform more than one paragraph at a time.
Using the EXIT is just a habit, now. I suppose I should change my
style, it doesn't accomplish anything, altho I like to think it makes
the code neater.
Yes, my objection to EXIT-PARAGRAPH, EXIT-SECTION and
EXIT-PERFORM-CYCLE are because they are GO TO's .... AND because they
are disguised.
Stephen J Spiro
Member, J4 COBOL Standards committee
PS: YOU (all of you!) could join the standards committee and make a
difference!
Howard Brazee
> *LOL* NEVER say the ONLY reason for doing something is "xxx"!
> In the Old, Original COBOL, you performed a paragraph THRU a parahraph
> and a section THRU a section.
I have never seen a section THRU a section. In my early days paragraph THRU paragraph was rare in
my experience, becoming real common in the late 1970s, and early 1980s.
> Yes, my objection to EXIT-PARAGRAPH, EXIT-SECTION and
> EXIT-PERFORM-CYCLE are because they are GO TO's .... AND because they
> are disguised.
Please continue. The reason I object to GO TO's is because they allow for drop through code to new
paragraphs. Since this isn't the case here, your objection must lie elsewhere. Why do you object
to GO TO's in this case?
Peter Lacey
> CONTINUE could be replaced by EXIT-PARAGRAPH in those compilers
> which have already implemented this "feature". DON'T DO IT!
> EXIT-PARAGRAPH, EXIT-SECTION and EXIT-PERFORM-CYCLE are ALL disguised
> GO TO's! BAD! BAD! BAD! Write to J4 (and/or your National Body) and
> tell them to get rid of these abominations before they get into the
> new official standard!
>
> *-------------------- END-RANT ---------------------
You're treading on very dangerous ground here, friend.
ANY kind of verb that redirects program flow is a go to!!! Whether it is expressed in
that way or not, every such verb represents the concept: the program is executing a
statement HERE but is going to remove itself to executing a statement THERE. Even a
PERFORM 100 TIMES has an implied but explicit transfer of execution back to the top of
the perform. Just because it doesn't say GO TO doesn't mean it doesn't do it. Try
writing a program as one long set of statements , top to bottom with no deviations, and
you'll have to agree that you can't avoid control transfers. QED.
At the risk of seeming archaic, stubborn, out of it, etc., (insert your own adjective),
I strongly question your use of the word "Abominations". Consider a program:
IF A = B
...
500 lines of code with enough conditions and if's to make it interesting
...
END-IF.
I've had to maintain enough of such code to have decided opinions on its worthiness. To
locate that terminal END-IF (especially considering the no-comment no-paragraph style of
prgramming so popular these days) I've been reduced to printing the program with an
indented listing and then taking a ruler to it; or using an editor (with indented code)
and finding an END-IF in the same column as the starting IF. Then I always had to
examine the listing or screen very carefully to convince myself that I had it right.
Now consider the same program coded with a GOTO:
IF A = B NEXT SENTENCE
ELSE GO TO 110-NEXT.
(coded that way as some people get disturbed at a NOT in an IF)
...
500 lines of code with enough conditions and if's to make it interesting
...
(.) Terminal period.
110-NEXT.
Elapsed time to find the "end of the IF" - about ten seconds. Utterly unambiguous.
Simple as spilling one's tea.
How is it, then, that the first method of programming is so much better? Why is the
first one supposed to be easier to understand? Is it a question of better control of
one's facial muscles? Is ambiguity preferable? Is it because programs with GOTO's can
be a horrible mess? (If so, then better eliminate GOTO-less programs too, because you
can get horrible messes without GOTO's! There is a thread still open that displays an
absolutely monstrous use of EVALUATE).
The GOTO argument has been "going" on for over 25 years now. That fact alone should be
sufficient argument that there is equal merit to both sides.
With all possible respect, people who insist that such and such verbs must be removed
from the compiler are as stubborn and hidebound as those who use GOTOs and create
reliable, easy-to-maintain code.
End of MY rant.
Richard Plinston
>
> The French exerted a strong influence in England in the vocabulary
> ( and improvement, I expect ) of the culinary arts. When several big
> wigs were losing their heads during the French Revolution, many chefs
> (french) were, as a corollary, losing their jobs. They emigrated "en
> masse" to England where they set up restaurants, or worked for the
> British aristocracy. Apparently, that is why, today, anglophones do
> not eat pig, but pork (from the French "porc"), not sheep, but mutton
> ("mouton"), not calf, but veal ("veau") and not cow, but beef ("boeuf)
> - I'm sure you get the picture.
It goes back further that, to the Normans. When the Normans took over
they became the ruling class and spoke Norman-French (Normans were
originally North-men or Vikings). The English remained serfs. As there
was a separation between the meat-eating French speakers and the animal
raising Middle English speakers (unable to afford to eat meat) the two
sets of terms became separated.
James J. Gavan
Arnold Trembley wrote:
> Tim Scrivens wrote:
> >
> > How about some of the old standards, name-wise
> >
> > Chomondoley
> > Coughtry (5 pronunciations)
> > Dondall
> > even Powell
>
> Cholmondoley = Chumley? Sounds like a P.G. Wodehouse festival.
>
> How do you pronounce Mainwaring?
In exactly the same way a Cockney spiv nicknames a Scot 'Taffy" ! What a
delight as Captain Mainwaring/Mannering or the crafty little Irish
priest in "Bless Me Father".
Name wise there's always Mrs. Bouquet/Bucket from 'Keeping Up
Appearances'. Nah ! She aint fictional - believe me they still EXIST !
PS: 'Spiv' - First used in WW2 - best I can suggest is - smart-assed,
street-wise and that particular spiv was a 'black marketer' - got
rationed goods, (petrol/clothing/food) by stealing, or 'under the
table' and re-sold for profit.
PPS : That snobbery conveyed by Mrs. Bouquet was a rampant part of
British society - certainly back in the WW2 era, at which 'Dad's Army'
poked fun. But to show you its impact - and this is for real :-
Battle of Britain is in progress and two young 'chappies' join the RAF
as fighter pilots to combat the Luftwaffe onslaught. One is not 'Qu-ite
right', perhaps he doesn't hold hs knife and fork correctly, or slurps
over his beer. One becomes a commissioned pilot officer, the latter a
lowly sergeant.
They both on the same day shoot down an Me-109. They are recognized for
bravery and duly trot up to Buckingham Palace where the King (George VI)
will pin a medal (gong) on their chest. The Hossifer and Gentleman - he
gets the DFC (Distinguished Flying Cross), but the yobbo sergeant - DFM
(Distinguished Flying Medal) ! Aint democracy and equal opportunity just
great !
They've discreetly let that 'difference' drop since.
Jimmy
Richard Plinston
>
> At the risk of seeming archaic, stubborn, out of it, etc., (insert your own adjective),
> I strongly question your use of the word "Abominations". Consider a program:
>
> IF A = B
> ...
> 500 lines of code with enough conditions and if's to make it interesting
> ...
> END-IF.
>
> IF A = B NEXT SENTENCE
> ELSE GO TO 110-NEXT.
>
> (coded that way as some people get disturbed at a NOT in an IF)
> ...
> 500 lines of code with enough conditions and if's to make it interesting
> ...
> (.) Terminal period.
>
> 110-NEXT.
From my perspective the cause of the problem is not the IF ... END-IF or
the lack/use of GO TO Exit, but is much more subtle.
You obviously use a style of PERFORMed SECTIONs where the labels are
numbered. You may even have these numbered to represent both the
'level' and the position in the source file.
This imposes a restriction and an overhead on creating a sub-block that
could be performed. Because of this overhead it becomes too difficult
to break the code down into more managable routines. This leads to long
ponderous lumps of code that are difficult to navigate. As you quite
rightly say, a 500 line IF ... END-IF makes it difficult to understand.
Using a GO TO, however, introduces other problems.
If the code was structured then instead of (say):
something or other
IF ( Customer-Type = "R" )
120 lines calculating price
150 lines calculating discount
70 lines calculating tax
END-IF
You would write:
IF ( Customer-Type = "R" )
PERFORM Calculate-Retail-Price
PERFORM Calculate-Retail-Discount
PERFORM Calculate-Retail-Tax
END-IF
.
Calculate-Retail-Price.
120-lines
etc.
But your style PREVENTS you from doing this. Well not exactly prevents
but makes it too much hard work. You probably have to invent new
numbers (ensuring no clash), move the code to its correct sequential
position in the source, ensure the correct SECTION header and Exit
paragraph and that it is correctly terminated by the next SCTION
keyword.
The result is that the code gets separated from its parent and it is
then even more difficult to work between the IF and the code.
So the programmers code long meandering SECTIONs and put in GO TOs
because it is easier than the overheads and problems above.
This is _not_ a result of IF ... END-IF, or of trying to avoid GO TO (or
EXIT SECTION). It is directly the result of making 'routines' too
difficult to create (the overhead).
Try an experiment. Take a long meandering SECTION that should only have
two paragraphs in it, the (implied or specific) code paragraph and the
nnn-Exit.
Now break down the code into logical blocks and give each a meaningful
name. For each put a PERFORM at the start of the section. If there is
an overall IF or IF .. GO TO then put this in the initial block of code.
The 500 lines may turn into a 20 line of so summary of the code followed
by a dozen or so routines that do the work, and these are in the same
place. Because the summary can be IF ... END-IF withoutout meandering
over many pages you won't _need_ any GO TO Exit, so kill that
paragraph. It no longer _needs_ to be a SECTION so make the initial
paragraph what is PERFORMed. Get a decent text editor that can do a
search by placing the cursor on a name and pressing a key, you no longer
_need_ number to find things, or to put them in some sort of artificial
order (this was necessary when programs were in boxes of cards).
The _cause_ of the 500 line IF ... END-IF is not 'GO TO less
programming', but attempting to avoid GO TO _within_ a high overhead
PERFORM SECTION style that has created the 500 line paragraphs in the
first place.
To go to 'GO TO Less' programming it is necessary to _also_ reject all
the red-tape that goes with the 'PERFORM SECTION with GO TO exit'. As
you have discovered, trying to get to it in steps fails miserably. Now
try and find enlightenment little cricket ;-)
Yes, I know, you or your site have been doing it one way for 30 years
....
> End of MY rant.
Feeling better now ? I do. ;-)
William M. Klein
The "issue" of IBM's use of VSAM files returning a file-status code of
"97" when a "verify" is required (and done by the IBM COBOL run-time itself)
is a "little" interesting (and has some discussion).
In (at least one) theory, IBM is "non-conforming" by using a "9x" file
status code for something that they (themselves) call a "successful" I/O
statement. On the other hand, the "behavior" after all 9x codes is
"implementor defined" - so they can (and at a HIGHLY theoretical level have)
said that this really is an "unsuccessful" I/O statement that results in
processing "as if" it were successful.
Much of this MAY go away in the future, when the new draft Standard allows
for "0x" file status codes indicating implementor defined SUCCESSFUL
conditions. Also (as I recall) the "newer" COBOL (IBM COBOL for
this-and-that) *tend* to issue "97" less often than you used to get with
OS/VS COBOL.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:3B24C461...@brazee.net...
William M. Klein
requested that GO TO be placed in the "archaic" (*not* OBSOLETE) category in
this revision of the Standard.
I have NOT seen how J4 "processed" this request and NOTHING will be final on
it until the WG4 meeting in November. HOWEVER, from past "discussion" my
GUESS is that this will be "rejected".
If you have an opinion on whether GO TO should or should not be made
"archaic," then I think you MIGHT want to send a note to the J4 Chair asking
for you "input" to be considered on this topic. He can be reached
electronically at:
doncobol <at> mediaone.net
Just so there is no confusion, the following are what the terms "archaic"
and "obsolete" mean in the draft Standard.
E.1 Archaic language elements
The purpose of the archaic language element designation is to discourage the
use in new programs of some features that are unreliable, poor programming
practice, or ill-defined -- where better programming techniques are
available in standard COBOL. These elements are classified as archaic rather
than obsolete because their use in existing programs is too extensive to
warrant removal in the next revision of standard COBOL.
Archaic language elements are intended to remain in the next revision of
standard COBOL. There is no plan for the removal of archaic elements;
however, should their use in program inventories become insignificant, they
may be considered for designation as obsolete by future architects of
standard COBOL."
***
E.2 Obsolete language elements
Obsolete language elements are elements that will be removed in the next
edition of this draft International Standard because those elements no
longer needed or are rarely used. To limit the impact of removal, those
elements are designated as obsolete to serve as a notice of the intention to
remove them.
No elements will be removed from any future edition of this draft
International Standard without first having been designated as obsolete
language elements in the preceding edition.
Obsolete language elements have not been enhanced nor modified in this draft
International Standard and will not be maintained. The interaction between
obsolete language elements and other language elements is undefined unless
otherwise specified in this draft International Standard.
A conforming implementation is required to support obsolete language
elements except for elements that are also optional or processor-dependent."
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter Lacey" <la...@mb.sympatico.ca> wrote in message
news:3B252083...@mb.sympatico.ca...
Stephen J Spiro
> FYI - one national Standards body (the Netherlands) *has* specifically
> requested that GO TO be placed in the "archaic" (*not* OBSOLETE) category in
> this revision of the Standard.
>
> I have NOT seen how J4 "processed" this request and NOTHING will be final on
> it until the WG4 meeting in November. HOWEVER, from past "discussion" my
> GUESS is that this will be "rejected".
>
> If you have an opinion on whether GO TO should or should not be made
> "archaic," then I think you MIGHT want to send a note to the J4 Chair asking
> for you "input" to be considered on this topic. He can be reached
> electronically at:
>
> doncobol <at> mediaone.net
<snip>
Unless they did it the day I slept late, Netherlands comments have not
yet been processed. We hope to finish the international comments in
Portland, Ore at the beginning of August.
I, personally, also requested that GO TO be made "archaic", in one of
MY public review comments. My proposal was rejected by a vote of 8 to
1. If Netherlands lobbies hard for it, it could still be done at the
next WG4 meeting.
Stephen J Spiro
Member, J4 COBOL Standards Committee
PS: Still a lot of work left, ALL OF YOU could join J4 and make a
difference!
James J. Gavan
> "William M. Klein" <wmk...@nospam.ix.netcom.com> wrote in message news:<9g3fkf$nmf$1...@slb7.atl.mindspring.net>...
> > FYI - one national Standards body (the Netherlands) *has* specifically
> > requested that GO TO be placed in the "archaic" (*not* OBSOLETE) category in
> > this revision of the Standard.
> >
> > I have NOT seen how J4 "processed" this request and NOTHING will be final on
> > it until the WG4 meeting in November. HOWEVER, from past "discussion" my
> > GUESS is that this will be "rejected".
> >
> > If you have an opinion on whether GO TO should or should not be made
> > "archaic," then I think you MIGHT want to send a note to the J4 Chair asking
> > for you "input" to be considered on this topic. He can be reached
> > electronically at:
>
"Bewitched, bothered and bewildered, am I" - Pal Joey - Richard Rodgers & Lorenz Hart..
So how long does this malarkey go on with the Standards, a bouncing ball between ANSI/J4 and ISO ?
Wont hold you to it Bill, and you can be speculative - but just so we can get some handle on this schmozzle. Assuming
a proposed deadline of December 2002 - care to show some milestones (Month and Year) what happens from here on in
until December 2002
Jimmy
Stephen J Spiro
<snip>
> You're treading on very dangerous ground here, friend.
>
> ANY kind of verb that redirects program flow is a go to!!!
<snip>
*-------------------
I'm sorry, but if you do not understand the conceptual difference
between a physical transfer of control and the unrestricted use of GO
TO in programming methodology, then we do not have a common
vocabulary. Further discussion on the topic (between you and me)
would waste both of our time.
Stephen J Spiro
Wizard Systems
Stephen J Spiro
>
> Wont hold you to it Bill, and you can be speculative - but just so we can get some handle on this schmozzle. Assuming
> a proposed deadline of December 2002 - care to show some milestones (Month and Year) what happens from here on in
> until December 2002
>
> Jimmy
"Official" schedule:
Last WG4 Convener's schedule:
http://www.ncits.org/tc_home/j4htm/m226/00-0424.doc
WG4 Homepage Schedule:
http://anubis.dkuug.dk/jtc1/sc22/wg4/open/projects#milestones
Jimmy, this a bleeding _ISO_ committee! You didn't think there would
be SCHEDULES? *L*
Stephen J Spiro
Member, J4 COBOL Standards Committee
PS: All of you could join the J4 standards committee and help us keep
this schedule, or make a better standard!
Howard Brazee
> You would write:
>
> IF ( Customer-Type = "R" )
> PERFORM Calculate-Retail-Price
> PERFORM Calculate-Retail-Discount
> PERFORM Calculate-Retail-Tax
> END-IF
> .
> Calculate-Retail-Price.
> 120-lines
> etc.
>
> But your style PREVENTS you from doing this. Well not exactly prevents
> but makes it too much hard work. You probably have to invent new
> numbers (ensuring no clash), move the code to its correct sequential
> position in the source, ensure the correct SECTION header and Exit
> paragraph and that it is correctly terminated by the next SCTION
> keyword.
I do this all the time. First of all, there generally is plenty of room to insert new
numbers where they belong. If I want to add paragraphs between 1100-CUSTOMER-LOOP &
2000-CALCULATE-INTEREST, I have some choices available. And global changes don't take much
work anyway.
SkippyPB
Spiro) enlightened us:
If you are going to try and have GO TO be made "archaic" in the Cobol
Standard, then I suggest you also petition IBM to make the following
Assembler instructions "archaic":
B
BE
BNE
BAL
BALR
BNO
BO
BCT
BCTR
BCR
BM
BXH
BXLE
BP
And while your at it, I believe there is a JMP instruction in some PC
Assemblers, so you should petition Intel and others to make it
"archaic" as well.
And while you're at it, I'm sure that Microsoft's VB and Q-Basic have
some offending branch instructions that you could petition them to
make "archaic" as well.
And what about C and C++? Aren't there some branch instructions in
those languages that should be made "archaic" as well?
Hell, let's revolutionize the entire set of computer languages to
eliminate branching altogether because some people think this kind of
operation is "archaic". Once that is done and all the mainframe and
PC operating systems have been rewritten then we can all get back to
work writing Cobol and other computer language programs that only use
"non-archaic" commands. The birds will sing, the world will be
perfect....
Regards,
////
(o o)
-oOO--(_)--OOo-
Sticks and stones may break my bones,
But whips and chains excite me!
DON'T DRILL in the Artic National Wildlife Refuge
Read the real facts at:
http://www.worldwildlife.org/arctic-refuge/
also
http://www.savepolarbears.org/
Remove nospam to email me.
Steve
Howard Brazee
> If you are going to try and have GO TO be made "archaic" in the Cobol
> Standard, then I suggest you also petition IBM to make the following
> Assembler instructions "archaic":
What do good assembler programming practices have to do with good CoBOL programming practices?
>
> B
> BE
> BNE
> BAL
> BALR
> BNO
> BO
> BCT
> BCTR
> BCR
> BM
> BXH
> BXLE
> BP
We can do ALTER GO TO's quite easily in assembler as well. Just because we can do something in assembler doesn't
mean we can't recommend against doing it in CoBOL. (Making it archaic simply is a recommendation that it not be
used).
> And while your at it, I believe there is a JMP instruction in some PC
> Assemblers, so you should petition Intel and others to make it
> "archaic" as well.
>
> And while you're at it, I'm sure that Microsoft's VB and Q-Basic have
> some offending branch instructions that you could petition them to
> make "archaic" as well.
>
> And what about C and C++? Aren't there some branch instructions in
> those languages that should be made "archaic" as well?
>
> Hell, let's revolutionize the entire set of computer languages to
> eliminate branching altogether because some people think this kind of
> operation is "archaic". Once that is done and all the mainframe and
> PC operating systems have been rewritten then we can all get back to
> work writing Cobol and other computer language programs that only use
> "non-archaic" commands. The birds will sing, the world will be
> perfect....
And even if they recommend that we don't use GO TO in CoBOL, there are lots of recommended ways to branch in CoBOL.
Methinks you are being silly.
Peter Lacey
> From my perspective the cause of the problem is not the IF ... END-IF or
> the lack/use of GO TO Exit, but is much more subtle.
>
> You obviously use a style of PERFORMed SECTIONs where the labels are
> numbered. You may even have these numbered to represent both the
> 'level' and the position in the source file.
Better stop right now. I never use sections except as the input and output procedures for a
sort (and I'm getting away from that). I do use numbered paragraphs but the only
relationship the numbers have to the position in the program is that all the paragraph names
within sort procedures have the same intial digit as the section name
INPUT PROCEDURE IS 200-INPUT
200-INPUT SECTION.
201-GO.
210-...
etc.
Beyond that, the paragraph numbers are in strictly increasing order. Reason is that it makes
navigating within the source code infinitely easier. Also paragraph names are guaranteed to
be unique.
Therefore, I must respectfully point out that, because of your jumping to an incorrect
conclusion, your whole subsequent argument is irrelevant.
My point in the post was to ask why, in the example I gave, GOTO-less coding should be
considered "better" and "less ambiguous"? You did acknowledge the point but didn't really
answer it.
>
>
> You would write:
>
> IF ( Customer-Type = "R" )
> PERFORM Calculate-Retail-Price
> PERFORM Calculate-Retail-Discount
> PERFORM Calculate-Retail-Tax
> END-IF
> .
> Calculate-Retail-Price.
> 120-lines
> etc.
>
Of course. This is certainly the way I'd do it (with numbers prefixed to the names).
> Now
> try and find enlightenment little cricket ;-)
No need to be condescending. I was polite and (I hope) reasonably humorous.
> Yes, I know, you or your site have been doing it one way for 30 years
Now that really is a bit much. I happily gave up on cards once a decent editor was
available. I leaped upon the PERFORM...END-PERFORM and similar constructions when they
became available. I stopped using sections for memory conservation once useful memory sizes
were there. I have moved along to using GUI (although some of the earlier implementations
were "klunky") and continue to refine my use of it. I'm beginning to try OO. Now if in the
course of "30 years" I have found a particular programming technique useful, easy, and
maintainable in the face of enlightened (or not) opinio, I'm Entitled!!
PL
Thane Hubbell
If you download the PDF instead of opening it in your browser, and
then open it with Acrobat - the F3 works to continue the search.
I have no comments on the other topics except to say that the
likelyhood of removing features at this late date (especially as the
country vote was virtually unanimous in favor of the draft -- one
abstention) is zero.
"James J. Gavan" <jjg...@home.com> wrote in message news:<3B245565...@home.com>...
James J. Gavan
Peter Lacey wrote:
> I stopped using sections for memory conservation once useful memory sizes
> were there. I have moved along to using GUI (although some of the earlier implementations
> were "klunky") and continue to refine my use of it. I'm beginning to try OO.
Ooh ! Re OO - Which compiler, and what is your success to date ? (You do realize you are swimming
against the generally 'accepted' tide <G>)
Jimmy, Calgary AB
Chuck Stevens
news:4145699b.01061...@posting.google.com...
> Unless they did it the day I slept late, Netherlands comments have not
> yet been processed.
We did "process" this item at Meeting #231 just completed, but did not
produce a final answer; the comment was accepted as a project by a J4 member
who, it is presumed, will prepare a proposed response to be discussed in
Portland. There were a handful of international comments whose processing
was "tabled" until the Portland meeting because they related to areas
already being researched elsewhere, but this particular comment isn't one of
them.
-Chuck Stevens
James J. Gavan
Stephen J Spiro wrote:
> "James J. Gavan" <jjg...@home.com> wrote >
> > So how long does this malarkey go on with the Standards, a bouncing ball between ANSI/J4 and ISO ?
> >
> > Wont hold you to it Bill, and you can be speculative - but just so we can get some handle on this schmozzle. Assuming
> > a proposed deadline of December 2002 - care to show some milestones (Month and Year) what happens from here on in
> > until December 2002
> >
> > Jimmy
>
> "Official" schedule:
>
> Last WG4 Convener's schedule:
> http://www.ncits.org/tc_home/j4htm/m226/00-0424.doc
>
> WG4 Homepage Schedule:
> http://anubis.dkuug.dk/jtc1/sc22/wg4/open/projects#milestones
>
> Jimmy, this a bleeding _ISO_ committee! You didn't think there would
> be SCHEDULES? *L*
>
May I remind you sir, you are a Yank. You may NOT arbitrarily use Brit colloquialisms, "Bleeding.........." indeed ! <G>
Well, I'll concede I'd let WMK do it 'cos he's a bit 'TransAtlantic' .
OK so you had a good laugh. So would I, but the Brit expression is, "Not funny ha ha, but funny peculiar (pathetic)".
Thanks for the references and I took a look see - one is a bit out of date, but the other is informative. Just let's hope
in the screwing around it doesn't cause a delay. Seems funny to me - you've already been through the process with the CD
1.10 comments. Agreed you've got to fine tune based on those comments - but to drag it out from today until December 2002 ?
Even that warns with a caveat - not necessarily, but could become xxx 2003 ?
What's with the ISO bit, you J4, ARE (A)merican NSI, though you do speak as a group with divers tounges and accents. Bottom
line, and translate to nice diplomatic-ese as you wish.:-
"Look you jerks running ANSI/ISO, there are over 3 million people world wide who make their bread, either designing COBOL
compilers or developing applications using COBOL. We have a concrete 40 year track record of success.
You #4@##! people are screwing us around with your hidebound bureaucratic procedures. If you wont acknowledge our concerns,
when we want to quickly and easily introduce changes to OUR COBOL community language, we will do our 'own thing' and you
can stick your respective bureaucracies where the sun don't shine !"
PS: Reference "divers dialects above." From my wife. Mind you she has to choose her customers carefully, they don't all
necessarily have a sense of humour. She works part-time at a retail cash desk for pin money and to keep herself active :-
Customer says pleasantly, "I love your English accent". "Accent ?", replies my Eileen, sweetly. "I don't have an accent.
It's you colonials who have an accent !".
William M. Klein
defined at this stage. If anyone (myself included) wanted to change this
now, it would definitely be CONTROVERSIAL - and probably would result in
delays.
The steps (from the FCD review on) - but without dates are:
A) International FCD review starts (4 month review)
B) US does a two-month public review
C) J4 TAG determines which US public review comments get forwarded to the
international review process.
B1-C1 "similar" actions occur in other countries who do whatever they want
to determine and then submit their national comments
D) International review period on FCD ends
>>> (we are here)
E) J4 (as subcontractor to WG4) drafts responses to ALL internationally
submitted comments (this includes the US comments that were submitted
internationally - but NOT all the original US Public review comments)
F) WG4 has a meeting to "process" the J4 recommendations on international
comments. This usually involves at least a "little" tweaking but MIGHT be a
total reversal - or a "rubber stamp". I have NO way to project what will
happen
G) AFTER WG4 "reconciliation" of comments, their "official" response is
forwarded back up to SC22 for sending back to all national standards bodies
(including ANSI).
H) Assuming no country changes from "yes with comments" or "yes" to "NO" on
the basis of these responses,
I) J4 develops proposals to "implement" the responses sent to all the
countries (when some changes were required). Actually, work has already
begun on these "tentative" proposals but they ABSOLUTELY are not applied to
the FCD document until AFTER the (Nov 2001) WG4 meeting.
I1 - J4 actually creates and sends out all of the replies to the US FCD
public review comments. They are delayed until this time - in case WG4
direction makes some of the "draft" US replies inappropriate.
J) J4 finishes all "substantive changes" and does an "editing meeting"
(possibly with or by WG4 or possibly just a "subgroup".
K) The output of this work (proposals and editing work) results in an FDIS
document "Final Draft International Standard).
L) This FDIS then goes out to another 4 month international review period.
Normally, (Unless something has gone DRASTICALLY wrong) this is a "straight"
up or down vote. During this 4 month period the US does another 2 month
public review.
M) Assuming this FDIS "passes" (and there are explicit rules for what a
"pass" is) at the international processing, this FDIS becomes an
International Standard
N) In the US as soon as this document becomes an ISO Standard, it will
"automagically" also become an ANSI Standard. This may work differently in
other countries.
***
The existing schedules actually have a "little" slack in them to end up with
a December 2002 "completion". So far I have seen nothing that is likely to
change this, but there certainly COULD turn out to be something
"controversial" or "hard to implement" coming out of the November 2001 WG4
meeting. I doubt it, but it is possible.
--
Bill Klein
wmklein <at> ix.netcom.com
"James J. Gavan" <jjg...@home.com> wrote in message
news:3B26741F...@home.com...
Liam Devlin
>
> Liam Devlin wrote:
>
> > I work with a great number of people who stubbornly code NEXT SENTENCE
> > instead of CONTINUE even though they're coding END-IF nowadays. They're
> > probably lucking out because they're also coding periods everywhere they
> > can.
> >
> > LiamD
>
> Do they state any reasons for using NEXT SENTENCE?
Because they've always done it that way. It's a good thing we didn't
depend on COBOL programmers to explore the savannas and walk upright,
we'd still be living in caves.
Liam Devlin
>
> Liam Devlin wrote:
>
(snip)
>
> Bloody good guess Liam. Comes out 'HATCH BEECHAM'. One of the UK
> pharmaceutical firms was/is called Beechams - fair bet it started out as
> Beauchanmp - might even have ben an 's' on the end. With those weirdos that
> occur in UK, the name Auchinleck comes out 'AFFLECK'. There are family members
> who use the spelling 'Affleck'.
Like fair Ben in "Pearl Harbor"?
> Now when it comes to Celtic names, even with roots back to the 'Auld Sod' - I
> get real tounge-tied. So how does your first name come out phonetically., (I
> prefer Christian name - but what the hell). I'd been inclined to say LEE-AM
> but I suspect it's more like L'EEM.
Kind of, it's sort of "LEE-um" where the "um" part is hardly there. I
have no idea how it's supposed to be pronounced since no one in my
family was actually from Ireland.
> Jimmy (Seamus if you like <G>).
Yes, I do, Seamus, good name, lad.
LiamD
Liam Devlin
>
> Tim Scrivens wrote:
> >
> > How about some of the old standards, name-wise
> >
> > Chomondoley
> > Coughtry (5 pronunciations)
> > Dondall
> > even Powell
>
> Cholmondoley = Chumley? Sounds like a P.G. Wodehouse festival.
>
> How do you pronounce Mainwaring?
"Luxury Yacht"
(sorry, couldn't resist such a good setup)
LiamD