COBOL/DIALOGUE System
Eddie Veness
digits alphanumeric. I have to prevent the user from being able to leave a
space anywhere within those eight digits and finally creat an error message.
The error message I can handle, I just can't get my head around preventing
spaces. I thought at first sight, simple enough but this is getting the
better of me. I have not been programming in COBOL for that long and I would
welcome any help.
James J. Gavan
Eddie Veness wrote:
Eddie,
You haven't told us which 'screen tool' your are using, although from your
subject heading I'm taking a guess at Net Express Dialog System.
1. Assuming it was Screen Section check out the syntax for ACCEPT - where you
can use FULL, LENGTH-CHECK, UPPER on EXCEPTION etc.
2. Assuming it is a Windows based tool for GUIs - you can build in some of the
above features as you design your Dialogue entry field, (e.g. Numeric(only)
Upper or Uppercase (which gives you 'upper' and numerics).
3. From what you've written you have a pic x(08) which must be 'filled' -
possibly a Customer Account Number which must ALWAYS be 8 characters ?. Over and
above the GUI set-up above, which characters are acceptable - Uppercase Alpha
and Numerics but no spaces or ANY other characters such as "/", "-" etc.
I thought this would be easy until I started looking :-). You can't do IS
NUMERIC tests on pic x and you can't do IS ALPHABETIC-UPPER on pic 9's !!! Plus
ALPHABETIC-UPPER also accepts the space character as valid. Check your on-line
Help for Class Condition tests for background on this, plus use of the SPECIAL
NAMES.
If you really want to tie it down you could do the following sort of validity
check. (This is off the top of my head so check the syntax) :-
01 MyInputfield.
05 charM occurs 8 pic x.
01 CharX pic x.
88 ValidAlpha value "A" thru "Z".
88 ValidNumeric value 0 thru 9.
01 Avalue. pic x.
88 GoodValue value 1.
88 BadValue value 0.
set Badvalue to true
Perform varying n from 1 by 1 until n > 8
move CharM(n) to CharX
if ValidAlpha OR ValidNumeric
set GoodValue to true
EXIT PERFORM
End-if
End-Perform
If BadValue......... then your error routine
*** In the above I'm testing for 'positive' conditions. I intensely dislike
testing for negatives - just like a Cockney and he 'ain't got none' :-)
Be interesting to see what other responses you get.
Jimmy, Calgary AB
Charles Hottel
inspect name8 tallying space-count for all spaces
if space-count > zero
display 'errormsg'
end-if
Eddie Veness <e.ve...@blueyonder.co.uk> wrote in article
<Wdz2a.904$I06...@news-binary.blueyonder.co.uk>...
James J. Gavan
compiled but following should work :-
01 MyInputfield.
05 charM occurs 8 pic x.
01 CharX pic x.
88 ValidAlpha value "A" thru "Z".
88 ValidNumeric value 0 thru 9.
01 Avalue. pic x.. **** should be pic 9.
88 GoodValue value 1.
88 BadValue value 0.
set GoodValue to true
Perform varying n from 1 by 1 until n > 8
move CharM(n) to CharX
if ValidAlpha OR ValidNumeric
continue
else set BadValue to true
EXIT PERFORM
End-if
End-Perform
If BadValue......... then your error routine
Chuck Stevens
IF numeric-item IS GREATER THAN ZERO THEN PERFORM issue-error.
Is that what you had in mind?
There's a conflict in your description. If the field is actually being
filled with eight NUMERIC digits, no sign (as implied by "those eight
digits"), and you've defined the field as PICTURE X(8), then I'd suggest a
REDEFINES with PICTURE 9(8) DISPLAY, and doing an IF numeric-redefinitioin
IS NOT NUMERIC to determine whether to issue the error.
-Chuck Stevens
"Eddie Veness" <e.ve...@blueyonder.co.uk> wrote in message
news:Wdz2a.904$I06...@news-binary.blueyonder.co.uk...
Calin @ Work
double-click on the entry field (or choose properties) and enter 9(8) in the
picture string.
If it's more than this, it's not DS :-)
Calin, TORONTO
"Eddie Veness" <e.ve...@blueyonder.co.uk> wrote in message
news:Wdz2a.904$I06...@news-binary.blueyonder.co.uk...
Robert Wagner
The sample is incorrect. It says if the first byte is ok, then the whole string
is ok.
What is EXIT PERFORM? That's not standard COBOL.
The code should read:
set Goodvalue to true
Perform varying n from 1 by 1 until n > 8
move CharM(n) to CharX
if not (ValidAlpha or ValidNumeric)
set BadValue to true
End-if
End-Perform
James J. Gavan
Robert Wagner wrote:
>
> The sample is incorrect. It says if the first byte is ok, then the whole string
> is ok.
>
> What is EXIT PERFORM? That's not standard COBOL.
>
> The code should read:
>
> set Goodvalue to true
> Perform varying n from 1 by 1 until n > 8
> move CharM(n) to CharX
> if not (ValidAlpha or ValidNumeric)
> set BadValue to true
> End-if
> End-Perform
Beat you to it - found the error myself :-). 'Though I do admit your :-
if not (ValidAlpha or ValidNumeric)
is better coding than my 'Continue'.
Wanna get into semantics Mr. 'COBOL Best Practices' ? EXIT-PERFORM - No it's not
COBOL '85 but is a Micro Focus extension which is now officially part of COBOL 2002
- no more than you do I want to wait 17 years until it's in a compliant COBOL 2002
compiler..
Make up your mind - which is it - OO is verbose OR the bozos on mainframes wont use
OO ? As for verbosity :-
***** Non- OO
perform BY-NAME-PARA
........
BY-NAME-PARA.
if not ByName
set Byname to true
perform CREATE-NAMELIST
End-if.
**** OO COBOL (M/F without 'Red tape')
invoke self "byName"
..............
Method-id. "byName".
if not ByName
set Byname to true
invoke self "createNamelist"
End-if
End Method "byName".
The OO method contains only one more line of code than the non-OO to signify the
'end' of the 'mini program'. To 'tart' it up I add comment lines for readability.
Jimmy, Calgary AB
Robert Wagner
not
>COBOL '85 but is a Micro Focus extension which is now officially part of COBOL
2002
The syntax is ambiguous. Suppose the program reads:
perform varying ... until ...
perform until ....
if ...
EXIT-PERFORM
end-if
end-perform
end-perform
Which perform does it exit, the inner or the outer?
>Make up your mind - which is it - OO is verbose OR the bozos on mainframes wont
use
>OO ?
I retracted my assertion that OO COBOL is too verbose. I still believe mainframe
bozos .. excuse me, make that 'professionals' .. will be the last to adopt it.
As for verbosity :-
>
>***** Non- OO
>
>perform BY-NAME-PARA
>........
>
>BY-NAME-PARA.
>
>if not ByName
> set Byname to true
> perform CREATE-NAMELIST
>End-if.
>
>**** OO COBOL (M/F without 'Red tape')
>
>invoke self "byName"
>..............
>
>Method-id. "byName".
>if not ByName
> set Byname to true
> invoke self "createNamelist"
>End-if
>End Method "byName".
"set Byname to true" belongs inside the "createNamelist" method. Better
terminology would be 'NamelistCreated' in place of 'Byname'.
Following mainframe standards, that would read 'perform 9000-BY-NAME-PARA'. As
though we didn't know it was a paragraph and couldn't find it with a text
editor.
For an additional touch of realism, comment out rather than delete the old
non-OO code.
I'm pleased to see you using OO COBOL.
Robert
William M. Klein
the rules about EXIT PERFORM. For that matter, I think you use Micro
Focus - read their LRM where they already have it as an extension. (Along
with EXIT PERFORM CYCLE)
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e4b5056...@news.optonline.net...
JerryMouse
"Eddie Veness" <e.ve...@blueyonder.co.uk> wrote in message
news:Wdz2a.904$I06...@news-binary.blueyonder.co.uk...
It's worse than you might think.
The user leaves field A, triggering some kind of lost-focus event. Your code
takes over.
You can check the user's input manually and, if not correct, put him back in
field A until he gets it right.
Cool. Now here's the tricky part:
The user, in leaving the field, goes directly (via a mouse click, say) to
another field, B. The contents of field B depend on the correct value in
field A (say Field A is the customer number and field B is the customer
name).
The got-focus event for field B triggers before the lost-focus for field A.
Immediately upon entering field B, the program uses the value from field A
to do something (like look up the customer's name). If field A is wrong,
BOOM!
We use Fujitsu's PowerCOBOL and this sequence drives us nuts.
Here's one circumvention.
First statement in got-focus event for "A"
Move 'N' to ALLOW-FOCUS.
Lost-focus event for "A"
(after passing all validity checks)
Move "Y" to ALLOW-FOCUS
1st statement in Got-focus event for "B"
If ALLOW-FOCUS = "N"
Exit-program.
(which should get the lost-focus event for "A" as next-from-queue)
What's needed (I'm told) is a robust VALIDATE method as in VB.
B Berman
If there is a 'KeyPress' event, as in VB, you can check each digit entered as
the user enters them, and never leave (lose focus) the text box field.
--
----------------------------------------------------------------------
Bob Berman - Jacksonville, FL
mailto:bbe...@netbox.com website: http://home.attbi.com/~berman.bob
AIM id: bbrmn
----+----+----+----+----+----+----+----+----+----+----+----+----+----+
James J. Gavan
'real' thing. I have a dialog with the left side of screen showing an input record
and the right side showing a listbox of existing records to select from, (sorted
collection). The default for the listbox is display in alphabetical name sequence
and the user can select by Pushbutton to show in PrimeKey sequence or another (when
appropriate). So :-
1. Class Dialog :-
*>--------------------------------------------------------
Method-id. "zCreatePushbutton".
*>--------------------------------------------------------
Local-storage section.
78 DefaultButtonID value 1.
78 ExitButtonID value 55.
01 ls-event pic x(4) comp-5.
01 ls-object object reference.
Linkage section.
copy "dilogprm.new" replacing ==(tag)== by ==lnk==.
Procedure Division using lnk-Params.
move clicked to ls-event
invoke self "getObjectFromId"
using lnk-ID returning ls-object
Evaluate true
when lnk-id = DefaultButtonID *> PB-OK
etc..
when lnk-id = 55 *> PB-Exit
etc...
when other
invoke ls-object "setEventto" using
ls-event, os-Caller, lnk-Methodname
End-Evaluate
*> above 'Caller' is the Edit Program and lnk-Methodname will contain
*> "PB-ByName", "PB-ByKey" or "PB-Other" for this example
End Method "zCreatePushbutton".
*>--------------------------------------------------------
2. Class - Edit Program
*>-------------------------------------------------
Method-id. "PB-ByName".
*>-------------------------------------------------
Procedure Division.
if not Byname of ws-CollectionParams
set ByName of ws-CollectionParams to true
invoke self "initCollection"
End-if
*> "initCollectiuon" picks up on the global setting for the Sequence Flag.
End Method "PB-ByName".
*>-------------------------------------------------
Same sort of code for both 'PB-ByKey" and "PB-ByOther"
- Hope that clarifies usage, as we don't have nested performs.
Jimmy, Calgary AB
Richard
> The syntax is ambiguous. Suppose the program reads:
>
> perform varying ... until ...
> perform until ....
> if ...
> EXIT-PERFORM
> end-if
> end-perform
> end-perform
>
> Which perform does it exit, the inner or the outer?
Which part of the actual rules didn't you read ? What part of 'the
END-PERFORM of the nearest in-line PERFORM' don't you understand ?
BTW it is 'EXIT PERFORM' not 'EXIT-PERFORM'.
> I still believe mainframe bozos ..
>> "they should have at least offered cogent rebuttal rather than
attacking my character."
James J. Gavan
JerryMouse wrote:
> "Eddie Veness" <e.ve...@blueyonder.co.uk> wrote in message
> news:Wdz2a.904$I06...@news-binary.blueyonder.co.uk...
> > I am currently trying to edit a field which is filled by the user with 8
> > digits alphanumeric. I have to prevent the user from being able to leave a
> > space anywhere within those eight digits and finally creat an error
> message.
> > The error message I can handle, I just can't get my head around preventing
> > spaces. I thought at first sight, simple enough but this is getting the
> > better of me. I have not been programming in COBOL for that long and I
> would
> > welcome any help.
>
> It's worse than you might think.
>
Are you trying to scare him to death Jerry :-) He did say he was a 'beginner'.
Hopefully he's OK. I'm not familiar with Dialog System (Pete and Thane both
Fujitsu users know more about Dialog System than I'll ever know - or want to
know !). For each control the DS system allows him to add in-line code to do
his validity checks. If that's not clear then Calin can jump in and expand.
I agree with you gained focus, lost focus and the Event Loop are a real pig,
depending upon what you are trying to do. For the following reasons I use both
'gain' and 'lost' events :-
- Gain Focus - I find it most irritating to backspace to 'clear' an existing
field; so I have two options. (1) 'clear' or 'setEmpty' object - accepts fresh
input from user. From memory that is the way it works with COBOL Screen
Section. (2) Insert mode - don't clear the field, say for SIN, VAT, GST and any
other big numbers. Allow the user to 'insert' new characters as appropriate.
- Lost Focus (1) Do I want to return directly to Business Logic now - user has
entered a new PrimeKey - so check it exists and either display or accept input
for new record. (2) For convenience (some 70% of the application's input) is
decimal inches/cms - 9.999 or 99.999 - which are entered as integers - on lost
focus redisplay with decimal point. (3) Third possibility - user clicks on a
checkbox or radio button - this gives two options (a) Retain value selected
until PB-OK entered or (b) must return the check box/radio button value NOW as
Business Logic may determine that additional controls (currently hidden) now
need to be 'activated' with set enable and show.
I have real fun using both 'gained' and 'lost'. For your ALLOW-FOCUS flag I
utilize methods "accessSystemEvents" and "cancelAccessToSystemEvents" for the
next object(control).
I try to stay within the logic of the Dialog - such as redisplaying decimal
numbers, and same applies to dates where user enters for YYMM a value of '1' -
then I will re-display as 'Jan 2001'. Kind of goes against the grain but for the
most part I'm currently opting for validating input when user enters PB-OK which
triggers the return to the Business class.
I wouldn't claim my approach is the simplest - but with a lot of buggering
around it works !
Jimmy, Calgary AB
Robert Wagner
>The syntax is not at all ambiguous. Read the 2002 Standard and you see all
>the rules about EXIT PERFORM. For that matter, I think you use Micro
>Focus - read their LRM where they already have it as an extension. (Along
>with EXIT PERFORM CYCLE)
I read about it and learned it exits the inner loop. CYCLE exits the iteration.
More literate phrases would be EXIT CYCLE or EXIT ITERATION.
Micro Focus also has EXIT PARAGRAPH, which is the same as NEXT SENTENCE if one
doesn't use periods. I avoid NEXT SENTENCE because it is non-portable. Most
compilers make it synonymous with CONTINUE; Micro Focus thinks it means 'after
the next period'. Restoring the significance of periods, which are generally
regarded as anachronistic, is an error by Micro Focus. In practice, there's a
big difference between CONTINUEing and going to the next period, which is
usually end of paragraph.
Semantically, the EXIT clauses and CONTINUE have the flavor of COBOL because
they begin with a verb, whereas NEXT SENTENCE does not.
All these are disguised GO TOs. I thought we'd learned to do without GO TO.
Robert
JerryMouse
"B Berman" <bbe...@netbox.com> wrote in message
news:3E4BC673...@netbox.com...
Yeah, we use that technique sometimes. In the above scenario, the technique
fails when the user has to enter, say, a five-digit customer number, enters
only 3 digits, then clicks the "Exit" button. That is, customer number lost
focus gets control, determines the customer number is bad, produces warning
message, and sets the focus back to the customer number field. The Exit
event fires. Moan.
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> The syntax is ambiguous. Suppose the program reads:
>>
>> perform varying ... until ...
>> perform until ....
>> if ...
>> EXIT-PERFORM
>> end-if
>> end-perform
>> end-perform
>>
>> Which perform does it exit, the inner or the outer?
>
>Which part of the actual rules didn't you read ? What part of 'the
>END-PERFORM of the nearest in-line PERFORM' don't you understand ?
>
>BTW it is 'EXIT PERFORM' not 'EXIT-PERFORM'.
If you want to elevate your standing in this newsgroup, you'll have to do it by
helping others and generally acting positive. Disparaging my intelligence or
knowledge doesn't make YOU stand any taller. To the contrary, it makes you seem
crotchety.
Your evening postings come through google.com, while your daytime postings come
through kc.net.nz. Do we have a Jekyll-Hyde dynamic going?
Feel free to answer privately if it suits you.
Robert
Richard Plinston
>>> The syntax is ambiguous. Suppose the program reads:
>>> ...
> If you want to elevate your standing in this newsgroup,
My postings are only rarely aimed at trying to inflate any standing that I
may or may not have here, it is only no importance to me at all.
> you'll have to do it by helping others
If I thought that you were a newbie having difficulty finding your way
around then I may have posted the extract from the manual plus a useful
explanation. However, it seemed that you would have already read that and
had formed a definitive conclusion: "The syntax _is_ ambiguous".
> To the contrary, it makes you seem crotchety.
Good, it is working then ;-)
> Your evening postings come through google.com, while your daytime postings
> come through kc.net.nz. Do we have a Jekyll-Hyde dynamic going?
No, it just indicates flexibility.
And of course, it is summer here, and light when all else is dark.
Richard Plinston
> Micro Focus also has EXIT PARAGRAPH, which is the same as NEXT SENTENCE if
> one doesn't use periods.
The use of NEXT SENTENCE in any situation where 'not using periods' is
viable is disallowed by the '85 standard, though this is an extension by MF.
> Most compilers make it synonymous with CONTINUE; Micro Focus thinks it
> means 'after the next period'.
The standard states that it is disallowed anywhere this difference in
interpreation would make a difference.
> Semantically, the EXIT clauses and CONTINUE have the flavor of COBOL
> because they begin with a verb, whereas NEXT SENTENCE does not.
Syntactically the NEXT SENTENCE is not a statement (though it is as an
extension in MF) but is a phrase in the IF statement.
William M. Klein
Can you provide an example of ANY (much less "most") compilers think that
"Next Sentence" and "Continue" are "synonymous"?
It is true that in *most* (but definitely not all) ANSI/ISO conforming
cases, the two are the same - but I know of *no* compiler that treats them
as identical in the following "fully conforming" source code:
If Test1 = "1"
If Test 2 = "2"
Display "1 and 2"
Else
Display "Compile with either Next Sentence or Continue to get
different results"
If Test3 = "3"
If Test4 = "4"
Next Sentence
* or *> give different results
Compile
Else
Continue
* No END-IF occurs here - so there is no END-IF with a NEXT
SENTENCE
* Outer ELSE terminated IF ... NEXT SENTENCE ELSE ... construct
Else
Display "Test 3 is false"
End-If
Display "Test 3 is true or false - but CONTINUE is coded"
End-If
Display "Test 2 is true or false - but continue is coded"
End-If
Display "Always displayed with CONTINUE - never with NEXT Sentence"
.
Display "Next Sentence goes here"
***
Note: If you try this on any ANSI'85 conforming compiler and it fails to
compile cleanly (with either CONTINUE or NEXT SENTENCE - but not both) then
you have a "bug" in that compiler. The '85 Standard is "clear" that this is
legal and NEXT SENTENCE and CONTINUE are *definably" different things. If
your style doesn't allow for periods within paragraphs, then you don't need
that last sentence - it is just there to show the difference between the two
constructs more clearly.
.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e4c333b...@news.optonline.net...
> "William M. Klein" <wmk...@ix.netcom.com> wrote:
>
<snip>
> Most
> compilers make it synonymous with CONTINUE; Micro Focus thinks it means
'after
> the next period'.
<snip>
Richard Plinston
> Can you provide an example of ANY (much less "most") compilers think
> that
> "Next Sentence" and "Continue" are "synonymous"?
My understanding is that MicroFocus originally implemented their '85
compiler Cobol/2 version 1.x) with this, but quickly realised that the it
should be 'next full stop' and changed it.
> The '85 Standard is "clear" that this is legal
I am not convinced that the standard itself is clear that this is legal. I
do understand that a clarification was asked for (and this alone implies
that it wasn't clear), and that it was eventuially agreed that a nested IF
with a NEXT SENTENCE phrase and without and END-IF within an IF .. END-IF
was not disallowed by the standard when taken absolutely literally as
written.
I am sure that this was unintentional and that NEXT SENTENCE should be
disallowed anywhere within any IF .. END-IF.
Calin @ Work
ask the user "sure you wish to do that?" and then go quietly. :-)
Normally in the lost focus routine you check if the gain focus was on the
cancel button and act accordingly (i.e. don't validate).
Calin, TORONTO
"JerryMouse" <nos...@bisusa.com> wrote in message
news:2e-dnbMYHqH...@giganews.com...
Howard Brazee
On 13-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> Micro Focus also has EXIT PARAGRAPH, which is the same as NEXT SENTENCE if one
> doesn't use periods. I avoid NEXT SENTENCE because it is non-portable. Most
> compilers make it synonymous with CONTINUE; Micro Focus thinks it means 'after
> the next period'. Restoring the significance of periods, which are generally
> regarded as anachronistic, is an error by Micro Focus. In practice, there's a
> big difference between CONTINUEing and going to the next period, which is
> usually end of paragraph.
I have argued against the elimination of periods on this forum before - and in
those discussions, the only reason I have seen for the one period paragraphs is
"it makes cutting and pasting easier". Bah. Fortunately, I have never had to
work with coders who believe periods are anachronistic. To me, code that
depends upon a stylistic trick such as only having a period at the end of a
paragraph is non-portable and dangerous.
But my question is: Which are these "most compilers" that make NEXT SENTENCE
synonymous with CONTINUE? I was not aware that any compilers did this, much
lest most.
> Semantically, the EXIT clauses and CONTINUE have the flavor of COBOL because
> they begin with a verb, whereas NEXT SENTENCE does not.
>
> All these are disguised GO TOs. I thought we'd learned to do without GO TO.
Certainly not in maintenance where we like to make minimal changes to a working
program.
Chuck Stevens
> Micro Focus also has EXIT PARAGRAPH, which is the same as NEXT SENTENCE if
one
> doesn't use periods.
The current ISO standard includes both EXIT PARAGRAPH and EXIT SECTION.
> I avoid NEXT SENTENCE because it is non-portable. Most
> compilers make it synonymous with CONTINUE; Micro Focus thinks it means
'after
> the next period'.
Silly Micro Focus. Can you imagine any implementor with the remotest
consideration for portability actually producing a compiler that does what
every standard from at the latest ANSI X3.23-1968 through the current ISO
standard has required that NEXT SENTENCE actually accomplish? ;-)
> Restoring the significance of periods, which are generally
> regarded as anachronistic, is an error by Micro Focus. In practice,
there's a
> big difference between CONTINUEing and going to the next period, which is
> usually end of paragraph.
The current ISO standard does have more ways of limiting periods to the ends
of paragraphs, but that's not the only meaningful, clear, legible way to
write COBOL programs. Thus far, sentences terminated by periods within
paragraphs has not (yet) been marked an archaic element in standard COBOL.
Programs *can* be written so that intermediate periods are unnecessary, but
there is no particular reason other than style (either individual or site
standards) to do so. That *you* regard periods as unconditionally
anachronistic, and that many of the people who jump onto the latest
bandwagon of programming style regard them as unconditionally anachronistic,
does not necessarily make it so.
> Semantically, the EXIT clauses and CONTINUE have the flavor of COBOL
because
> they begin with a verb, whereas NEXT SENTENCE does not.
I'm not sure about the reasoning of "flavor of COBOL", but NEXT SENTENCE is
marked as an archaic element in the current ISO standard on the grounds that
scope delimiters and CONTINUE provide equivalent functionality without
falling into the trap that "most implementors" have fallen into! See
ISO/IEC 1989:2002 Page 833, G.1, Archaic language elements, item 3, NEXT
SENTENCE phrase in IF and SEARCH statements.
-Chuck Stevens
Chuck Stevens
"Howard Brazee" <howard...@cusys.edu> wrote in message
news:b2j3b6$qq8$1...@peabody.colorado.edu...
> But my question is: Which are these "most compilers" that make NEXT
SENTENCE
> synonymous with CONTINUE? I was not aware that any compilers did this,
much
> lest most.
I can't answer the first question, although there are apparently some that
make this error, and that leads to further comments on your second sentence
above. ISO/IEC 1989:2002 states in its justification for the archaization
of NEXT SENTENCE: "This phrase can be confusing, especially when specified
in a delimited-scope statement. It is a common belief among users that
control is transferred to a position after the scope-delimiter rather than
to a separator period that follows it somewhere." That second sentence
leads me to believe that some implementors might have MISinterpreted the
functioning of NEXT SENTENCE.
I agree with you that a "sentence" in COBOL terms is not synonymous with an
"imperative statement"; the former is ALWAYS terminated by a period, and
thus it seems to me that a control transfer to NEXT SENTENCE is ALWAYS to
the beginning of whatever sentence follows the period that marks the end of
the CURRENT sentence. That users (and perhaps implementors) have
misunderstood the fact that in COBOL a SENTENCE has ended with a terminator
period since the beginning of time is unfortunate, but it's a
misunderstanding nonetheless. That's part of the reason the current
standard recommends avoiding it.
-Chuck Stevens
Howard Brazee
On 14-Feb-2003, "Chuck Stevens" <charles...@unisys.com> wrote:
> I agree with you that a "sentence" in COBOL terms is not synonymous with an
> "imperative statement"; the former is ALWAYS terminated by a period, and
> thus it seems to me that a control transfer to NEXT SENTENCE is ALWAYS to
> the beginning of whatever sentence follows the period that marks the end of
> the CURRENT sentence. That users (and perhaps implementors) have
> misunderstood the fact that in COBOL a SENTENCE has ended with a terminator
> period since the beginning of time is unfortunate, but it's a
> misunderstanding nonetheless. That's part of the reason the current
> standard recommends avoiding it.
I would be surprised if implementers were confused. I do know that IBM
mainframes allow it even when followed by an END-IF. But it still goes to the
next period. I don't use it and go so far as to replace it in maintenance
programs.
I am very much against the practice mentioned in this thread of making it the
equivalent of an EXIT PARAGRAPH, assuming that the paragraph is exactly one
sentence long.
Chuck Stevens
> I am very much against the practice mentioned in this thread of making it
the
> equivalent of an EXIT PARAGRAPH, assuming that the paragraph is exactly
one
> sentence long.
Aye, there's the rub. If your paragraph is exactly one sentence long, then
a NEXT SENTENCE appearing within that sentence rightly transfers control the
same as EXIT PARAGRAPH would.
A not particularly serious proposal: If NEXT SENTENCE is going to remain
in the standard, perhaps we need to add EXIT SENTENCE as a synonym for it.
That way, the verb would be imperative, and it would be semantically and
syntactically parallel to all the other EXITs!
-Chuck Stevens
Richard
> To me, code that
> depends upon a stylistic trick such as only having a period at the end of a
> paragraph is non-portable and dangerous.
While I have no issue with your liking of full stops, I would like to
know why you categorize 'minimum full stops' in this way.
* In what way does the code _depend_on_ not having full stops ?
Stops could be added anywhere that is not within a structure, just as
you would have them, without changing the meaning. There is no
dependancy.
* In what way is it a stylistic 'trick' ?
How does it trick anything ?
* In what way is it non-portable ?
Which compilers or operating systems won't compile it to work
identically ?
* In what way is it dangerous ?
Compared to, say, having extra full-stops accidentally left in a block
under an IF.
Robert Wagner
>
>"Howard Brazee" <howard...@cusys.edu> wrote in message
>news:b2j3b6$qq8$1...@peabody.colorado.edu...
>
>> But my question is: Which are these "most compilers" that make NEXT
>SENTENCE
>> synonymous with CONTINUE? I was not aware that any compilers did this,
>much
>> lest most.
>
>I can't answer the first question, although there are apparently some that
>make this error, and that leads to further comments on your second sentence
>above. ISO/IEC 1989:2002 states in its justification for the archaization
>of NEXT SENTENCE: "This phrase can be confusing, especially when specified
>in a delimited-scope statement. It is a common belief among users that
>control is transferred to a position after the scope-delimiter rather than
>to a separator period that follows it somewhere." That second sentence
>leads me to believe that some implementors might have MISinterpreted the
>functioning of NEXT SENTENCE.
In my experience, most of them misinterpreted it.
>I agree with you that a "sentence" in COBOL terms is not synonymous with an
>"imperative statement"; the former is ALWAYS terminated by a period, and
>thus it seems to me that a control transfer to NEXT SENTENCE is ALWAYS to
>the beginning of whatever sentence follows the period that marks the end of
>the CURRENT sentence. That users (and perhaps implementors) have
>misunderstood the fact that in COBOL a SENTENCE has ended with a terminator
>period since the beginning of time is unfortunate, but it's a
>misunderstanding nonetheless. That's part of the reason the current
>standard recommends avoiding it.
This raises the question of what a sentence is. In English, as sentence may be
terminated by a period (full stop), question mark, explanation point (bang) or
NOTHING AT ALL. For example, if I were writing "The file name is foo.txt", I
would omit a period after txt to avoid the reader cutting and pasting an
extraneous period. I'd leave two spaces and capitalize the first word of the
next sentence. Similarly, if I wrote "Please email me at x...@y.com", I would omit
a period after com.
I contend a sentence is defined by its syntactical structure rather than by a
punctuation terminator. In the case of COBOL, the structure is V S O (... O).
When I write "move a to b move c to d", syntactically there are two sentences.
Robert
Richard
> In my experience, most of them misinterpreted it.
Please list your 'experience' of sufficient vendor implementations and
indicate which 'misinterpreted' it, and in what way, to justify your
claim of 'most'.
Given that you have also stated that "Most compilers make it
synonymous with CONTINUE" you may like to mention specifically which
ones that you imagine actualy do this.
The _only_ compiler that I know of that did this was a very early MF
Cobol/2 which was released _before_ the '85 standard was finalised and
thus wasn't necessarily a misinterpretation, but may have been based
on drafts that changed.
> This raises the question of what a sentence is.
> In English, ....
Completely irrelevant. This isn't english, or greek, or even
'merican. It is COBOL, and sentences are completely defined in the
language. If you had read a manual on the language you would know
that.
> I contend a sentence is defined by its syntactical structure rather than by a
> punctuation terminator. In the case of COBOL, the structure is V S O (... O).
> When I write "move a to b move c to d", syntactically there are two sentences.
You can't just make up your mind about something and then claim it as
some sort of revealed truth. If you had two clues to rub together you
would know that those are two _statements_ and a 'sentence' is
_defined_ as being terminated by a full stop and a space.
Your arguments also lack coherence.
Yours claims have been:
Most implentations misinterpreted it.
Most treat is as CONTINUE.
These are quite wrong, but you do seem to think that NEXT SENTENCE
does go to 'the next full stop', while arguing that sentences should
not need to end in a full stop.
You have shown that you _can_ 'read and learn' about EXIT PERFORM, now
try the rest of the manual.
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> In my experience, most of them misinterpreted it.
>
>Given that you have also stated that "Most compilers make it
>synonymous with CONTINUE" you may like to mention specifically which
>ones that you imagine actualy do this.
I must concede defeat on this point. I searched most of the COBOL source on my
home PC, some of which dates back to 1990. There was not a single instance of
NEXT SENTENCE, while there were many CONTINUEs. Next I wrote a test program and
compiled it with Realia v3.1 dated 1987. It performed as you said -- by
transferring control to the next 'COBOL sentence' following a full stop.
Fujitsu v3 issued a Warning:
'NEXT SENTENCE' CANNOT BE SPECIFIED IN IF OR SEARCH STATEMENT WITH EXPLICIT
SCOPE TERMINATOR. ACCEPTED AS WRITTEN.
The executable did go to the next 'COBOL sentence'.
>These are quite wrong, but you do seem to think that NEXT SENTENCE
>does go to 'the next full stop', while arguing that sentences should
>not need to end in a full stop.
I said Micro Focus goes to a full stop, which I believed to be discrepant with
most other compilers. Now I see they all do it.
I must have discovered this in the '80s, stopped using NEXT SENTENCE, and
forgotten why.
Robert
Howard Brazee
On 14-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> That second sentence
> >leads me to believe that some implementors might have MISinterpreted the
> >functioning of NEXT SENTENCE.
>
> In my experience, most of them misinterpreted it.
So you have an example?
> This raises the question of what a sentence is. In English, as sentence may be
> terminated by a period (full stop), question mark, explanation point (bang) or
> NOTHING AT ALL. For example, if I were writing "The file name is foo.txt", I
> would omit a period after txt to avoid the reader cutting and pasting an
> extraneous period. I'd leave two spaces and capitalize the first word of the
> next sentence. Similarly, if I wrote "Please email me at x...@y.com", I would
> omit a period after com.
I haven't heard this definition before. Do you have a citation? I generally
put in a space before the period as the best way to emulate a sentence in this
example. But this is English you're talking about. COBOL is an English-like
language, but it is not English.
> I contend a sentence is defined by its syntactical structure rather than by a
> punctuation terminator. In the case of COBOL, the structure is V S O (... O).
> When I write "move a to b move c to d", syntactically there are two sentences.
Not in COBOL. A COBOL sentence has a very specific definition.
Howard Brazee
On 14-Feb-2003, rip...@Azonic.co.nz (Richard) wrote:
> > To me, code that
> > depends upon a stylistic trick such as only having a period at the end of a
> > paragraph is non-portable and dangerous.
>
> While I have no issue with your liking of full stops, I would like to
> know why you categorize 'minimum full stops' in this way.
I don't understand what you're asking here. Specifically what is "minimum full
stops"?.
> * In what way does the code _depend_on_ not having full stops ?
If "Next Sentence" is used to mean the same thing as "Exit Paragraph", then
having a period before the end of the paragraph will have it work incorrectly.
> Stops could be added anywhere that is not within a structure, just as
> you would have them, without changing the meaning. There is no
> dependancy.
The concept of "go to next period" is dangerous when a period could be added
without a syntax check.
> * In what way is it a stylistic 'trick' ?
To make it mean "Exit Paragraph", then you must use a style. (one I haven't
seen used).
> How does it trick anything ?
It tricks maintenance programmers.
> * In what way is it non-portable ?
Programmers will do conversions - it is best to make your code obvious to some
contract programmer who isn't used to your style.
> Which compilers or operating systems won't compile it to work
> identically ?
>
> * In what way is it dangerous ?
It tricks maintenance programmers.
> Compared to, say, having extra full-stops accidentally left in a block
> under an IF.
If a period is left in before an END-IF, then the compiler will tell you.
Richard
> > > To me, code that
> > > depends upon a stylistic trick such as only having a period at the end of a
> > > paragraph is non-portable and dangerous.
I now understand that you aren't against 'only having a period at the
end of a paragraph', you are against next sentence in conjuction with
END-IF.
As next sentence is disallowed by the standard in any structure that
has an END-IF or END-SEARCH, then any use of next sentence in these
conditions is indeed a stylistic trick that is dangerous and
non-portable.
* I do know that a clarification has conceeded that the standard was
insufficiently rigorous and that some contrived usage of next sentence
is not specifically disallowed as it should be.
Howard Brazee
On 17-Feb-2003, rip...@Azonic.co.nz (Richard) wrote:
> > > > To me, code that
> > > > depends upon a stylistic trick such as only having a period at the end
> > > > of a
> > > > paragraph is non-portable and dangerous.
>
> I now understand that you aren't against 'only having a period at the
> end of a paragraph', you are against next sentence in conjuction with
> END-IF.
This latter is what I was calling dangerous. It's not clear from above that the
it isn't the "stylistic trick" that bothered me - it was the way NEXT SENTENCE
as an EXIT PARAGRAPH depended upon that style that I considered dangerous.
> As next sentence is disallowed by the standard in any structure that
> has an END-IF or END-SEARCH, then any use of next sentence in these
> conditions is indeed a stylistic trick that is dangerous and
> non-portable.
>
> * I do know that a clarification has conceeded that the standard was
> insufficiently rigorous and that some contrived usage of next sentence
> is not specifically disallowed as it should be.
Specifically, IBM has chosen to allow a NEXT SENTENCE within an IF END-IF loop.
Using the NEXT SENTENCE as a replacement for END PARAGRAPH (which is not yet
available in my compiler), is non-portable as well.
Chuck Stevens
> This raises the question of what a sentence is. In English, as sentence
may be
> terminated by a period (full stop), question mark, explanation point
(bang) or
> NOTHING AT ALL. ...
> I contend a sentence is defined by its syntactical structure rather than
by a
> punctuation terminator. In the case of COBOL, the structure is V S O (...
O).
> When I write "move a to b move c to d", syntactically there are two
sentences.
Contend away.
It would probably be much less frustrating for you to determine what
definitions the rules for COBOL apply to terms like this rather than use
rules you think ought to apply and then find that they don't work the way
you want them to.
COBOL is, to be sure, based on the form of the English imperative sentence.
However, the rules for the formation of COBOL sentences (and COBOL
statements comprising COBOL sentences) are quite different from similar
rules for English (or German or Hill Bondo or Tlingkit).
I think if you studied the rules below and apply them to your COBOL
programming you would likely find yourself less frustrated with what you
perceive as the language's disconnect with reality as you wish to define
that reality to be. Herewith reality for COBOL as defined in the "grammar
rules" for that language:
ANSI X3.23-1974, Page I-68, Section 4: Glossary, defines "Sentence" as
follows: "A sequence of one or more statements, the last of which is
terminated by a period followed by a space." On Page I-70, this standard
also defines "Statement" as "A syntactically valid combination of words and
symbols written in the Procedure Division beginning with a verb."
ANSI X3.23-1985, Page III-22, Section III: Glossary, defines "Sentence" as
"A sequence of one or more statements, the last of which is terminated by a
separator period." On Page III-24, the definition for "Statement" is "A
syntactically valid combination of words, literals, and separators,
beginning with a verb, written in a COBOL source program."
ISO/IEC 1989:2002, Page 382, Section 14.4, Procedural statements and
sentences, contains the definition for "sentence" as follows: "A sentence
is a sequence of one or more procedural statements, the last of which is
terminated by a separator period." The same section defines "procedural
statement" as "A procedural statement is a unit of the COBOL language that
specifies an action to be taken. Statement names are identified in table
13, Procedural statements." This section goes on to explain that there are
three types of statements: declarative, imperative and conditional, and the
aforementioned table.
I have not yet been able to get my hands on a copy of ANSI X3.23-1968 (I
have been trying to locate one for some years), but a copy of the "IBM DOS
Full American National Standard COBOL" dated May 1973 (file no. S360-24;
order No. GC28-6394-4) to which I have access has this to say: "The
statement is the basic unit of the Procedure Division. A statement is a
syntactically valid combination of words and symbols beginning with a COBOL
verb. ..." and "A sentence is composed of one or more statements. The
statements may optionally be separated by semicolons [or the word THEN]. A
sentence must be terminated by a period followed by a space." (The phrase
in brackets in this quotation is identified as an IBM extension to standard
COBOL).
Likewise, the Unisys A Series COBOL ANSI-68 Programming Reference Manual
(Form 8600 0320, dated September 1991) states, under "Rules of procedure
formation" in Section 7: "The Procedure Division": "A sentence consists of
one or more statements and is terminated by a period followed by a space."
and "A statement is a syntactically valid combination of words and symbols
beginning with a COBOL verb." My guess is, based on past experience, that
the wording in this manual is quite close to that in the 1968 standard.
Using your terms, it is a STATEMENT (not a sentence) that begins with a
"V"erb, and it isn't always defined as followed by an optional "S"ubject"
and an optional "Object". I would argue that even in ENGLISH, "Move a to b
move c to d", "Move a to b; move c to d." and even the IBM extension "Move a
to b then move c to d." represent multiple STATEMENTS ("main clauses" in
Webster's Ninth definition of "compound sentence") that comprise arguably
single SENTENCES.
-Chuck Stevens
William M. Klein
eliminated the concept of a "verb" in COBOL. This was *not* a change that I
was happy with - but did please people who didn't like calling the COBOL
word "IF" a "verb". There is no replacement term introduced - all there is,
is a list of reserved words that start (procedural) statements.
It should be noted that the '85 Standard was a little (well actually QUITE)
sloppy on the use of the terms "verb" versus the term "statement".
None of this changes (in any way) the fact that a COBOL sentence is, was,
and probably will be for a long time in the future well defined as 1 or more
statements followed by a separator period.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles...@unisys.com> wrote in message
news:b2tqkp$6l1$1...@si05.rsvl.unisys.com...
Robert Wagner
>that reality to be. <snip>
>Using your terms, it is a STATEMENT (not a sentence) that begins with a
>"V"erb, and it isn't always defined as followed by an optional "S"ubject"
>and an optional "Object". I would argue that even in ENGLISH, "Move a to b
>move c to d", "Move a to b; move c to d." and even the IBM extension "Move a
>to b then move c to d." represent multiple STATEMENTS ("main clauses" in
>Webster's Ninth definition of "compound sentence") that comprise arguably
>single SENTENCES.
I cannot dispute the Rules of COBOL, which are clearly stated in the citations
you gave and I deleted for brevity. My problem is with incorrect word usage.
A STATEMENT is bigger than a sentence. A statement can use more than one
sentence. The word they should have used is CLAUSE.
Collins English Dictionary defines Sentence as: "a sequence of words capable of
standing alone to make an assertion, ask a question, or give a command, usually
consisting of a subject and a predicate containing a finite verb." Simplified,
one subject and one predication. Note the lack of reference to punctuation.
Vocal English doesn't use punctuation nor does poetry, in many instances. Only
written English (and other languages with a writing tradition) use punctuation,
and when it does, a Compound Sentence is punctuated by a semi-colon (not
commonly used in COBOL) or the word 'then' (an IBM extension). Lacking those
two, one clause is the 'main clause' while the others are subordinate. COBOL
doesn't have Compound Sentences.
When scores on English language SAT are corelated with college major, computer
science comes in dead last .. below business, below education, below home
economics.
What we have is a struggle between technicians who want to preserve the period
because they think it makes parsing easier vs. COBOL practitioners with some
literacy and 40 years bad experience with errant periods, especially the periods
that land in column 73. The 2002 standard recommends against using periods while
ambivalantly making them significant in NEXT SENTENCE.
My Best Practice is don't use periods and don't use NEXT SENTENCE. Both are in
the same Legacy boat.
Robert
Chuck Stevens
> I cannot dispute the Rules of COBOL, which are clearly stated in the
citations
> you gave and I deleted for brevity. My problem is with incorrect word
usage.
>
> A STATEMENT is bigger than a sentence. A statement can use more than one
> sentence. The word they should have used is CLAUSE.
Sigh.
ANSI X3.23-1974, Page I-53, Section I, "Introduction to the Standard", Topic
4: Glossary: "A clause is an ordered set of consecutive COBOL
character-strings whose purpose is to specify an attribute of an entry."
ANSI X3.23-1974, Page I-64, same section, same topic: "A phrase is an
ordered set of one or more consecutive COBOL character-strings that form a
portion of a COBOL procedural statement or of a COBOL clause."
If the standard were a grammar of written English, maybe. It's not a
grammar of written English, it's a grammar of COBOL, and the definitions of
the various components of the language are specified in that grammar. And
for the purposes of this discussion, the hierarchy in the Procedure Division
IS: phrase, clause, statement, sentence, paragraph, section. Best I can
tell, it's been that way since 1960.
If pigs had wings they could fly. If we had some ham, we could have some
ham and eggs, if we had some eggs. Shoulda. Woulda. Coulda.
> Collins English Dictionary defines Sentence as: "a sequence of words
capable of
> standing alone to make an assertion, ask a question, or give a command,
usually
> consisting of a subject and a predicate containing a finite verb."
Simplified,
> one subject and one predication. Note the lack of reference to
punctuation.
The definition of "sentence" in COBOL is not found in the Collins English
Dictionary, it is found in the COBOL standard.
That being said, I prefer the Merriam-Webster dictionaries as more
definitive of American English (just as I prefer the Oxford for English
English). The definition in the Ninth New Collegiate I have handy does
include reference to end punctuation (though indicates that it is optional).
> Vocal English doesn't use punctuation nor does poetry, in many instances.
Only
> written English (and other languages with a writing tradition) use
punctuation,
> and when it does, a Compound Sentence is punctuated by a semi-colon (not
> commonly used in COBOL) or the word 'then' (an IBM extension). Lacking
those
> two, one clause is the 'main clause' while the others are subordinate.
COBOL
> doesn't have Compound Sentences.
I know of languages that do not distinguish between word, clause, sentence
and utterance. What's your point? What English does does not necessarily
apply to what Hill Bondo or Tlingkit or Tagalog or Mandarin do. Or COBOL.
> What we have is a struggle between technicians who want to preserve the
period
> because they think it makes parsing easier vs. COBOL practitioners with
some
> literacy and 40 years bad experience with errant periods, especially the
periods
> that land in column 73.
What we have is the desire to preserve the value of existing programs as
they stand unless there is an overriding reason to make some component of
such programs obsolete. What we have here is a sizeable body of people who
are called upon to maintain code that's been running just fine, thank you
very much, for a very long time.
<<The 2002 standard recommends against using periods while
> ambivalantly making them significant in NEXT SENTENCE.
NEXT SENTENCE is an ARCAIC element in ISO/IEC 1989:2002, and has been in
COBOL for a VERY long time (as previously indicated), and in every standard
in which it exists, it, and the associated "SENTENCE", mean EXACTLY what the
standard says they mean. With some fleshing out of scope terminators in '02
COBOL, it is now POSSIBLE to AVOID periods, if you choose to do so as a
matter of style, but the 2002 standard does NOT MAKE periods any more
significant than they were in '85, '74 or '68, and the standards committee
is not likely to make "inter-paragraph" periods archaic, obsolescent,
obsolete OR illegal in COBOL until there's SUBSTANTIAL evidence that VERY
few EXISTING applications will be adversely affected -- whether they were
originally written last week or forty years ago.
> My Best Practice is don't use periods and don't use NEXT SENTENCE. Both
are in
> the same Legacy boat.
That's fine for you. Your choice. And as to NEXT SENTENCE, the standards
folks actually agree with you (though I could be convinced that EXIT
SENTENCE might be of value as a synonym)! But are you certain no
programmer's EVER going to cause your programs to break by adding periods
(or paragraph-names, for whatever reason)? And do you feel justified in
taking the position "Well, HE can't POSSIBLY know REAL COBOL because HE
actually thinks that periods can be used in the PROCEDURE DIVISION!" without
being willing to bear any responsibility for, say, the company's bankruptcy?
All *his* fault for not being fluent in your style as pronounced by you as
Universal Truth, ex cathedra by virtue of your ordination? I'm not
convinced.
-Chuck Stevens
Richard Plinston
> I cannot dispute the Rules of COBOL,
> A STATEMENT is bigger than a sentence. A statement can use more than one
> sentence. The word they should have used is CLAUSE.
You then immediately turn around and dispute them.
> Collins English Dictionary defines Sentence as:
It ain't English, get over it.
> What we have is a struggle between technicians who want to preserve the
> period because they think it makes parsing easier
Why would you think it make parsing easier ?
> The 2002 standard
> recommends against using periods while ambivalantly making them
> significant in NEXT SENTENCE.
The standard disallows use of NEXT SENTENCE in any situation where it would
make a difference. It may only be used in an IF or SEARCH that is
terminated by a full stop (or specifically does not have an END-IF or
END-SEARCH).
It is only when it is used as an extension (such as MF) or is contrived to
defeat the intent of the standard that there would be any difference.
The _standard_ makes no such significance for NEXT SENTENCE and full stops
that you claim.
How hard it that to understand ?
James J. Gavan
Robert Wagner wrote:
> "Chuck Stevens" <charles...@unisys.com> wrote:
>
Gawd ! I jes keep on checkin' this one - jes in case there's actually something
about the topic MICRO FOCUS DIALOG SYSTEM
Can some brave heart start a new thread with "Robert versus the Rest : Was Dialogue
System ". Could always loop back to 'Best Practices' <G>
I don't suppose it matters a dam, but Chuck, your extracts/definition of clauses,
sentences etc. convinced me. Hey it was easier for you than Colin Powell at the UN.
Sacre Bleu !
Jimmy
William M. Klein
that the '85 Standard did (whether intentionally or not) make a real
difference between NEXT SENTENCE and CONTINUE in *fully* conforming source
code. The rule is that the NEXT SENTENCE phrase may not be *immediately*
in an IF that is terminated by an END-IF. However, it may well be in an IF
that is terminated by the ELSE of a containing IF that does, itself end in
an END-IF. This means that it is entirely possible to have '85 Standard
conforming source code that requires that a compiler (and a programmer)
knows the difference between the two.
Having said that, Robert was mistaken in most of the rest of what he wrote,
so I hope he understood the intent of your note.
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:b31d8l$vd5$1...@aklobs.kc.net.nz...
Richard
> Sorry Richard, but as previously stated - both J4 and WG4 have confirmed
> that the '85 Standard did (whether intentionally or not) make a real
> difference between NEXT SENTENCE and CONTINUE in *fully* conforming source
> code. The rule is that the NEXT SENTENCE phrase may not be *immediately*
> in an IF that is terminated by an END-IF. However, it may well be in an IF
> that is terminated by the ELSE of a containing IF that does, itself end in
> an END-IF. This means that it is entirely possible to have '85 Standard
> conforming source code that requires that a compiler (and a programmer)
> knows the difference between the two.
I am aware that the committees have had to agree that the wording of
the standard can be contrued to allow some contrived constructs
designed to fit the letter of the rules rather than what I believe to
be the intent.
Of course some extensions also allow there to be a difference too.
Robert Wagner
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e5423be....@news.optonline.net...
>The definition of "sentence" in COBOL is not found in the Collins English
>Dictionary, it is found in the COBOL standard.
Let's put aside my comparison of COBOL grammar to English grammar and your
appeal to authority. I'll try to explain my objection to periods in abstract
terms that a systems-oriented person might find more understandable.
We're all familiar with systems designed in layers. For instance, the ISO
7-layer model for communication. A cardinal tenant of this design is that each
layer be self-contained. A structure initiated at level n should be terminated
at level n, not by a sub rosa 'pass-through' from level n-1.
The grammar of all languages -- English, COBOL and (whatever) -- contains two
layers: lexicon and syntax. Lexicon deals with the meaning of words; syntax
deals with the assemblage of words into larger structures such as clauses and
sentences. When I write language processing programs, including COBOL
compilers,I write one layer that deals with lexicon and a separate layer that
deals with syntax.
Punctuation such as the period are words. Technically, they are called
logographs, meaning 'a symbol representing a word'. An easy example is '=',
which is synonymous with 'equal to'.
Because syntax deals with sentences, the logic about what terminates a sentence
should be at the syntax level. It should not be 'passed-through' from the
lexicon level.
Does this make sense?
>are you certain no
>programmer's EVER going to cause your programs to break by adding periods
>(or paragraph-names, for whatever reason)? And do you feel justified in
>taking the position "Well, HE can't POSSIBLY know REAL COBOL because HE
>actually thinks that periods can be used in the PROCEDURE DIVISION!" without
>being willing to bear any responsibility for, say, the company's bankruptcy?
>All *his* fault for not being fluent in your style as pronounced by you as
>Universal Truth, ex cathedra by virtue of your ordination? I'm not
>convinced.
When systems malfunction, there are two approaches to providing a solution. The
rational approach asks 'how can we prevent this from happening again'? The
emotional approach asks 'who's guilty?', we want to punish the guilty.' The
emotional approach provides short-term self-gratification by giving the
appearance something is being done, perhaps a deterrent put in place, when we
know in our heart it isn't so.
By shifting the discussion from 'what's right' to 'who's guilty', you are
attempting to move it from the rational plane to the emotional.
Policy determines the fate of systems and institutions; Politics determines the
fate of individual people. The former is hopefully rational; the latter is
always emotional. I find it more productive to pursue rational solutions.
Robert
Howard Brazee
On 19-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> I cannot dispute the Rules of COBOL, which are clearly stated in the citations
> you gave and I deleted for brevity. My problem is with incorrect word usage.
>
> A STATEMENT is bigger than a sentence. A statement can use more than one
> sentence. The word they should have used is CLAUSE.
In English a statement can be bigger than a sentence, it can be smaller than a
sentence, it can be the same size as a sentence. It is "a single declaration or
remark".
Which is also is true with a statement in CoBOL.
A clause is "a group of words containing a subject and predicate and functioning
as a member of a complex or compound sentence". A predicate may or may not
include a verb.
> My Best Practice is don't use periods and don't use NEXT SENTENCE. Both are in
> the same Legacy boat.
So you are upset because CoBOL isn't English enough for you in it's definitions
of statement and sentence - so you recommend making it more English by only
using a period to end a paragraph. All paragraphs are one sentence long.
Just like English...
Anyway, I don't use NEXT SENTENCE, and I do use END IF. Given that, what
advantage would my programs gain if they didn't have periods?
Richard
> >The definition of "sentence" in COBOL is not found in the Collins English
> >Dictionary, it is found in the COBOL standard.
>
> Let's put aside my comparison of COBOL grammar to English grammar and your
> appeal to authority.
Chuck's wasn't an 'appeal to authority', it was simply pointing out
that when you contrived an 'appeal to authority', you used the wrong
authority:
>> Collins English Dictionary defines Sentence as: ...
> I'll try to explain my objection to periods in abstract
> terms that a systems-oriented person might find more understandable.
We are not arguing because we don't understand exactly what it is you
are saying, we are arguing because you are wrong. Using condecending
terms doesn't make us more sympathetic to your ideas.
> [irrelelevant material deleted]
> Punctuation such as the period are words. Technically, they are called
> logographs, meaning 'a symbol representing a word'. An easy example is '=',
> which is synonymous with 'equal to'.
Punctuation is _not_ 'a symbol representing a word'. An '=' symbol is
_not_ punctuation. The two groups of symbols are quite distinct
(though the same grphic may be used in both groups differently). You
are confused because each punctuation symbol has a name (or several),
it doesn't mean that it is a symbol for that word.
> Because syntax deals with sentences, the logic about what terminates
> a sentence should be at the syntax level.
I thought that you said you were going to "put aside my comparison of
COBOL grammar to English grammar".
Natural languages are primarily spoken. Sentences are terminated by
vocal signals: pauses or changes of inflection and intonation. When
the language is written down it uses symbols to represent the
vocalisation. In English (and several others) these symbols include
',;:." which represent different lengths of pausing, and "()-?!" which
also indicate changes in inflection and emphasis.
Cobol and other computer languages are not spoken. They do not use
the punctuation symbols to indicate the same things. Your attempt at
imposing rules intended to assist written forms of natural language
rules makes no sense at all. While there may be some superficial
similarities to written natural languages this does not mean that
Cobol should use inappropriate rules.
> Does this make sense?
Only to you.
If you don't like the way Cobol is defined then go and find a language
you prefer, or write your own.
> the latter is always emotional. I find it more productive to pursue
> rational solutions.
Yet your arguments about what senteces are seem based entirely on your
emotion, obsession even.
Robert Wagner
>So you are upset because CoBOL isn't English enough for you in it's definitions
>of statement and sentence - so you recommend making it more English by only
>using a period to end a paragraph. All paragraphs are one sentence long.
>Just like English...
Well, just like spoken and poetic English. COBOL isn't Literature. It's written
by code monkeys trying to get the job done with below-average literacy.
It would be refreshing to see COBOL written in blank verse. I've tried without
success.
>Anyway, I don't use NEXT SENTENCE, and I do use END IF. Given that, what
>advantage would my programs gain if they didn't have periods?
Huge advantage. Suppose you wrote
move a to b.
move c to d.
Then you decided to do it only under certain conditions. The code becomes
if (condition)
move a to b
move c to d
end-if
You must tediously delete the periods on every line. I would turn the question
around to ask what utilityt these periods provide. The answer is none. If
periods are superfluous, why write them in the first place?
Robert
Robert Wagner
>> Punctuation such as the period are words. Technically, they are called
>> logographs, meaning 'a symbol representing a word'. An easy example is '=',
>> which is synonymous with 'equal to'.
>
>Punctuation is _not_ 'a symbol representing a word'. An '=' symbol is
>_not_ punctuation. The two groups of symbols are quite distinct
>(though the same grphic may be used in both groups differently). You
>are confused because each punctuation symbol has a name (or several),
>it doesn't mean that it is a symbol for that word.
You are simply wrong. Every punctuation symbol represents a word. It may not be
enunciated in the spoken language, but it is still a word.
>> Because syntax deals with sentences, the logic about what terminates
>> a sentence should be at the syntax level.
>
>I thought that you said you were going to "put aside my comparison of
>COBOL grammar to English grammar".
I thought I did. The message was about system hierarchies, independent of
language.
>Natural languages are primarily spoken. Sentences are terminated by
>vocal signals: pauses or changes of inflection and intonation. When
>the language is written down it uses symbols to represent the
>vocalisation. In English (and several others) these symbols include
>',;:." which represent different lengths of pausing, and "()-?!" which
>also indicate changes in inflection and emphasis.
There are no pauses or questions in COBOL. We have only imperative sentences.
Granted, COBOL is written, but the 2002 standard discourages the use of periods.
I do as well. They don't contain any information. They're superfluous.
>Cobol and other computer languages are not spoken. They do not use
>the punctuation symbols to indicate the same things. Your attempt at
>imposing rules intended to assist written forms of natural language
>rules makes no sense at all. While there may be some superficial
>similarities to written natural languages this does not mean that
>Cobol should use inappropriate rules.
How are the rules inappropriate? I don't find them so. It seems to me that if
COBOL used English grammer and word meanings correctly, its reputation as the
most readable language would be enhanced.
Aren't we in this forum because we love COBOL's readability?
Robert
William M. Klein
Yet another statement that I don't know where you got it. See below:
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e5587c9...@news.optonline.net...
> rip...@Azonic.co.nz (Richard) wrote:
>
<snip>
>
> Granted, COBOL is written, but the 2002 standard discourages the use of
periods.
> I do as well. They don't contain any information. They're superfluous.
>
There is NOTHING in the 2002 standard that in ANY WAY discourages the use of
periods - and as many periods as you might want within a single procedure.
They *do* impact "flow of control" when used in the same procedure as a NEST
SENTENCE - and it is true that "Next Sentence" is in the "archaic" (not
OBSOLETE) category. However, there isn't even a "hint" of discouraging
periods themselves.
FYI - even in a 2002 conforming source program that never uses "Next
Sentence" the use of periods is still critical to the compiler.
For example, assuming that you did NOT use any periods within the procedure
division. Please explain how you (or a 2002 conforming compiler) could
handle the following "snippet" of source code:
Move "ABC" to XYZ ABC Display "Is ABC a procedure-name or a data-name"
Remember that the '85 Standard A-margin/B-margin distinction has been
removed. Therefore, the *only* way that you can tell if a "user-word" is a
data-name or a procedure name (in code like this) is by whether it is or is
not preceded by a period.
I am *not* saying that you code this way - but it does explain why the 2002
does NOT "discourage" the use of periods.
Richard Plinston
>>Punctuation is _not_ 'a symbol representing a word'.
> You are simply wrong. Every punctuation symbol represents a word. It may
> not be enunciated in the spoken language, but it is still a word.
What crap. If it is not enunciated in a spoken language it is not a word.
"punctuation: system of marks indicating pauses or logical and grammatical
relationships in written language."
You are confused because each symbol has a name, which is quite different
from 'representing a word'.
> I thought I did. The message was about system hierarchies, independent of
> language.
But you are still trying to relate two completely different systems. Just
because human speech is a language and Cobol is a 'language' doesn't mean
that you can apply rules or hierarchies from one to the other.
> There are no pauses or questions in COBOL. We have only imperative
> sentences.
Exactly, which is why trying to relate english rules of punctuation (or
what you term system hierarchies) to Cobol is meaningless babble.
> Granted, COBOL is written, but the 2002 standard discourages the use of
> periods. I do as well. They don't contain any information. They're
> superfluous.
Why didn't you just say how you feel about full stops instead of ranting on
about irrelevancies. Of course, you may have felt that it made your
arguments seem quasi-intellectual, but in the end it just boils done to you
think that 'full stops are silly'.
In fact full-stops are not superfluous. They are still required at the end
of every paragraph to eliminate ambiguity.
> How are the rules inappropriate? I don't find them so. It seems to me that
> if COBOL used English grammer and word meanings correctly, its reputation
> as the most readable language would be enhanced.
If you don't like the way Cobol is then either rewrite the standard and
submit it to the committee for consideration or wander off and write a
different language that you feel is better.
You also take an extremely insular view. Many programmers don't have
English as their first, or indeed as any, language. Cobol has a set of
rules and usage that is appropriate and is well defined. Natural languages
have arbitrary, ill-defined and contradictory rules and exceptions. Even
when rules are followed it is still possible to result in ambiguity.
Using 'English grammer[sic] and word meanings' would degrade Cobol
enormously and would result in prolonged arguments that could never be
resolved. Well, just like this one actually.
In any case you would probably want it the be 'American grammar and word
meanings', which is quite a different matter again.
On the one hand you claim that making it more 'English like' would make it
more readable, yet your actual code is _less_ like English. Where is all
the capitalisation of proper names, not even the start of a paragraph is
capitalised? Where are all the commas to separate the phrases? Why haven't
you used noise-words such as 'then' to make it more English like?
The answer of course is that your argument has nothing to do with being
'English like' or using 'English grammar and word meanings' at all.
It is a simple tirade against the use of full stops dressed up in an
attempt to look quasi-intellectual.
> Aren't we in this forum because we love COBOL's readability?
Not specifically, no. While that is an attribute of Cobol, it is, as with
any other stylistic aspect, a matter of recognition.
What is found by any individual to be 'readable' is what one is used to.
If one is used to all uppercase and full stops wherever possible then that
is what one finds to be the most readable. If one mostly sees mixed case
and minimum full stops then that is found to be most readable.
You appear to use minimum full stops and all lower case and thus find that
most readable. But you seem to feel that your opinions are some sort of
absolute rather than a matter of training and recognition.
Robert Wagner
>Robert Wagner wrote:
>Cobol has a set of
>rules and usage that is appropriate and is well defined. Natural languages
>have arbitrary, ill-defined and contradictory rules and exceptions. Even
>when rules are followed it is still possible to result in ambiguity.
The desire to remove ambiguity from programming languages gave us C's == to
represent equal comparison. Designers didn't want to use = because it means
assignment. As a result, a C programmer who writes 'if (a = b) ..;' gets b
copied into a then the result tested for zero. This is a common error, committed
even by seasoned programmers. The invention of '==' INCREASED misunderstanding
rather than decreasing it, as intended.
We successfully deal with ambiguity in written and spoken language all the time.
In COBOL, we read the = in 'if a = b' as a relational operator, while
recognizing the = in 'compute a = b' as an assignment operator. The
disambiguation is not hard to understand.
>On the one hand you claim that making it more 'English like' would make it
>more readable, yet your actual code is _less_ like English. Where is all
>the capitalisation of proper names, not even the start of a paragraph is
>capitalised? Where are all the commas to separate the phrases? Why haven't
>you used noise-words such as 'then' to make it more English like?
They are not phrases, they are sentences. In English, we need initial caps,
terminators, separators and joining adverbs because we do not write each
sentence on a separate line. In programming, line breaks provide sufficient
delineation of sentences.
Robert
Robert Wagner
>Robert,
> Yet another statement that I don't know where you got it. See below:
>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e5587c9...@news.optonline.net...
>> rip...@Azonic.co.nz (Richard) wrote:
>>
> <snip>
>>
>> Granted, COBOL is written, but the 2002 standard discourages the use of
>periods.
>> I do as well. They don't contain any information. They're superfluous.
>
>There is NOTHING in the 2002 standard that in ANY WAY discourages the use of
>periods - and as many periods as you might want within a single procedure.
Intra-paragraph periods are discouraged by:
..Designating NEXT SENTENCE as archaic
..Providing explicit terminators for IF, SEARCH and EVALUATE
If one uses explicit terminators and doesn't use NEXT SENTENCE then periods
serve no purpose (except paragraph termination).
Robert
Michael Mattias
> "Howard Brazee" <how...@brazee.net> wrote:
> COBOL [is] written by code monkeys trying to get the job done with
below-average literacy.
I beg your pardon, sir?
There are numerous COBOL programmers who create prose for publication; prose
not limited to technical subjects.
Michael Mattias
One of many published 'below-average literacy code monkeys'
Racine WI
mmat...@talsystems.com.
Howard Brazee
On 20-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> Granted, COBOL is written, but the 2002 standard discourages the use of
> periods.
Cite?
Howard Brazee
On 20-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> You are simply wrong. Every punctuation symbol represents a word. It may not
> be enunciated in the spoken language, but it is still a word.
Cite?
Howard Brazee
On 20-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> Granted, COBOL is written, but the 2002 standard discourages the use of
> periods. I do as well. They don't contain any information. They're
> superfluous.
They give some information, but even if not - a little redundancy can make for a
more readable language. A little redundancy can make it more like a spoken
language.
What is the big attraction to eliminating periods? Did it make it more English
like? Did it make it easier to get a clean compile (without the compiler
noticing that you have an IF without an END IF)?
> How are the rules inappropriate? I don't find them so. It seems to me that if
> COBOL used English grammar and word meanings correctly, its reputation as the
> most readable language would be enhanced.
So obviously you wish to emulate English more closely. Fortunately, CoBOL
allows you to put more than one period in a paragraph, avoiding run-on
sentences. It allows you to avoid un-English constructs such as END IF. You
can easily make your code more English-like.
> Aren't we in this forum because we love COBOL's readability?
It's can be more understandable than English.
Howard Brazee
On 21-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> They are not phrases, they are sentences. In English, we need initial caps,
> terminators, separators and joining adverbs because we do not write each
> sentence on a separate line. In programming, line breaks provide sufficient
> delineation of sentences.
In CoBOL, line breaks do no such thing.
Howard Brazee
On 20-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> >So you are upset because CoBOL isn't English enough for you in it's
> >definitions
> >of statement and sentence - so you recommend making it more English by only
> >using a period to end a paragraph. All paragraphs are one sentence long.
> >Just like English...
>
> Well, just like spoken and poetic English. COBOL isn't Literature. It's
> written
> by code monkeys trying to get the job done with below-average literacy.
Then with your spoken and poetic CoBOL, leave out the periods. (I thought you
said periods were words)
If you're going to demand CoBOL be English like, at least compare written CoBOL
with written English.
> It would be refreshing to see COBOL written in blank verse. I've tried without
> success.
It's not hard at all. But maintenance is a bitch. Blank verse is designed to
add ambiguity and isn't designed to be obvious. Good programming goes counter
to these goals.
Howard Brazee
On 21-Feb-2003, "Michael Mattias" <michael...@gte.net> wrote:
> > COBOL [is] written by code monkeys trying to get the job done with
> below-average literacy.
>
> I beg your pardon, sir?
I think he vastly over-rates "average literacy".
Of course, when he starts an argument on this forum and EVERY SINGLE response
disagrees with him completely (without anybody arguing with any of these
responses) - then we all must be idiots. I know several people who write books
that the idiot publishers won't publish and the idiot readers won't buy.
Us code-monkeys have to be below-average literacy, because if there was one with
half an ounce of sense, one of these posts would be supporting his statements -
or at least arguing with someone who disagreed with him.
Howard Brazee
On 20-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> >Anyway, I don't use NEXT SENTENCE, and I do use END IF. Given that, what
> >advantage would my programs gain if they didn't have periods?
>
> Huge advantage. Suppose you wrote
> move a to b.
> move c to d.
> Then you decided to do it only under certain conditions. The code becomes
> if (condition)
> move a to b
> move c to d
> end-if
>
> You must tediously delete the periods on every line. I would turn the question
> around to ask what utilityt these periods provide. The answer is none. If
> periods are superfluous, why write them in the first place?
I could have cut and pasted using a windows utility without including the
period. But any rate, it is not tedious nor onerous to remove the periods.
I write them for clarity.
Howard Brazee
On 21-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
> >There is NOTHING in the 2002 standard that in ANY WAY discourages the use of
> >periods - and as many periods as you might want within a single procedure.
>
> Intra-paragraph periods are discouraged by:
>
> ..Designating NEXT SENTENCE as archaic
> ..Providing explicit terminators for IF, SEARCH and EVALUATE
Please go on. How does this discourage the use of periods?
> If one uses explicit terminators and doesn't use NEXT SENTENCE then periods
> serve no purpose (except paragraph termination).
That's one purpose. Another purpose is to make the language more English like,
which purpose you professed to think is valid.
A third purpose is that it makes it easier for compilers to check for END IF
mismatches.
Does the CoBOL verb COMPUTE discourage the use of the verb ADD ?
William M. Klein
way discouraged. The Standard *does* have a way of "discouraging" use - and
that is putting an item in either the archaic or obsolete category - and
periods in the middle of paragraphs are NOT in that category.
According to your "theory", the Standard is "discouraging" the use of Add,
Subtract, Multiply, and Divide - because you COULD use COMPUTE to do the
same thing. ADD is even *more* discouraged because you could use the SUM
intrinsic function.
You are simply WRONG in stating that periods in the middle of paragraphs are
being discouraged. They are *not* required - but neither are comments,
using meaningful user-defined words, or any other "stylistic" feature of the
language.
Please, PLEASE, do not make erroneous statements about the COBOL Standards -
which you have (so far) shown little knowledge much less understanding of.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e56179d...@news.optonline.net...
Chuck Stevens
> rip...@Azonic.co.nz (Richard) wrote:
> Granted, COBOL is written, but the 2002 standard discourages the use of
periods.
I acknowledge that the 2002 standard *allows* programs to be written with
very few periods, and I also acknowledge that it offers a repertoire of
mechanisms that allow individual programmers as a matter of style largely to
avoid them, but so far as I know the use of periods is not in any way
explicitly or implicitly *discouraged* by the standard, any more than it
discourages the use of hand-coded editing routines in favor of VALIDATE or
GO TO ... DEPENDING in favor of EVALUATE.
The convention for "discouraging" the use of a widely-used feature of the
language starts with placing it in the archaic category (like NEXT SENTENCE,
MOVE HIGH-VALUES TO <numeric item>, continuation of COBOL words across line
boundaries, ON OVERFLOW instead of ON EXCEPTION on a CALL statement, and the
use of <identifier> in a COPY ... REPLACING in the '02 standard). The use
of periods in the Procedure Division for any purpose other than terminating
a paragraph is simply not in that list.
> How are the rules inappropriate? I don't find them so. It seems to me that
if
> COBOL used English grammer and word meanings correctly, its reputation as
the
> most readable language would be enhanced.
The rules of COBOL are appropriate to COBOL precisely because they DEFINE
COBOL. COBOL is not English, Tagalog, Sanskrit, or Chinese, it is COBOL,
and it has its own grammar (and its own terms in describing that grammar).
The use of the term "aspect" in a Russian grammar is unlikely to bear much
relevance in a grammar of Mandarin. The use of the word "article" in
English grammars has no meaning whatever in either Russian or Chinese
grammars. Guess what: Articles are IMPORTANT in English. Verbal aspect is
IMPORTANT in Russian. Neither has any relevance to COBOL. If COBOL used
ALL the rules of English grammar, it would cease to be COBOL.
And COBOL is not only not English, it is DECREASINGLY targeted to the
monoglot in English. The current standard is FIRST released as an
INTERNATIONAL standard, and includes significant support for
internationalization mechanisms. In what way would slavish adherence to
the conventions of written English in the composition of COBOL program
enhance its legibility to the monoglot in Tlingkit? Yes, this may be an
extreme example -- but see below for some that aren't!
> Aren't we in this forum because we love COBOL's readability?
Maybe you are. As for me, that doesn't rank all that high up on my reasons
for participating in this forum.
And I'd have to say that COBOL's inability to support, say, Venezuelan
currency-representation conventions in the PICTURE clause (to say nothing of
non-English-character-set identifiers) from the inception of the language up
to the 2002 standard was a *limitation* in its usefulness to those outside
English-speaking countries. Readability to the person fluent in written
English is *lower* on the priority scale for COBOL than ever it was before,
I would say.
I had a recent discussion with a member of another standards development
group on the subject of coding identifiers in other than "regular" character
sets. There is no argument whatever as to whether they should ultimately be
able to encode them in Cyrillic, Greek, any of the Japanese writing
schemata, or Chinese ideographs; there is, however, some resistance to
allowing such identifiers to be encoded in representations of, say,
cuneiform or Egyptian hieroglyphics. English readability?
-Chuck Stevens
Richard
> >There is NOTHING in the 2002 standard that in ANY WAY discourages the use of
> >periods - and as many periods as you might want within a single procedure.
>
> Intra-paragraph periods are discouraged by:
>
> ..Designating NEXT SENTENCE as archaic
> ..Providing explicit terminators for IF, SEARCH and EVALUATE
>
> If one uses explicit terminators and doesn't use NEXT SENTENCE then periods
> serve no purpose (except paragraph termination).
There is _NOTHING_ in these that discourages the use of full stops at
all.
It is entirely neutral on the issue.
The scope terminators were in the '85 standard, so no change there.
NEXT SENTENCE was disallowed in an IF .. END-IF in '85.
You are obsessive about trying to stop people using full stops and are
just inventing all sorts of unsupportable nonsense arguments.
No one is going to change their style because of any of these silly
'reasons', just get over it.
Richard
> The desire to remove ambiguity from programming languages gave us
Do you think that ambiguity should not be removed ?
> C's == to
> represent equal comparison. Designers didn't want to use = because it means
> assignment.
Most computer languages differenciate between assignment and equality
is some way. Pascal uses ':=' for assignment, other dissallow
contexts where these could be confused.
> As a result, a C programmer who writes 'if (a = b) ..;' gets b
> copied into a then the result tested for zero.
This is _not_ a result of differentiating between assignment and
equality. It is the result of C having assignment as an operator and
not a statement and of allowing expressions in conditionals. These
features of C give it a great deal of power and flexability.
> This is a common error, committed
> even by seasoned programmers.
No. Seasoned programmers are the ones that have learned to use tools
which eliminate this as a problem.
> The invention of '==' INCREASED misunderstanding
> rather than decreasing it, as intended.
No. Wrong. Either assignment are to be the same thing as '=' which
means there is entire ambiguity and no understanding, or they are to
be different things, such as '=' and '==' or ':=' and '=' or some
other. Obviously if they are different things then this is better
than 'no understanding'.
Oh and by the way, in "if ( a = b )" it tests for true if the result
is _not_ zero. You may find this ambiguous, I don't.
> We successfully deal with ambiguity in written and spoken language all the time.
Complete crap. You may feel that you deal with ambiguity
'successfully', but you probably just take it as support for your
predefined conclusions regardless of what was intended.
In many cases ambiguity is simply not noticed by the receiver, it is
only if the sender notices an inappropriate result that the ambiguity
is noticed and the message modified.
> In COBOL, we read the = in 'if a = b' as a relational operator, while
> recognizing the = in 'compute a = b' as an assignment operator. The
> disambiguation is not hard to understand.
That is because you cannot put a COMPUTE into a condition. Cobol
loses flexibility compared to other languages.
This is a result of the 'desire to remove ambiguity'.
But C's problems have nothing to do with the need to remove ambiguity
in Cobol. A full stop is required prior to a paragraph label in order
to remove ambiguity.
> They are not phrases, they are sentences. In English, we need initial caps,
> terminators, separators and joining adverbs because we do not write each
> sentence on a separate line.
Yet more complete crap.
Capitals on initial words in a sentence, on proper names, acronyms and
others are a style designed to resolve ambiguity. Punctuation
(terminators and separators) indicate pauses and intonation, and this
also resolves ambiguity.
Writing English on a separate line per sentence would not be a
substitute for this style.
We don't "need caps, etc' because we don't write each sentance on a
separate line". If we did use a separate line we would _still_ need
capitals and punctuation. If fact we do in poetry and in lists.
You wanted to make Cobol written in a more englishlike way to be more
readable, yet you reject the mechanisms that would do this, with
completely spurious arguments.
> In programming, line breaks provide sufficient
> delineation of sentences.
Putting in line breaks for each statement, phrase, clause, sentence,
or whatever, is a _style_ not a requirement of the language. Many
lanuages, including Cobol can be packed, even splitting words at the
end of a line.
Now it may be that you would prefer to use a language that enforces
line breaks and resolves ambiguity some diffeent way. Well please do
so, either by moving on or by writing your own.
Chuck Stevens
news:217e491a.03022...@posting.google.com...
> rob...@wagner.net (Robert Wagner) wrote
<<Many lanuages, including Cobol can be packed, even splitting words at the
end of a line.>>
Speaking of discouraged practices, the splitting of words at the end of a
fixed-form reference format source image is actively discouraged by the
current COBOL standard as an archaism. The splitting of words across source
images is *not* permitted in free-form reference format. See ISO/IEC
1989:2002 Page 8332, G.1, Archaic language elements, item 1, Continuation of
COBOL words
-Chuck Stevens
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> The desire to remove ambiguity from programming languages gave us
>
>Do you think that ambiguity should not be removed ?
Misunderstanding should be removed. Ambiguity in the lexicon can be resolved by
context in the syntax.
>Most computer languages differenciate between assignment and equality
>is some way. Pascal uses ':=' for assignment, other dissallow
>contexts where these could be confused.
Languages such as COBOL.
>> As a result, a C programmer who writes 'if (a = b) ..;' gets b
>> copied into a then the result tested for zero.
>
>This is _not_ a result of differentiating between assignment and
>equality. It is the result of C having assignment as an operator and
>not a statement and of allowing expressions in conditionals. These
>features of C give it a great deal of power and flexability.
The 'power' to shoot yourself in the foot. How often does a programmer need to
do assignment in the middle of a conditional?
>> This is a common error, committed
>> even by seasoned programmers.
>
>No. Seasoned programmers are the ones that have learned to use tools
>which eliminate this as a problem.
You are referring to LINT. The existence of such safety nets demonstrates how
error-prone the language is.
>Oh and by the way, in "if ( a = b )" it tests for true if the result
>is _not_ zero. You may find this ambiguous, I don't.
I said, "the result is tested for zero." How else would it determine the result
is_not_zero? Wait .. I have it .. use a ternary operator: if ((a = b) ? false :
true) .. ; <pausing to admire the elegence of his code>
>In many cases ambiguity is simply not noticed by the receiver, it is
>only if the sender notices an inappropriate result that the ambiguity
>is noticed and the message modified.
That's called debugging.
>> In COBOL, we read the = in 'if a = b' as a relational operator, while
>> recognizing the = in 'compute a = b' as an assignment operator. The
>> disambiguation is not hard to understand.
>
>That is because you cannot put a COMPUTE into a condition. Cobol
>loses flexibility compared to other languages.
You should lobby for that feature, and even more strongly for function calls
which look like references to subscripted variables. The compiler sees 'COMPUTE
a = b(c);' cannot find an array named b, cannot find a function prototype,
therefore <fanfare> b must be a function (rather than a misspelling). It's
obvious.
>But C's problems have nothing to do with the need to remove ambiguity
>in Cobol. A full stop is required prior to a paragraph label in order
>to remove ambiguity.
My COBOL pre-processor recognized paragraph names without a preceeding period.
When it saw a one-word sentence not defined as data, that's a paragraph name.
Terminate the previous sentence with a period to placate the COBOL compiler. For
example, when presented with 'move a b c. move d e', it looked to see whether
'c' was defined as data. If not, it output:
move a to b.
c.
move d to e
I acknowledge that's as sloppy as the function call example above, which is why
I stopped using the preprocessor.
>Now it may be that you would prefer to use a language that enforces
>line breaks and resolves ambiguity some diffeent way. Well please do
>so, either by moving on or by writing your own.
I did write my own preprocessor. For instance, it, along with APS and others,
honored indentation as significant. When people read source code, they see
subordination based on indentation, not explicit block terminators or level
numbers. It would be nice if compilers at least gave a warning when seeing an
out-dent without a preceeding terminator.
Robert
Robert Wagner
..The beloved '85 COBOL standard, section 5.1.7:
"The separator period, when used in these formats, has the status of a required
word."
They could have said 'The separator period is required.' Instead they went out
of their way to promote it to a word.
..Common usage, as seen in 'dot-com' and 'dot-NET'.
..My Demo program parses COBOL source into a list of "words". It does not have
one type structure for lexemes and a different structure for punctuation.
Robert
Robert Wagner
>What is the big attraction to eliminating periods?
Moving sections of code in and out of if statements is simplified.
> Did it make it easier to get a clean compile (without the compiler
>noticing that you have an IF without an END IF)?
That's a problem. The period terminating a paragraph also terminates an
incorrect IF statement. I wish there was a compiler option to require explicit
terminators.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e5587c9...@news.optonline.net...
>> rip...@Azonic.co.nz (Richard) wrote:
>
>> Granted, COBOL is written, but the 2002 standard discourages the use of
>periods.
>
>I acknowledge that the 2002 standard *allows* programs to be written with
>very few periods, and I also acknowledge that it offers a repertoire of
>mechanisms that allow individual programmers as a matter of style largely to
>avoid them, but so far as I know the use of periods is not in any way
>explicitly or implicitly *discouraged* by the standard, any more than it
>discourages the use of hand-coded editing routines in favor of VALIDATE or
>GO TO ... DEPENDING in favor of EVALUATE.
The 2002 standard discourages periods by providing explicit terminators and
discouraging NEXT SENTENCE, leaving the period with no role except paragraph
termination. Because its old role was preserved, it has become a trouble-maker
which must be avoided inside IF and every other explicitly terminated statement.
>The convention for "discouraging" the use of a widely-used feature of the
>language starts with placing it in the archaic category (like NEXT SENTENCE,
>MOVE HIGH-VALUES TO <numeric item>, continuation of COBOL words across line
>boundaries, ON OVERFLOW instead of ON EXCEPTION on a CALL statement, and the
>use of <identifier> in a COPY ... REPLACING in the '02 standard). The use
>of periods in the Procedure Division for any purpose other than terminating
>a paragraph is simply not in that list.
I speculate periods were not designated archaic for political reasons. The COBOL
community includes many, perhaps mostly, mainframers who want to retain old
practices. Some of them refer to '85 COBOL as "new COBOL" .. 18 years later.
They are not the constituancy who will be first in line to try OO COBOL; they
will be near the end of the line.
Because it retained backward compatibility, C++ experienced the same growing
pains. I've been in many shops who SAY they program in C++. Examining their code
reveals that it is pure ANSI C. They are compiling it with a compiler designated
C++ to give the appearance of using a modern language, to benefit from a modern
editor and debugger, and to avoid the embarrassment of admitting the truth. They
are packaging old wine in new bottles.
I'd wager that, if one examined the code of people who support periods, (s)he
would also find paragraph names prefixed with numbers, large monolithic programs
containing GO TOs, and a generally poor sense of structural design. COBOL bears
that legacy. It will not be eliminated by adding new syntax. Traditionalists
will simply avoid using the new features. It will be eliminated only by a major
paradigm shift, such as OO. For this reason, I applaud the addition of OO
features to COBOL.
<snip>
>I had a recent discussion with a member of another standards development
>group on the subject of coding identifiers in other than "regular" character
>sets. There is no argument whatever as to whether they should ultimately be
>able to encode them in Cyrillic, Greek, any of the Japanese writing
>schemata, or Chinese ideographs; there is, however, some resistance to
>allowing such identifiers to be encoded in representations of, say,
>cuneiform or Egyptian hieroglyphics. English readability?
OO turns a programming language into a mega-language. Don't like the English
word ADD? Create a method named the Russian equivalent. Don't like English names
for data structures? Create a class named the Kanji logogram for Table. Don't
like the way UNSTRING works? Replace it with your own PARSE. Please make it
virtual so I can overload it with my PARSE, because mine is so much better.
Every programmer has been promoted to language designer.
Is this good or bad?
Robert
Robert Wagner
>
>On 21-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
>
>> If one uses explicit terminators and doesn't use NEXT SENTENCE then periods
>> serve no purpose (except paragraph termination).
>
>A third purpose is that it makes it easier for compilers to check for END IF
>mismatches.
Please give an example.
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>There is _NOTHING_ in these that discourages the use of full stops at
>all.
>
>It is entirely neutral on the issue.
>
>You are obsessive about trying to stop people using full stops and are
>just inventing all sorts of unsupportable nonsense arguments.
>
>No one is going to change their style because of any of these silly
>'reasons', just get over it.
The volume of responses indicates a significant portion of the COBOL community
regards periods as a symbol representing other practices to which they are
attached and are afraid of losing. Like falling into paragraphs, PERFORM ..
THRU, the superfluous 77 level and the sacred GO TO.
You are defending a Culture, not a punctuation mark.
Robert
Donald Tees
>
> I speculate periods were not designated archaic for political reasons. The COBOL
> community includes many, perhaps mostly, mainframers who want to retain old
> practices. Some of them refer to '85 COBOL as "new COBOL" .. 18 years later.
> They are not the constituancy who will be first in line to try OO COBOL; they
> will be near the end of the line.
>
> Because it retained backward compatibility, C++ experienced the same growing
What absolute drivel.
The period is an excellent terminator, and by eliminating it in favour
of all sorts of scope delimiters, all you are doing is encouraginging
huge monolothic sentences. The natural "chunk" of code in Cobol is the
paragraph, comprised of sentences.
Insisting that each paragraph be a single sentence, simply does away
with the entire purpose of the paragraph. When IF statements get so
complex that you cannot tell what they are doing, it is a very simple
matter to break it down into groups of statements by putting the groups
into multiple paragraphs, and giving them names. That way, things are
readable.
Instead, you want to make the sentence huge, clutter it up with dozens
of "end" statements of various forms, and leave all the stateements
within it unlabeled so that one has to spebd an hour figuring out what
each group of statements do. When the sheer compexity of the resulting
sentence, makes the punctuation (rather than the grammar) so critical to
the functioning of the code that you need twenty type of periods to sort
it all out, then you want to make the simple mechanism obsolete so you
cannot paint yourself into corner with the complexities you introduce.
As to your inference that everyone not agreeing to your convoluted style
is incompetent, mired in twenty year old practices, and incapable of
understanding your way of doing things, that is just pure ego. I have
not used a numbered paragraph in my thirty-five years of Cobol, and the
last time I coded a goto (about three in thirty-five years), it was
because the code was a deliberate infinite loop, a very sound reason for
a goto, in my opinion. I also have been writing OOP now for better than
three or four years.
Donald
Richard Plinston
>>No one is going to change their style because of any of these silly
>>'reasons', just get over it.
>
> The volume of responses indicates a significant portion of the COBOL
> community regards periods as a symbol representing other practices to
> which they are attached and are afraid of losing.
Some may use full stops, some use as few as possible, others use whatever
they feel enhances the readability of their code _to_them_ and theirs. This
is their personal choice.
Full stops will never be entirely eliminated, as you feel they should, they
form a necessary function.
As it happens, I use as few as possible wherever practical, but I would not
try to _impose_ my usage on others.
> You are defending a Culture, not a punctuation mark.
I am not defending either a culture or a punctuation mark, I am defending
rational and cogent arguments from your onslaught of nonsense and made up
silliness.
> Like falling into
> paragraphs, PERFORM .. THRU, the superfluous 77 level and the sacred GO
> TO.
These have absolutely nothing to do with whether one uses full stops or not
and is just another crap argument.
Robert Wagner
>The period is an excellent terminator, and by eliminating it in favour
>of all sorts of scope delimiters, all you are doing is encouraginging
>huge monolothic sentences.
Without explicit delimiters, one can write huge monolithic sentences almost as
easily. I assume you are referring to long nested IFs.
>The natural "chunk" of code in Cobol is the
>paragraph, comprised of sentences.
I think the natural chunk is a 'block'. Other languages make this clear by using
begin and end marks e.g. curly braces in C.
You don't use periods inside IF and EVALUATE statements. You're not allowed to.
Why are they suddenly important when outside an IF? It's asymmetrical. You would
have us do condition testing in one paragraph, or a paragraph per level if
nested, and all imperative operations in paragraphs of their own. For example:
if (condition)
move a to b *> build output record
move c to d
perform until (condition)
move e to f *> put price history into record
end-perform
end-if
== versus --
if (condition)
perform build-output-record.
-- 100 lines of unrelated code --
build-output-record.
move a to b.
move c to d.
perform put-price-history-into-record until (condition).
put-price-history-into-record.
move e to f.
Now a maintenance change requires changing "move c to d." to a conditional. The
code becomes:
build-output-record.
move a to b.
perform get-value-of-d.
perform put-price-history-into-record until (condition).
put-price-history-into-record.
move e to f.
get-value-of-d.
if (condition)
perform put-c-into-d
else
perform put-new-c-into-d
end-if.
put-c-into-d.
move c to d.
put-new-c-into-d.
move new-c to d.
After a few more change iterations, your code has turned into spaghetti.
Now a production support person is trying to figure out how garbage got into c.
(S)he must trace backward through three levels of non-adjacent code to
understand the conditions under which things are moved to c .. constructing the
first example mentally or in pseudo-code.
>Insisting that each paragraph be a single sentence, simply does away
>with the entire purpose of the paragraph.
This is a circular argument i.e. one that uses its conclusion as one of its
premises. You define 'sentence' as 'text terminated by a period', then conclude
all my paragraphs contain one sentence. The dictionary defines 'sentence' as 'a
statement containing one noun and one predicate.'
> When IF statements get so
>complex that you cannot tell what they are doing, it is a very simple
>matter to break it down into groups of statements by putting the groups
>into multiple paragraphs, and giving them names. That way, things are
>readable.
Now you've (unwittingly) put your finger on the real issue here -- fear of being
overwhelmed by complexity. That threshold is a function of the program's logic
AND your ability to comprehend. The program's logic isn't going to change, no
matter how it written. It is going to make the same decisions ONE WAY OR
ANOTHER. They can be made in one complete statement or they can be disbursed
into simpler but incomplete statements. The only variable is you.
In the paper which started this <cough> 'discussion', I tried to give readers
tools for dealing with complex logic. Tools more powerful than 'common sense'
and natural language skills, which have a relatively low capacity for
complexity. I compared it to the difference between solving mathematical 'word
problems' with sixth-grade skills vs. solving them with algebra. Sadly, most
programmers are running on the former.
>Instead, you want to make the sentence huge, clutter it up with dozens
>of "end" statements of various forms, and leave all the statements
>within it unlabeled so that one has to spend an hour figuring out what
>each group of statements do.
Comments are for explaining what statements do, not paragraph names. If it takes
an hour for you to figure out what a group of statements does, add a comment so
the next maintenance programmer won't have to do it again. I sometimes comment
code I wrote a few months ago.
>As to your inference that everyone not agreeing to your convoluted style
>is incompetent, mired in twenty year old practices, and incapable of
>understanding your way of doing things, that is just pure ego. I have
>not used a numbered paragraph in my thirty-five years of Cobol, and the
>last time I coded a goto (about three in thirty-five years), it was
>because the code was a deliberate infinite loop, a very sound reason for
>a goto, in my opinion. I also have been writing OOP now for better than
>three or four years.
A pat on the back to you. You're 90% on the way to Real Programming. We just
need to work on those periods and logic anxiety.
Robert
Robert Wagner
>Robert Wagner wrote:
>> The volume of responses indicates a significant portion of the COBOL
>> community regards periods as a symbol representing other practices to
>> which they are attached and are afraid of losing.
>
>Some may use full stops, some use as few as possible, others use whatever
>they feel enhances the readability of their code _to_them_ and theirs. This
>is their personal choice.
To most professionals, it's a shop choice. The shop publishes a stylebook
containing do's and don'ts, and uses 'code walkthrus' to ensure compliance.
Some have a full-time staff who do nothing but police coding style.
Most COBOL stylebooks were written in the '70s, or by programmers who stopped
growing in the '70s.
>As it happens, I use as few as possible wherever practical, but I would not
>try to _impose_ my usage on others.
The paper which started this discussion was a tutorial instructing newbies on
Best Practices. My secondary objective was to see it adopted as a stylebook by a
few companies (such as mine), so that 'code Nazis' would not _impose_ '70s style
COBOL on neophytes. They love to _impose_, usually after the code is tested and
ready to go into production.
>
>> You are defending a Culture, not a punctuation mark.
>
>I am not defending either a culture or a punctuation mark, I am defending
>rational and cogent arguments from your onslaught of nonsense and made up
>silliness.
Generally, ad hominem arguments are incorrect, not because they are unmannerly,
but because they are irrelevant. If the person doesn't hold himself to be an
authority then criticism of his character is irrelevant to the points he makes.
You must rebut his points or remain silent.
This case is different because I DO claim to be an authority on Practical Use of
COBOL. My claim is based on forty years of writing a million lines of code and
supervising the write/rewrite of 5-10 million lines.
So feel free to respond emotively. However, because this is a public forum, it
would be instructive to readers if you rebutted SOME of the points I make.
Otherwise, you'll sound like that 'poopie' guy. Readers don't benefit much from
learning I'm a low-IQ a-hole.
Robert
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> The desire to remove ambiguity from programming languages gave us
>
>Do you think that ambiguity should not be removed ?
Misunderstanding should be removed. Ambiguity in the lexicon can be resolved by
context in the syntax.
>Most computer languages differenciate between assignment and equality
>is some way. Pascal uses ':=' for assignment, other dissallow
>contexts where these could be confused.
Languages such as COBOL.
>> As a result, a C programmer who writes 'if (a = b) ..;' gets b
>> copied into a then the result tested for zero.
>
>This is _not_ a result of differentiating between assignment and
>equality. It is the result of C having assignment as an operator and
>not a statement and of allowing expressions in conditionals. These
>features of C give it a great deal of power and flexability.
The 'power' to shoot yourself in the foot. How often does a programmer need to
do assignment in the middle of a conditional?
>> This is a common error, committed
>> even by seasoned programmers.
>
>No. Seasoned programmers are the ones that have learned to use tools
>which eliminate this as a problem.
You are referring to LINT. The existence of such safety nets demonstrates how
error-prone the language is.
>Oh and by the way, in "if ( a = b )" it tests for true if the result
>is _not_ zero. You may find this ambiguous, I don't.
I said, "the result is tested for zero." How else would it determine the result
is_not_zero? Wait .. I have it .. use a ternary operator: if ((a = b) ? false :
true) .. ; <pausing to admire the elegence of his code>
>In many cases ambiguity is simply not noticed by the receiver, it is
>only if the sender notices an inappropriate result that the ambiguity
>is noticed and the message modified.
That's called debugging.
>> In COBOL, we read the = in 'if a = b' as a relational operator, while
>> recognizing the = in 'compute a = b' as an assignment operator. The
>> disambiguation is not hard to understand.
>
>That is because you cannot put a COMPUTE into a condition. Cobol
>loses flexibility compared to other languages.
You should lobby for that feature, and even more strongly for function calls
which look like references to subscripted variables. The compiler sees 'COMPUTE
a = b(c);' cannot find an array named b, cannot find a function prototype,
therefore <fanfare> b must be a function (rather than a misspelling). It's
obvious.
>But C's problems have nothing to do with the need to remove ambiguity
>in Cobol. A full stop is required prior to a paragraph label in order
>to remove ambiguity.
My COBOL pre-processor recognized paragraph names without a preceeding period.
When it saw a one-word sentence not defined as data, that's a paragraph name.
Terminate the previous sentence with a period to placate the COBOL compiler. For
example, when presented with 'move a b c. move d e', it looked to see whether
'c' was defined as data. If not, it output:
move a to b.
c.
move d to e
I acknowledge that's as sloppy as the function call example above, which is why
I stopped using the preprocessor.
>Now it may be that you would prefer to use a language that enforces
>line breaks and resolves ambiguity some diffeent way. Well please do
>so, either by moving on or by writing your own.
I did write my own preprocessor. For instance, it, along with APS and others,
Robert Wagner
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e5587c9...@news.optonline.net...
>> rip...@Azonic.co.nz (Richard) wrote:
>
>> Granted, COBOL is written, but the 2002 standard discourages the use of
>periods.
>
>I acknowledge that the 2002 standard *allows* programs to be written with
>very few periods, and I also acknowledge that it offers a repertoire of
>mechanisms that allow individual programmers as a matter of style largely to
>avoid them, but so far as I know the use of periods is not in any way
>explicitly or implicitly *discouraged* by the standard, any more than it
>discourages the use of hand-coded editing routines in favor of VALIDATE or
>GO TO ... DEPENDING in favor of EVALUATE.
The 2002 standard discourages periods by providing explicit terminators and
discouraging NEXT SENTENCE, leaving the period with no role except paragraph
termination. Because its old role was preserved, it has become a trouble-maker
which must be avoided inside IF and every other explicitly terminated statement.
>The convention for "discouraging" the use of a widely-used feature of the
>language starts with placing it in the archaic category (like NEXT SENTENCE,
>MOVE HIGH-VALUES TO <numeric item>, continuation of COBOL words across line
>boundaries, ON OVERFLOW instead of ON EXCEPTION on a CALL statement, and the
>use of <identifier> in a COPY ... REPLACING in the '02 standard). The use
>of periods in the Procedure Division for any purpose other than terminating
>a paragraph is simply not in that list.
I speculate periods were not designated archaic for political reasons. The COBOL
community includes many, perhaps mostly, mainframers who want to retain old
practices. Some of them refer to '85 COBOL as "new COBOL" .. 18 years later.
They are not the constituancy who will be first in line to try OO COBOL; they
will be near the end of the line.
Because it retained backward compatibility, C++ experienced the same growing
pains. I've been in many shops who SAY they program in C++. Examining their code
reveals that it is pure ANSI C. They are compiling it with a compiler designated
C++ to give the appearance of using a modern language, to benefit from a modern
editor and debugger, and to avoid the embarrassment of admitting the truth. They
are packaging old wine in new bottles.
I'd wager that, if one examined the code of people who support periods, (s)he
would also find paragraph names prefixed with numbers, large monolithic programs
containing GO TOs, and a generally poor sense of structural design. COBOL bears
that legacy. It will not be eliminated by adding new syntax. Traditionalists
will simply avoid using the new features. It will be eliminated only by a major
paradigm shift, such as OO. For this reason, I applaud the addition of OO
features to COBOL.
<snip>
>I had a recent discussion with a member of another standards development
>group on the subject of coding identifiers in other than "regular" character
>sets. There is no argument whatever as to whether they should ultimately be
>able to encode them in Cyrillic, Greek, any of the Japanese writing
>schemata, or Chinese ideographs; there is, however, some resistance to
>allowing such identifiers to be encoded in representations of, say,
>cuneiform or Egyptian hieroglyphics. English readability?
OO turns a programming language into a mega-language. Don't like the English
Robert Wagner
>
>On 21-Feb-2003, rob...@wagner.net (Robert Wagner) wrote:
>
>> If one uses explicit terminators and doesn't use NEXT SENTENCE then periods
>> serve no purpose (except paragraph termination).
>
>A third purpose is that it makes it easier for compilers to check for END IF
>mismatches.
Please give an example.
William M. Klein
You are wrong again. Read what the '85 Standard really says. It says
"has the status of a required word."
which is NOT to say that it is a word - in fact the '85 Standard is quite
clear that it is not.
See page IV-4 which CLEARLY distinguishes COBOL words from separators
(including the separator period) when it says,
"The individual characters of the language are concatenated to form
character-strings and separators. ..."
COBOL words are then listed as part of "character-string".
I really, REALLY wish that you would stop justifying your 'personal views"
my MIS-representing the Standard.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e57eb61....@news.optonline.net...
William M. Klein
> "Chuck Stevens" <charles...@unisys.com> wrote:
>
> >
> >"Robert Wagner" <rob...@wagner.net> wrote in message
> >news:3e5587c9...@news.optonline.net...
> >> rip...@Azonic.co.nz (Richard) wrote:
> >
> >> Granted, COBOL is written, but the 2002 standard discourages the use of
> >periods.
> >
> >I acknowledge that the 2002 standard *allows* programs to be written with
> >very few periods, and I also acknowledge that it offers a repertoire of
> >mechanisms that allow individual programmers as a matter of style largely
to
> >avoid them, but so far as I know the use of periods is not in any way
> >explicitly or implicitly *discouraged* by the standard, any more than it
> >discourages the use of hand-coded editing routines in favor of VALIDATE
or
> >GO TO ... DEPENDING in favor of EVALUATE.
>
> The 2002 standard discourages periods by providing explicit terminators
and
> discouraging NEXT SENTENCE, leaving the period with no role except
paragraph
> termination. Because its old role was preserved, it has become a
trouble-maker
> which must be avoided inside IF and every other explicitly terminated
statement.
You are wrong. You have been told you are wrong. You continue to
mis-represent what the Standard does.
Do you think that you will have anyone believing you when you state
something correctly - if you keep arguing for things that have already been
shown to be wrong.
The 2002 Standard has explicit ways of "discouraging" features - and periods
just are NOT in this category. It doesn't matter what you WANT, you can't
claim it for the Standard.
You *might* want to submit a paper asking for "middle of the paragraph"
periods to be put in the archaic category in the NEXT COBOL Standard. Maybe
if you need that and heard back from the real standards committees you would
stop making a complete fool of yourself.
Richard
> Misunderstanding should be removed. Ambiguity in the lexicon can be resolved by
> context in the syntax.
That is correct. In the case of Cobol labels the ambiguity is
resolved by have a full stop at the end of each paragraph.
> The 'power' to shoot yourself in the foot. How often does a programmer need to
> do assignment in the middle of a conditional?
If you don't like C then please do not use it. C programmers do, in
fact, like the idiom of being able to do assignment in conditionals.
In many cases this saves code repetition.
> You are referring to LINT. The existence of such safety nets demonstrates how
> error-prone the language is.
lint is one tool, in fact lint like facilities are in the compilers
now, just as they are in other languages.
For example some Cobol compilers will report unreachable code. Does
this indicate how error-prone Cobol is ?
> You should lobby for that feature,
No, I shouldn't. Cobol has features that I like and C has features
that I like. This does not mean that I _should_, or even want to, try
to impose those on others.
> and even more strongly for function calls
> which look like references to subscripted variables.
No. I shouldn't. Nor do I care for your attempt to tell me what I
should or shouldn't do.
> My COBOL pre-processor recognized paragraph names without a preceeding period.
> When it saw a one-word sentence
A sentence id _defined_ as being terminated by a full-stop and space.
If it saw a 'sentence' then this must have been bounded by the end of
the previous sentence and teminated by another full-stop and space.
But of course you are not using the terms in any defined way but just
making up how you term things. This does introduce ambiguity.
> not defined as data, that's a paragraph name.
Your pre-processor is obviously just ignoring one interpretation of
the ambiguous state. You have been shown cases where this _is_
ambiguous, the fact that your pre-processor is incompetent is of no
consequence, the compiler will pick this up later.
> Terminate the previous sentence with a period to placate the COBOL compiler. For
> example, when presented with 'move a b c. move d e', it looked to see whether
> 'c' was defined as data. If not, it output:
x1.
> move a to b.
> c.
> move d to e
>
> I acknowledge that's as sloppy as the function call example above, which is why
> I stopped using the preprocessor.
Not only sloppy but dangerous. If the program had 'perform x1' and
the 'c' was a typing error for an actual variable c1, then how do you
discover the two introduced bugs ?
As I said it fails to resolve the ambiguity.
> I did write my own preprocessor. For instance, it, along with APS and others,
> honored indentation as significant. When people read source code, they see
> subordination based on indentation, not explicit block terminators or level
> numbers. It would be nice if compilers at least gave a warning when seeing an
> out-dent without a preceeding terminator.
This is not part of Cobol, indentation is entirely up to the
programmer. If you like enforced indentation indicating level then
try Python.
Richard
> >> You are simply wrong. Every punctuation symbol represents a word. It may not
> >> be enunciated in the spoken language, but it is still a word.
> >
> >Cite?
>
> ..The beloved '85 COBOL standard, section 5.1.7:
>
> "The separator period, when used in these formats, has the status of a required
> word."
This does not say that the full stop _is_ a word, or _represents_ a
word, as you claimed, but only that under certain conditions it is
given the same status as a required word in that it is required.
> They could have said 'The separator period is required.' Instead they went out
> of their way to promote it to a word.
No. The full stop is not promoted to _being_ a word, it is not even
being promoted to having the same status as a word, it is having the
same status as a _required_ word.
'Status' (eg 'required') is an attribute. 'Required word' and
'full-stop' are entities. Just because two enties have the same value
in an attribute does not make them the same entity.
But this is irrelevant. Your claim was for
>> "The grammar of all languages -- English, COBOL and (whatever) --
...
>> Punctuation such as the period are words.
Show us an example in English.
> ..Common usage, as seen in 'dot-com' and 'dot-NET'.
In '.com' and '.NET' the '.' is _not_ a punctution full stop. It
happens that it is the same symbol as is used for punctuation, but it
not punctuation.
Your claim was 'Every punctuation symbol represents a word'. The fact
that non-punctuation symbols (such as '=', '+', '&' or the '.' in
3.14157) may be voiced is irrelevant to punctuation.
> ..My Demo program parses COBOL source into a list of "words". It does not have
> one type structure for lexemes and a different structure for punctuation.
The fact that your program chooses to process in this way shows
nothing about your claim. In fact it may be that your program has
inappropriately named variables and this should be a list of "words
and symbols".
Yet you attempt to use this as _evidence_ ?
Robert Wagner
>You are wrong. You have been told you are wrong. You continue to
>mis-represent what the Standard does.
>
>Do you think that you will have anyone believing you when you state
>something correctly - if you keep arguing for things that have already been
>shown to be wrong.
>
>The 2002 Standard has explicit ways of "discouraging" features - and periods
>just are NOT in this category. It doesn't matter what you WANT, you can't
>claim it for the Standard.
>
>You *might* want to submit a paper asking for "middle of the paragraph"
>periods to be put in the archaic category in the NEXT COBOL Standard. Maybe
>if you need that and heard back from the real standards committees you would
>stop making a complete fool of yourself.
Judging from the vitriol, I'm obviously hitting a nerve. The period is more than
a punctuation mark, it's a SYMBOL of old COBOL. If the period falls, so too do
fall-through paragrphs, PERFORM .. THRU and the 77 level .. all of which are
indefensible.
This is about culture, not about a punctuation mark.
Robert
Richard
> >What is the big attraction to eliminating periods?
>
> Moving sections of code in and out of if statements is simplified.
Finally, after screeds of nonsense in made up arguments, most of which
were completely irrelvant, many of which were just wrong, you have
discovered the only real argument against full stops wherever
possible.
Of course, most of us knew this anyway, some find that it not a big
deal anyway, many having adequate tools that can deal with this (does
your editor have macros or are you using archaic and obsolete tools ?)
I quite agree that this is made easier, and it is partly why I don't
use full stops on the end of each statement. The other is that it is
an issue of personal choice and I choose one way, others choose
another.
But it does not apply to the full stop at the end of a paragraph which
I put on a line by itself. This makes no difference at all to
indenting or outdenting the code.
There is no reason at all to eliminate that, and every reason to
retain it (eliminating ambiguity).
Robert Wagner
>You *might* want to submit a paper asking for "middle of the paragraph"
>periods to be put in the archaic category in the NEXT COBOL Standard. Maybe
>if you need that and heard back from the real standards committees you would
>stop making a complete fool of yourself.
I probably will not be around seventeen years hence. COBOL standards committees
are unacceptably slow.
Robert
Richard
> it has become a trouble-maker
> which must be avoided inside IF and every other explicitly terminated statement.
Actually the full stop _always_ had to be avoided inside IF (that is
between the IF and the terminating mechanism. It hasn't 'become'
this, it always has been.
> I speculate periods were not designated archaic for political reasons.
No.
Some of them refer to '85 COBOL as "new COBOL" .. 18 years later.
Evidence ? _Who_ has recently called the '85 standard 'new' ?
> They are not the constituancy who will be first in line to try OO COBOL; they
> will be near the end of the line.
You have absolutely _no_ idea who has and who has not tried OO Cobol,
or indeed who had already tried other OO languages over the last few
decades before OO Cobol became available to try. Many who have
already been using OO Cobol for some time are Cobol programmers from
30 years ago or so.
> Because it retained backward compatibility, C++ experienced the same growing
> pains.
Crap. C++ grew in usage exactly because it retained backwards
compatability. It it had not then it would have grown much more
slowly, or not at all.
> I've been in many shops who SAY they program in C++.
Delivering Pizzas were you ?
> It will be eliminated only by a major
> paradigm shift, such as OO. For this reason, I applaud the addition of OO
> features to COBOL.
You criticised C++ because it added OO feature to the core of C to
retain backwards compatability, now you praise Cobol for
_exactly_the_same_thing_.
> OO turns a programming language into a mega-language. ...
> Every programmer has been promoted to language designer.
Now you criticise OO, in fact you criticise the 'major paradigm shift'
that you claimed was required and you applauded.
You are a very confused little puppy.
Donald Tees
>
> Method-id. "byName".
> if not ByName
> set Byname to true
> invoke self "createNamelist"
> End-if
> End Method "byName".
>
> The OO method contains only one more line of code than the non-OO to signify the
> 'end' of the 'mini program'. To 'tart' it up I add comment lines for readability.
>
> Jimmy, Calgary AB
>
Only if you allow fall-through to end of program, Jimmy. ;).
You really should have an EXIT METHOD in there before the end method,
though it will work that way. Falling off the end of a program is not a
good idea.
Donald
Donald Tees
>
>>When IF statements get so
>>complex that you cannot tell what they are doing, it is a very simple
>>matter to break it down into groups of statements by putting the groups
>>into multiple paragraphs, and giving them names. That way, things are
>>readable.
>
>
> Now you've (unwittingly) put your finger on the real issue here -- fear of being
> overwhelmed by complexity. That threshold is a function of the program's logic
> AND your ability to comprehend. The program's logic isn't going to change, no
> matter how it written. It is going to make the same decisions ONE WAY OR
> ANOTHER. They can be made in one complete statement or they can be disbursed
> into simpler but incomplete statements. The only variable is you.
>
Are you being deliberately insulting, is it just lack of social skills,
or are you actually this thick?
It was not unwittingly at all. It is the crux and the center of the
arguement.
Any properly written top down program, with the advent of all the new
scope delimiters, can be broken down into chunks in three ways.
We can use sentences, with periods, we can use paragraphs, with names,
and we can use inline statements, with terminators. As you say, the
logic does not change.
I could quite easily remve every single paragraph name in my code, and
every period but one in the entire procedure division. Everything else
could be handled by scope delimiters.
I could also remove every single group of more than one statement, place
each in a paragraph, and give it a name. If I do that, then the problem
with periods in the middle of IF's ceases to exist.
I really do not see that
IF LINE-COUNT IS GREATER THAN PAGE-SIZE
PERFORM NEW-PAGE-ROUTINE.
BLAH BALH BLAH
is inferior to:
IF LINE-COUNT IS GREATER THAN PAGE-SIZE
********* The following is the page routine
BLAH BLAH BLAH
********* end of the page routine
END IF
*********END OF THE PAGEING IF
ELSE
BLAH BLAH BLAH
.
*********END OF THE PARAGRAPH
It simply clutters things up. The fact that the paragraph dealing with
paging is elsewhere in the code is NOT detrimental, as you claim. In
fact, it is the eaxct opposite ... if I am interested in fixing a paging
bug, I can search for it. If I am not, I can safely ignore it and
continue reading. I do not have to analyse the sentnce to find our
where it continues.
Your arguement about inserting "sentences" into IF statements bears the
same flaw ... do not do it. If you lay your paragraphs out correctly,
then you put it into the correct paragraph, not into the IF statement.
To repeat:
I could quite easily remve every single paragraph name in my code, and
every period but one in the entire procedure division. Everything else
could be handled by scope delimiters.
However, to assert that such an approach, even in part, is sytlistically
preferable shows an appalling lack of sophistocation in code writing
ability. You seem to be locked into a mindset more suited to a
different langauge ... perhaps one that does not have such an elegant
solution as a named paragraph.
Donald.
Thane Hubbell
Two quick comments:
First re: speed and standards - check the excellent article by Jerome
Garfunkel at cobolreport.com - it has some interesting historical
perspective on this and on COBOL's place in general.
Second - I glean from your messages that you think making something
Archaic is the first step toward making it obsolete. Items in the
Archaic category do not move directly into obsolete by any mechanism,
nor it appearing in the Archaic category a precursor to something
becoming obsolete.
SkippyPB
enlightened us:
No, it is about your bias, your ego and your arrogance. What you are
opposing is the part of the very structure of Cobol and whether you
like it or not it is there in the language; it is not indefensible;
and it is useful. Maybe you'd like to see commas removed from IBM
Assembler because they are an old symbol as well? Or maybe you should
just stick to C++ or the language du jour as I'm sure they won't have
any archaic symbols to gnaw in your craw.
Regards,
////
(o o)
-oOO--(_)--OOo-
Vulcanization: The process whereby rubber grows pointed ears and
starts saying "Live long and prosper".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Richard
> After a few more change iterations, your code has turned into spaghetti.
> Now a production support person is trying to figure out how garbage got into c.
Have you never heard of a 'strawman argument' ?
> Comments are for explaining what statements do, not paragraph names. If it takes
> an hour for you to figure out what a group of statements does, add a comment so
> the next maintenance programmer won't have to do it again. I sometimes comment
> code I wrote a few months ago.
Did it take you an hour to figure out your own code ?
> A pat on the back to you. You're 90% on the way to Real Programming. We just
> need to work on those periods and logic anxiety.
You are an arrogant little prat aren't you. Being condescending
doesn't win you friends, or change anyone's minds about how to
program.
Richard
> You must rebut his points or remain silent.
>
> This case is different because I DO claim to be an authority on Practical Use of
> COBOL. My claim is based on forty years of writing a million lines of code and
> supervising the write/rewrite of 5-10 million lines.
And I have 'only' 35 years of Cobol and several other languages.
You have, however, shown that you are _not_ an authority on what the
Cobol standards say, making several claims that were completely wrong.
You are obviously not an authority on natural languages, merely making
up arguments that you feel may support your crusade.
You certainly aren't an authority on personal motovation. You will
not get anyone to change their style by implying they are incompetent.
> So feel free to respond emotively. However, because this is a public forum, it
> would be instructive to readers if you rebutted SOME of the points I make.
> Otherwise, you'll sound like that 'poopie' guy.
Readers don't benefit much from
> learning I'm a low-IQ a-hole.
In an earlier post about your 'byte level OS' you stated that the
comp.sci. types wouldn't reply with cogent arguments, but resorted to
insults. At the time I offered that they had been giving arguments
which you simply ignored because you were too attached to your own
ideas, and eventually they just told you to fuck off because they
realised you would never listen.
Now why would I have thought that ?
> Readers don't benefit much from learning I'm a low-IQ a-hole.
They learn that from your messages, not mine.
Paul Raulerson
Take a chill pill please - this discussion is borering periously close to personal attacks, and that is something we don't need.
Especially over something as silly as a period.
I will state that Bill, Thane, Doc, Don, and others here are better authorities on COBOL than you will find gathered together
*anywhere* else - and as such have more than earned at least enough respect to demand politeness.
I am interested in Periods in pretty much an academic sense. I don't allow periods to be used in the procedure section except to
end paragraphs and where required. I also don't allow fall through programming or perform-thru. The reason I don't allow those
techniques has nothing to do with technical COBOL issues, it is because those design choices offend those of us trained in OOD.
Paradoxically, I don't find semi-colons behind C statements offensive, but my C shop is also not allowed to use them to end if
statements, while statements, and such. They have to use {} pairs even when the language does not require them.
Same reason as above.
I find that inconsistancy in myself a little amusing I suppose.
Anyway, point is, find a little more humor in this guys, and let the rancor, even if you believe it is deserved, go.
-Paul
Richard Plinston
> You really should have an EXIT METHOD in there before the end method,
> though it will work that way. Falling off the end of a program is not a
> good idea.
Implicit return at end of a procedure (or method) is common in many
languages, such as C/C++.
Not only will it 'work that way' but the standard guarantees that it will
work.
Your 'should have' and 'good idea' are purely a matter of personal style,
as is everything else that you argue about and try to impose on others.
Richard
> >You are wrong. You have been told you are wrong. You continue to
> >mis-represent what the Standard does.
> >
> >Do you think that you will have anyone believing you when you state
> >something correctly - if you keep arguing for things that have already been
> >shown to be wrong.
> >
> >The 2002 Standard has explicit ways of "discouraging" features - and periods
> >just are NOT in this category. It doesn't matter what you WANT, you can't
> >claim it for the Standard.
> >
> >You *might* want to submit a paper asking for "middle of the paragraph"
> >periods to be put in the archaic category in the NEXT COBOL Standard. Maybe
> >if you need that and heard back from the real standards committees you would
> >stop making a complete fool of yourself.
> Judging from the vitriol,
I see no 'vitriol' in the reply to you, only an informed opinion
stating that your assertions are simply wrong.
> I'm obviously hitting a nerve.
Yes, you are hitting a nerve. WMK is extremely well informed on the
standards, while you have demonstrated a complete lack of knowledge of
them. Repeatedly you have made incorrect statements about what the
standards do or do not say in an attempt to further your crusade.
Even when your errors are pointed out to you you completely ignore
this because, apparently, your crusade is more important to you than
facts.
> The period is more than
> a punctuation mark, it's a SYMBOL of old COBOL. If the period falls, so too do
> fall-through paragrphs, PERFORM .. THRU and the 77 level .. all of which are
> indefensible.
The full stop will not 'fall'. Its use (whether minimum or maximum)
is quite independent of other features, you are merely attempting to
appeal to emotion.
> This is about culture, not about a punctuation mark.
I thought that you had made it a crusade.
Richard Plinston
> Donald Tees wrote:
> .....
>
> as is everything else that you argue about and try to impose on others.
Oops, sorry, I unreservedly withdraw this, it was an overflow from writing
to RW.
Robert Wagner
>Robert Wagner wrote:
>Any properly written top down program, with the advent of all the new
>scope delimiters, can be broken down into chunks in three ways.
There are four (non-OO) ways. I'll discuss the fourth below.
>We can use sentences, with periods, we can use paragraphs, with names,
>and we can use inline statements, with terminators. As you say, the
>logic does not change.
>
>I could quite easily remove every single paragraph name in my code, and
>every period but one in the entire procedure division. Everything else
>could be handled by scope delimiters.
>
>I could also remove every single group of more than one statement, place
>each in a paragraph, and give it a name. If I do that, then the problem
>with periods in the middle of IF's ceases to exist.
Everything you just said is correct. The issue is called granularity, the quest
for the optimum-sized chunk of code. Some factors affecting the answer are human
comprehension, experience with the style used and (often overlooked) tools used
to view source. For example, if we could hyperlink to an out-of-line paragraph
or function by hitting one key then return by hitting one key, out-of-line
paragraphs would be more attractive. Similarly, in-line code would be more
attractive if the viewer worked like an outline processor, letting us hide and
reveal subordinate blocks of code with a single keypress or mouseclick. My text
editor does both.
>However, to assert that such an approach, even in part, is sylistically
>preferable shows an appalling lack of sophistocation in code writing
>ability. You seem to be locked into a mindset more suited to a
>different langauge ... perhaps one that does not have such an elegant
>solution as a named paragraph.
I did not advocate one packaging style exclusively. In fact, the non-trivial
Demo Program I posted here uses a balance of all three methods. A snippet is
copied below.
The Demo uses a fourth method: the function. Every named paragraph could be
converted to an inline function, which provides the same functionality but with
two significant benefits:
.. You can pass parameters to a function, not to a paragraph
.. A function has its own working-storage variables which the parent cannot
change. Also, a function cannot monkey around with the parent's working-storage.
A commonly-held false belief is that functions must be separately compiled.
Every '85-compliant COBOL compiler offers the option of putting them in the same
source file with their parent, which may be the 'main' program or one of its
functions. Thus you have a single 'program to compile'. I find it elegant the
way they are nested inside their respective parents in telescoping fashion.
Named paragraphs, by contrast, may be scattered anywhere.
The Demo Program used five functions nested three-deep for its outer structure.
Simply put, it used functions for big chunks of code, named paragraphs for
medium-sized chunks, and inline code for small chunks. Does that demonstrate
lack of sophistication or single-minded advocacy of one style over all others?
Code sample follows:
if current-verb equal to 'delete'
perform find-file-entry
else
perform find-file-entry-by-record
end-if
if file-found
set file-write to address of word-entry
end-if
end-if
move a-word to a-word-previous.
find-file-entry.
set hold-current-word to address of word-entry
set file-not-found to true
set address of file-entry to first-file
perform until address of file-entry equal to null or file-found
set address of word-entry to file-select
if address of word-entry not equal to null and
word-text equal to current-fd
set file-found to true
else
set address of file-entry to next-file
end-if
end-perform
set address of word-entry to hold-current-word.
find-file-entry-by-record.
set hold-current-word to address of word-entry
set file-not-found to true
set address of file-entry to first-file
perform until address of file-entry equal to null or file-found
set address of word-entry to file-record
if address of word-entry not equal to null and
word-text equal to current-record
set file-found to true
else
set address of file-entry to next-file
end-if
end-perform
set address of word-entry to hold-current-word.
find-file-entry-by-name.
set hold-current-word to address of word-entry
set file-not-found to true
set address of file-entry to first-file
perform until address of file-entry equal to null or file-found
set address of word-entry to file-name
if address of word-entry not equal to null and
word-text equal to current-record
set file-found to true
else
set address of file-entry to next-file
end-if
end-perform
set address of word-entry to hold-current-word.
construct-file-entry.
compute allocation-length =
length of fixed-portion of file-entry + 2
set allocation-pointer to null
call 'malloc' using allocation-length, allocation-pointer
if allocation-pointer equal to null
set malloc-error to true
display 'pf error constructing file ' return-code
goback
end-if
set address of file-entry to last-file
if first-file equal to null
set first-file to allocation-pointer
else
set next-file to allocation-pointer
end-if
set address of file-entry to allocation-pointer
move zero to file-length
move low-values to fixed-portion of file-entry
move last-file to previous-file
move allocation-pointer to last-file.
end program analysis-function.