Home > Archive > Cobol > February 2005 > If you were inventing CoBOL...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
If you were inventing CoBOL...
|
|
| Howard Brazee 2004-09-02, 3:55 pm |
| If you were inventing CoBOL back when, what would you do differently?
I wonder how foresight would have effected OO enhancements.
I would like a USAGE LARGE for numbers that don't fit computer architecture
(have a hundred digits, but inefficient).
Could we get away with enforced structure with the efficiencies back then?
Would you do calls differently?
I see no reason for margins on the left and in the right.
I'd standardize GOBACK type exits.
I'd really like to improve on error checking for calls and functions.
| |
| Pat Hall 2004-09-02, 3:55 pm |
| Buuuuttttt If you were inventing COBOL would you be limited to the
hardware and memory constraints of yester year? Makes a huge difference.
PatH...doesn't want to hurt his brain too much this morning
Howard Brazee wrote:
> If you were inventing CoBOL back when, what would you do differently?
>
> I wonder how foresight would have effected OO enhancements.
>
> I would like a USAGE LARGE for numbers that don't fit computer architecture
> (have a hundred digits, but inefficient).
>
> Could we get away with enforced structure with the efficiencies back then?
>
> Would you do calls differently?
>
> I see no reason for margins on the left and in the right.
>
> I'd standardize GOBACK type exits.
>
> I'd really like to improve on error checking for calls and functions.
| |
| Howard Brazee 2004-09-02, 3:55 pm |
|
On 2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:
> Buuuuttttt If you were inventing COBOL would you be limited to the
> hardware and memory constraints of yester year? Makes a huge difference.
Maybe it would be interesting to split the answer into what I asked - you were
inventing it back then - and a separate answer if we had today's resources but
no need to have backward compatibility.
| |
| Robert Wagner 2004-09-02, 3:55 pm |
| On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
wrote:
>If you were inventing CoBOL back when, what would you do differently?
Omit PERFORM THRU.
People wouldn't have acquired bad habits that had to be unlearned
later. The concept is flawed, and caused compilers grief in re
returns.
Make PERFORM pass parameters.
Define a DATE type.
Forget SECTIONs. They've always been unnecessary.
>I wonder how foresight would have effected OO enhancements.
??
>I would like a USAGE LARGE for numbers that don't fit computer architecture
>(have a hundred digits, but inefficient).
Don't need USAGE; pic 9(1000) says what you want.
>Could we get away with enforced structure with the efficiencies back then?
Yes. Structured has always been faster than spaghetti. Better overall
flow compensates for micro-inefficiencies.
>Would you do calls differently?
No.
But I would add better dynamic memory. You call with a structure, it
allocates memory, sets a pointer to the structure but hides it from
you. It's like an OO constructor. Then people wouldn't be afraid of
pointers because they couldn't accidentally step on them.
>I see no reason for margins on the left and in the right.
I've been using free-form for >20 years, on >3 compilers. The
foot-dragger is IBM.
>I'd standardize GOBACK type exits.
I didn't know it was a problem, even before 2002.
>I'd really like to improve on error checking for calls and functions.
You already have that. It's called Prototypes.
| |
| Peter Lacey 2004-09-02, 3:55 pm |
| Howard Brazee wrote:
>
> On 2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:
>
>
> Maybe it would be interesting to split the answer into what I asked - you were
> inventing it back then - and a separate answer if we had today's resources but
> no need to have backward compatibility.
Inventing it back then: most certainly include the in-line performs
(perform ...end-perform) and end-if; but I'd have to leave space
somewhere on the form for sequence numbers because we were using card
decks! I would have a different method for indicating overlayable
sections due to memory limitations.
If I were inventing it now: I'd require AT END and INVALID KEY with READ
statements (as appropriate); I would not have some verbs, especially
EVALUATE (hey! you did say "if YOU were inventing Cobol"! And despite
study, explanations and examples, I've yet to come across a case where
an evaluate couldn't be done more clearly and usually simpler with IF's
and/or CASE statments). We wouldn't need most of the various numeric
formats: "usage display" with (say) 24V8 maximum digits would suffice
for nearly everything, along with special formats for extreme precision
requirements and really big numbers. Apart from that, I would stick to
the original goal of clarity and English-like statements. Cobol has
stood the test of time due to its inherent strengths: smart to retain
those.
PL
| |
| Howard Brazee 2004-09-02, 3:55 pm |
|
On 2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
> Inventing it back then: most certainly include the in-line performs
> (perform ...end-perform) and end-if; but I'd have to leave space
> somewhere on the form for sequence numbers because we were using card
> decks!
But why do we need space for sequence numbers in 73-80 as well as 1-6? I've
sorted cards both ways.
| |
| Michael Russell 2004-09-02, 3:55 pm |
| The biggest omission, as far as I'm concerned - Date, DateTime & Time types,
plus the arithmetic functions for them.
Michael
| |
| Chuck Stevens 2004-09-02, 3:55 pm |
| See http://www.cobolportal.com/j4/files/04-0120.doc for the current state of
this capability as proposed by J4 for the 2008 COBOL standard. WG4 will
be discussing it next month. It doesn't require new "types" or PICTURE
character-strings -- all of its mechanisms coexist nicely with existing
COBOL USAGEs.
-Chuck Stevens
"Michael Russell" <michael.russell@spamex.dsl.pipex.com> wrote in message
news:413752b1$0$20257$cc9e4d1f@news-text.dial.pipex.com...
> The biggest omission, as far as I'm concerned - Date, DateTime & Time
types,
> plus the arithmetic functions for them.
>
> Michael
>
>
| |
| James J. Gavan 2004-09-02, 3:55 pm |
| Robert Wagner wrote:
>Forget SECTIONs. They've always been unnecessary.
>
>
>
In your purview yes. But back using a Radio Shack with only 64K -
absolute necessity to prioritize by allocating Section Numbers, to
'swap' in and out, in order to achieve some objectives. To-day - I gave
up on Sections nigh on 20 years ago when I first switched the
application to a PC - a Compaq portable.
Jimmy
| |
| Chuck Stevens 2004-09-02, 3:55 pm |
|
"avflinsch" <avflinsch@att.net> wrote in message
news:slrncjehhn.bj7.AB2RC@homer.linux1.lan...
> and procedural statements like
> set ws-switch-a to true -- (I know we can do this now)
> and set ws-switch-a to false -- (but we can't do this yet)
If you're talking about 88's, yes, you can, presuming a COBOL compiler
compliant with (or containing this particular feature of) the current
standard ISO/IEC 1989:2002, and presuming that the 88 has a "WHEN SET TO
FALSE" phrase in its VALUE clause.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-02, 3:55 pm |
|
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:413744C2.1041D866@mb.sympatico.ca...
> I would have a different method for indicating overlayable
> sections due to memory limitations.
Although memory limitations are far less an issue than they once were, it is
not clear that all architectures provide the capability of having arbitrary
large object code "blocks". SECTIONs allow the user to have some control
over the size of such "blocks" and to avoid having "block transitions" occur
in critical-path code. Even though I agree that the "Segmentation Module"
was way too specific and was appropriately marked as obsolete in '85, I
think retaining "SECTION" (as it still exists in 2002 COBOL) serves a useful
purpose -- whether or not the SECTIONs are ever referenced via GO TO or
PERFORM, and whether or not the implementor does "code block breaks" at
SECTION boundaries. If nothing else, they can be used to establish a
hierarchy of procedural code between the program and the paragraph levels,
which can be helpful to the programmer (or the *next* programmer to work on
the program).
-Chuck Stevens
| |
| William M. Klein 2004-09-02, 3:55 pm |
| On the subject of "margins on the left and right".
The '68 thru '85 (and '02 when in fixed form reference format) *only* specify
"sequence area" for columns 1-6. (Since the '85 Standard, this area doesn't need
to be numbers, much less in ascending order)
There is NO requirement for the "R-margin" (end of source code) to be after
column 72, 80, or any other specific place. This is left up to the implementor.
As far as what appears (if anything) between the R-margin and "end-of-line"
there is NOTHING in any previous or current standard suggesting that there
should (or must) be a "right margin". In an interpretation of the '85 Standard
(if I recall correctly - or it might just have been when developing the '02
Standard), it was determined that the "implementor definition of end of line"
*allowed* for the implementor to "support" columns 73-80 (for example) to
"include data". But this is certainly not something that the Standard ever
talks about, much less requires.
***
In the '02 Standard when using free form reference format, the "sequence area"
(columns 1-6) is gone. A programmer may (but is not required to) use inline
comments, at the end of any, many, or all lines to "identify" the line.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Chuck Stevens 2004-09-02, 3:55 pm |
| Even in fixed-form reference format, the distinction between Margin A and
Margin B is gone in ISO/IEC 1989:2002.
-Chuck Stevens
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:cJmdnUo_d4697KrcRVn-rw@comcast.com...
> On the subject of "margins on the left and right".
>
> The '68 thru '85 (and '02 when in fixed form reference format) *only*
specify
> "sequence area" for columns 1-6. (Since the '85 Standard, this area
doesn't need
> to be numbers, much less in ascending order)
>
> There is NO requirement for the "R-margin" (end of source code) to be
after
> column 72, 80, or any other specific place. This is left up to the
implementor.
>
> As far as what appears (if anything) between the R-margin and
"end-of-line"
> there is NOTHING in any previous or current standard suggesting that there
> should (or must) be a "right margin". In an interpretation of the '85
Standard
> (if I recall correctly - or it might just have been when developing the
'02
> Standard), it was determined that the "implementor definition of end of
line"
> *allowed* for the implementor to "support" columns 73-80 (for example) to
> "include data". But this is certainly not something that the Standard
ever
> talks about, much less requires.
>
> ***
>
> In the '02 Standard when using free form reference format, the "sequence
area"
> (columns 1-6) is gone. A programmer may (but is not required to) use
inline
> comments, at the end of any, many, or all lines to "identify" the line.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
>
| |
| Chuck Stevens 2004-09-02, 8:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@
4ax.com...
then?[color=darkred]
>
> Yes. Structured has always been faster than spaghetti. Better overall
> flow compensates for micro-inefficiencies.
*Always*?
The seeds of "structured programming" appear to have been first sown with
Edsger Dijkstra's paper disparaging the use of GO TO, some eight years after
the specification of COBOL-60 and some two years before the content of what
became the '68 standard was finished! The only *language* I've ever run
into that seemed to take Dijkstra's opinions to heart was SDL/UPL on the
B1000 -- and this, I believe, was written during the period when Dijkstra
was a Burroughs fellow, and even that had an "UNDO" statement whose effect
was to take flow out of the current block -- and in a violation of
Dijkstra's philosophy, out of a *parent* block. The concept of the "block"
was adopted from Algol, a language which Dijkstra (and later Wirth) greatly
admired.
There are some things that have been done through the history of COBOL that
I'd personally rather have been done differently, and at some point I may
articulate them, but I want to avoid speculations like "If pigs had wings,
maybe they could fly" in the process.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-02, 8:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:ch7nl8$t7s$1@peabody.colorado.edu...
> OK. In 1969 I saw no reason for margins on both the left and in the
right.
> Admittedly CoBOL was a mature language then, but we still used punched
cards.
> 1969 was Model T time as far as computing goes.
In 1969 -- and well into the 1980's, at least -- people were *still* using
punch cards as input not only to application programs but to compilers --
either as source patches or as entire source files. The programmer who
didn't put sequence numbers in his source card decks was risking
catastrophe! It was a Big Deal for a user site I worked for when we were
able to nstall our very first data communications network, went to
line-at-a-time source editing using (gasp!) terminals and got rid of our
keypunches in 1977! Certainly the distinction between Margin L and Margin
C was important to *that* site!
-Chuck Stevens
| |
| Jeff York 2004-09-02, 8:55 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>
>On 2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>
>
>But why do we need space for sequence numbers in 73-80 as well as 1-6? I've
>sorted cards both ways.
<Zummmerzet accent>
When I were just a young laad.. We used to put the program ID in
73-80 as well as the sequence in 1-6. That way, if/when one of the
ops dropped a tray of cards it was possible to sort them back into
correctly-sequenced individual programs.. :-)
</Zummerzet accent>
--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| Howard Brazee 2004-09-02, 8:55 pm |
|
On 2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> In 1969 -- and well into the 1980's, at least -- people were *still* using
> punch cards as input not only to application programs but to compilers --
> either as source patches or as entire source files. The programmer who
> didn't put sequence numbers in his source card decks was risking
> catastrophe! It was a Big Deal for a user site I worked for when we were
> able to nstall our very first data communications network, went to
> line-at-a-time source editing using (gasp!) terminals and got rid of our
> keypunches in 1977! Certainly the distinction between Margin L and Margin
> C was important to *that* site!
Sure. I remember using the card sorter to put my deck back in order. But I
never needed both sets of sequence numbers to do so. One was sufficient.
| |
| Howard Brazee 2004-09-02, 8:55 pm |
|
On 2-Sep-2004, Jeff York <ralf4@btinternet.com> wrote:
> When I were just a young laad.. We used to put the program ID in
> 73-80 as well as the sequence in 1-6. That way, if/when one of the
> ops dropped a tray of cards it was possible to sort them back into
> correctly-sequenced individual programs.. :-)
That's right. I forgot about that. Some shops had that, and others used the
same sequence number standards they used for JCL, namely numbers in the right.
| |
| Lueko Willms 2004-09-02, 8:55 pm |
| .. Am 02.09.04
schrieb robert@wagner.net.yourmammaharvests (Robert Wagner)
auf /COMP/LANG/COBOL
in eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
ueber Re: If you were inventing CoBOL...
RW> Forget SECTIONs. They've always been unnecessary.
Besides that in my style, I always divided up my programs in
SECTIONs (having one single paragraph called ANFANG, i.e. German for
"BEGIN"), you can't do without SECTIONs when you are using
DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.
yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela
| |
| Lueko Willms 2004-09-02, 8:55 pm |
| .. Am 02.09.04
schrieb howard@brazee.net (Howard Brazee)
auf /COMP/LANG/COBOL
in ch7nl8$t7s$1@peabody.colorado.edu
ueber Re: If you were inventing CoBOL...
[color=darkred]
HB> OK. In 1969 I saw no reason for margins on both the left and in the
HB> right. Admittedly CoBOL was a mature language then, but we still used
HB> punched cards. 1969 was Model T time as far as computing goes.
So what was the punched tape back then? A phaeton? A race-car?
Algol, it seems, was for the people using punched tape, and
FORTRAN, I read, was an effort to sell punched cards to engineers.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)
| |
| Robert Wagner 2004-09-02, 8:55 pm |
| On Thu, 2 Sep 2004 10:37:31 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>
>"avflinsch" <avflinsch@att.net> wrote in message
>news:slrncjehhn.bj7.AB2RC@homer.linux1.lan...
>
>
>If you're talking about 88's, yes, you can, presuming a COBOL compiler
>compliant with (or containing this particular feature of) the current
>standard ISO/IEC 1989:2002, and presuming that the 88 has a "WHEN SET TO
>FALSE" phrase in its VALUE clause.
We can say:
05 pic 9 value 0.
88 end-of-file value 1 false 0.
And we can say:
set end-of-file to false
But we cannot say:
05 pic 9 value not end-of-file.
88 end-of-file value 1 false 0.
We have to code the value 0 in two places. Someone might change one
and overlook the other.
If it's indirect in the procedure division, why isn't it indirect in
the data division as well?
| |
| Robert Wagner 2004-09-02, 8:55 pm |
| On Thu, 02 Sep 2004 17:25:38 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:
>Robert Wagner wrote:
>
[color=darkred]
>In your purview yes. But back using a Radio Shack with only 64K -
>absolute necessity to prioritize by allocating Section Numbers, to
>'swap' in and out, in order to achieve some objectives. To-day - I gave
>up on Sections nigh on 20 years ago when I first switched the
>application to a PC - a Compaq portable.
If you MUST do memory management, dynamic CALL/CANCEL is better.
It has the additional benefit of organizing an oversize program into
more manageable pieces.
| |
| Chuck Stevens 2004-09-03, 3:55 am |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:4s2fj0dubd28r06p92bcvnrmg9jsurin6b@
4ax.com...
> Get rid of precedence rules. Require that logical and arithmetic
> statements use parentheses on statements containing more than one
> level.
I actually agree with Robert here in at least part of this: I think
abbreviated combined relation conditions in particular are a delusion and a
snare. The big problem with them is that it is at first glance
*reasonable* but ultimately *erroneous* that abbreviation implies some sort
of association not otherwise implied by the precedence rules (or the
parentheses).
The 2002 standard points out some of the problems with Abbreviated Combined
Relation Conditions in an ISO NOTE on page 137 relating to the use of NOT
in abbreviations; this has been expanded further a part of the
clarifications in an approved proposal to add the relational operator "<>"
for "not equal" in the draft for the next standard, which proposal may be
found at http://www.cobolportal.com/j4/files/03-0224.doc .
COBOL's arithmetic precedence rules don't bother me that much; they seem to
match Fortran, ALGOL, Pascal and PL/I at least, so someone coming from those
languages shouldn't be terribly  .
But as a matter of style too many parentheses in either case is better than
too few.
> Require a warning on logical statements always true or false. For
> example:
> if a not = 1 or 2
> if a = b or c or a
Many implementors do this; it's not clear to me that it's the *standard's*
job to tell the *implementor* how to keep the *programmer* from shooting
himself in the foot in every case. I believe the standard specifies a
mechanism for flagging *standards violations*, but not one for *advisories*
along the lines of "Are you sure that's what you meant?" (or even for the
method of presentation of syntax *errors*, except that object code shouldn't
be produced when they occur). It may actually be a useful technique for
*incorporating* prototype code into *production* programs before testing is
complete; I've found it useful to "stub" large blocks of code that way -- or
even with "IF <enabling-condition> AND FALSE THEN ..." , where all I have to
do is delete the "AND FALSE" to open up the new logic, in my time.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-03, 3:55 am |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:042fj0ls9pu3je725nbdmkm45pths5csfr@
4ax.com...
> We can say:
>
> 05 pic 9 value 0.
> 88 end-of-file value 1 false 0.
>
> And we can say:
>
> set end-of-file to false
>
> But we cannot say:
>
> 05 pic 9 value not end-of-file.
> 88 end-of-file value 1 false 0.
>
> We have to code the value 0 in two places. Someone might change one
> and overlook the other.
>
> If it's indirect in the procedure division, why isn't it indirect in
> the data division as well?
I think that compromises the utility and clarity of the multivalued case for
TRUE. You could equally well have coded
05 pic 9 value not end-of-file.
88 end-of-file values 1 thru 9 false 0.
This is unambiguous as written, but what if it read "05 pic 9 value
end-of-file."?
I'm also not convinced that it adds significant utility. I'm also not sure
what "it" is that you are claiming needs to be "indirect".
-Chuck Stevens
| |
| Chuck Stevens 2004-09-03, 3:55 am |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@
4ax.com...
> If you MUST do memory management, dynamic CALL/CANCEL is better.
What, in *standards terms*, is "dynamic CALL/CANCEL"? The way I would
presume "dynamic" applied to CALL/CANCEL is CALL <dataname> as distinct from
CALL <literal>, and there are implementations where "dynamic CALL/CANCEL" is
maybe better than developing the information using an abacus and a pointed
stick on wet clay, but not by much!
I don't disagree that "modularity" is a virtue, and I happen to agree that
IPC (even as implemented according to '74 standards) is a really good way to
accomplish modularity, but I'm not convinced that the problems of memory
management are best solved by *procedural* modularity, particularly when the
system already does a pretty good job of handling object code, without any
involvement by the user at all, the overwhelming majority of the time.
> It has the additional benefit of organizing an oversize program into
> more manageable pieces.
One man's "oversize" is another man's "trivial".
Two personal hot buttons on related subjects:
Personally, I think "nested programs" is a Good Thing. I just don't like
where the '85 standard put them. I would personally have preferred that
the nested programs be located before any executable code in the PROCEDURE
DIVISION of the parent rather than after it.
While I'm on the subject of '85 CALL enhancements, I would have preferred
the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
"callee" rather than the sole responsibility of the "caller".
-Chuck Stevens
| |
| James J. Gavan 2004-09-03, 3:55 am |
| Jeff York wrote:
>"Howard Brazee" <howard@brazee.net> wrote:
>
>
>
>
><Zummmerzet accent>
>
>When I were just a young laad.. We used to put the program ID in
>73-80 as well as the sequence in 1-6. That way, if/when one of the
>ops dropped a tray of cards it was possible to sort them back into
>correctly-sequenced individual programs.. :-)
>
></Zummerzet accent>
>
>
>
Your Somerset shire bit hits the nail on the head. Started in systems on
an ICT 1500 at Trowbridge, (we were using Machine Code and mainly FAS
(1500 Assembler)). All paper tape. Moved to Debenhams in Taunton, ICL
1900 series where we initially still used paper tape. But already geared
to going to COBOL as the standard we did exactly as you did with the
paper tape, reference 1-6 and 73-80; (The identification helped when
splitting paper-tape and splicing in a correction).I think that may have
even been the case when we moved to key-to-tape and then key-to-disk. No
luxuries back in the '70s as Chuck pointed out. I think we got three
EXPENSIVE VDUs about '74 - a constant line-up (queue) of the programmers
trying to submit their jobs to the magic box on the floor below.
Currently, as a more practical use, if I do print a program to check
(sometimes more complete than viewing on screen) or if I wish to retain
a hard copy, then it's better for appearance to have margins for filing
in a binder - using 'portrait'.. I could go 'free format' but I still
stick to columns 8 - 72 inclusive.
That was a bloody feeble attempt at Zummerzet from a Shrop-SHAIRE lad !
Went back in 2000 and visited Yeovil and Taunton -  ly just 'townie'
accents, somewhat 'Estuary English' (London). Noww iff oid garn upt ter
Dunkery Beacon to voo the Welsh Coast on a dursant day, quate liklee I
wouldda 'ad sum werds wiv folks wat zounded loike the charaketers from
Blackmore's "Larna Duuune" (Lorna Doone). :-)
Jimmy, Calgary AB
| |
| William M. Klein 2004-09-03, 3:55 am |
| Do add to Chuck's comment, there is a common "misconception" that the CANCEL
statement *must* free storage. Not only does the Standard not require this,
there are a number of implementations that don't do it. The only thing that the
CANCEL statement is required to do is to insure that the next time the CANCELed
program is called, it is in initial - not last-used - state.
P.S. The IBM mainframe documentation states that the reason that using the
NODYNAM compiler option is "not conforming to the ANSI/ISO Standard" is that it
does NOT insure that a CANCEL places subprograms in initial state. I don't know
how many/which other implementations may have this same "non-Standard" behavior.
If they do, then they must include an option (similar to IBM's DYNAM option) for
standard conformance.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ch86r0$t6i$1@si05.rsvl.unisys.com...
>
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@
4ax.com...
>
>
> What, in *standards terms*, is "dynamic CALL/CANCEL"? The way I would
> presume "dynamic" applied to CALL/CANCEL is CALL <dataname> as distinct from
> CALL <literal>, and there are implementations where "dynamic CALL/CANCEL" is
> maybe better than developing the information using an abacus and a pointed
> stick on wet clay, but not by much!
>
> I don't disagree that "modularity" is a virtue, and I happen to agree that
> IPC (even as implemented according to '74 standards) is a really good way to
> accomplish modularity, but I'm not convinced that the problems of memory
> management are best solved by *procedural* modularity, particularly when the
> system already does a pretty good job of handling object code, without any
> involvement by the user at all, the overwhelming majority of the time.
>
>
> One man's "oversize" is another man's "trivial".
>
> Two personal hot buttons on related subjects:
>
> Personally, I think "nested programs" is a Good Thing. I just don't like
> where the '85 standard put them. I would personally have preferred that
> the nested programs be located before any executable code in the PROCEDURE
> DIVISION of the parent rather than after it.
>
> While I'm on the subject of '85 CALL enhancements, I would have preferred
> the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
> "callee" rather than the sole responsibility of the "caller".
>
> -Chuck Stevens
>
>
| |
| Robert Wagner 2004-09-03, 3:55 am |
| On Thu, 2 Sep 2004 13:43:33 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>I'd *expect* any compliant compiler before '74 to stop looking for COBOL
>source after Column 72.
The current Oracle pre-compiler (Pro*Cobol) ABENDS if there's anything
beyond 72.
| |
| Robert Wagner 2004-09-03, 3:55 am |
| On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@
4ax.com...
>
>then?
>
>*Always*?
I meant at all times during the evolution of hardware, even on anemic
machines of the '60s.
Many people independently discovered structured programming in the
late '60s. I recall when I did in '68 after this conversation:
EM: Did you know it's possible to write a program without a single
GOTO?
RW: Nah, can't be done. How would you handle ...
EM: Here, look at this proof of concept.
RW: Hey, this is interesting. You know that program we were about to
rewrite? Let's try it this way. It'll be a challenge to write in this
wierd style.
We did, and it came out half the size (in source lines) as the
original. It ran faster too, on a Spectra 70 comparable to a 360-40.
So we rewrote a dozen more programs, developing style in the process.
We learned early on the value of many callable programs.
In he end, our rewrites were running 25-50% faster than the originals.
Why? Because they were more cleanly designed. We made decisions once
rather than several times. We passed data between programs in memory
rather than through files. We replaced three load modules and data
passes with one.
Structured programming per se didn't run faster. It was the catalyst
to learning top-down design. We'd write the framework first, stub out
or dummy the low-level code, and test flow of control FIRST. As we
added layers of lower code, it came into focus.
The old programs had been designed bottom-up .. by 'coders' who wrote
file handling first rather than last. They had inordinate trouble
mastering flow of control, which led to redundant code.
That's why structured programming is faster.
| |
| Robert Wagner 2004-09-03, 3:55 am |
| On 2 Sep 2004 12:48:34 -0700, riplin@Azonic.co.nz (Richard) wrote:
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>You may not know what they were for, but they were essential on
>machines that I used, and on most of the machines at the time.
They were for memory management. I used overlays on one machine, a
Honeywell 2200. Then I discovered dynamic call and didn't go back to
sections.
>
>You mean: just like Java does.
Realia had that in 1984. I wish others had copied it.
| |
| Robert Wagner 2004-09-03, 3:55 am |
| On 02 Sep 2004 19:52:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:
>. Am 02.09.04
>schrieb robert@wagner.net.yourmammaharvests (Robert Wagner)
> auf /COMP/LANG/COBOL
> in eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
> ueber Re: If you were inventing CoBOL...
>
>RW> Forget SECTIONs. They've always been unnecessary.
>
>you can't do without SECTIONs when you are using
>DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.
Declaratives are Cobol's equivalent of COME FROM. Problem is, they
don't know where they came from, so they can't describe the error in
detail.
| |
| Chuck Stevens 2004-09-03, 3:55 am |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:dq5fj092r4fdu26cuhun2j7v284pqtco0s@
4ax.com...
> On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> I meant at all times during the evolution of hardware, even on anemic
> machines of the '60s.
What about the anemic machines of the '50's? I did a little programming on
1401's, and also on machines that didn't have COBOL compilers or do "block
structure" very well to begin with.
>
> Many people independently discovered structured programming in the
> late '60s. I recall when I did in '68 after this conversation:
The deprecation of "go to" seems indeed to have been stimulated by an
article by Dijkstra published in March 1968. It's not clear *to me* that
there was widespread advocacy of such an approach before then.
> EM: Did you know it's possible to write a program without a single
> GOTO? ...
All very well and good, but it relied on ideas that nobody seems to have
espoused *before* March of 1968.
> We did, and it came out half the size (in source lines) as the
> original. It ran faster too, on a Spectra 70 comparable to a 360-40.
That doesn't mean the techniques could reasonably be applied before they
were invented. I don't think GO TO in COBOL is inherently evil any more
than the branch instructions on the 1401 were.
I don't think "if we had some ham, we could have some ham and eggs -- if we
had some eggs" speculations are useful; I'm personally limiting myself to
things that I believe were, in my view, architectural *errors*. The
presence or absence of GO TO is a religious war, and I personally know of
*no* hardware architecture that omits it altogether. Even BALR on the
System/360 did a *branch*. Speculation as to what the world would have
been like if Dijkstra had been Grace Hopper's boss back in the 1950's aren't
very useful in my view. I think there's a case to be made for some
mistakes in direction *at the time they were taken*, but I don't think
eliminating GO TO from COBOL would have been appropriate in 1968 or even
today.
> Structured programming per se didn't run faster. It was the catalyst
> to learning top-down design. We'd write the framework first, stub out
> or dummy the low-level code, and test flow of control FIRST. As we
> added layers of lower code, it came into focus.
>
> The old programs had been designed bottom-up .. by 'coders' who wrote
> file handling first rather than last. They had inordinate trouble
> mastering flow of control, which led to redundant code.
>
> That's why structured programming is faster.
And structured programming was a concept that wasn't "always" around.
-Chuck Stevens
| |
| JerryMouse 2004-09-03, 3:55 am |
| Chuck Stevens wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:ch7nl8$t7s$1@peabody.colorado.edu...
>
>
> In 1969 -- and well into the 1980's, at least -- people were *still*
> using punch cards as input not only to application programs ....
How about the 2000 election (and 2004 in some places)?
| |
| JerryMouse 2004-09-03, 3:55 am |
| Howard Brazee wrote:
> If you were inventing CoBOL back when, what would you do differently?
>
> I wonder how foresight would have effected OO enhancements.
>
> I would like a USAGE LARGE for numbers that don't fit computer
> architecture (have a hundred digits, but inefficient).
>
> Could we get away with enforced structure with the efficiencies back
> then?
>
> Would you do calls differently?
>
> I see no reason for margins on the left and in the right.
>
> I'd standardize GOBACK type exits.
>
> I'd really like to improve on error checking for calls and functions.
Frankly, I can't think of a thing I'd do differently.....
| |
| docdwarf@panix.com 2004-09-03, 3:55 am |
| In article <dq5fj092r4fdu26cuhun2j7v284pqtco0s@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>
>I meant at all times during the evolution of hardware, even on anemic
>machines of the '60s.
>
>Many people independently discovered structured programming in the
>late '60s. I recall when I did in '68 after this conversation:
>
>EM: Did you know it's possible to write a program without a single
>GOTO?
>RW: Nah, can't be done. How would you handle ...
>EM: Here, look at this proof of concept.
>RW: Hey, this is interesting. You know that program we were about to
>rewrite? Let's try it this way. It'll be a challenge to write in this
>wierd style.
[snip]
>In he end, our rewrites were running 25-50% faster than the originals.
>Why? Because they were more cleanly designed. We made decisions once
>rather than several times. We passed data between programs in memory
>rather than through files. We replaced three load modules and data
>passes with one.
>
>Structured programming per se didn't run faster. It was the catalyst
>to learning top-down design.
Good of you to come to this realisation, Mr Wagner... a less-biased test
between structured and non-structured would have been to have two teams
putting the same amount of analysis and design time into the code; what
you appear to have demonstrated above is that well-thought-out and
-designed structured code rewrites are faster than the original code was.
DD
| |
| Peter Lacey 2004-09-03, 3:55 am |
| Robert Wagner wrote:
>
>
>
> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
> don't know where they came from, so they can't describe the error in
> detail.
Sure they can: it takes some coding effort, though. Just set up WS
variables FILE-NAME, WHERE-IN-PROGRAM, and FUNCTION, and fill them
properly before performing any I-O. Then the Declarative can display
messages or make decisions based on what it's given. I've been doing it
for years.
PL
| |
| Warren Simmons 2004-09-03, 3:55 am |
| Robert Wagner wrote:
> On 02 Sep 2004 19:52:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
>
>
>
> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
> don't know where they came from, so they can't describe the error in
> detail.
>
>
Come from.....
Perform did a branch and return. Doesn't that count?
Warren
| |
| Warren Simmons 2004-09-03, 3:55 am |
| Robert Wagner wrote:
> On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
> wrote:
>
>
>
>
> Get rid of precedence rules. Require that logical and arithmetic
> statements use parentheses on statements containing more than one
> level.
>
> Do not allow logical elision between AND/OR nor into or out of
> parentheses.
>
> For example, this would be invalid:
>
> if a not = b and c or d
>
> Would be written as:
>
> if (a not = b and c) or (a not = d)
>
> Require a warning on logical statements always true or false. For
> example:
>
> if a not = 1 or 2
> if a = b or c or a
>
> Reason for both: after newbies get bitten a few times, shops pass
> rules prohibiting all elision. I think it's one of Cobol's nicest
> features. Other languages drive me crazy when they make me repeat the
> subject over and over.
>
>
then you would be delighted to know, that many years into the COBOL
effort, the CC had a task group trying to clarify this kind of
"logic". Seems most had never had that much exposure to this.
Warren
| |
| William M. Klein 2004-09-03, 3:55 am |
| If anyone doesn't know how to tell "where they came from" in a DEBUGGING
DECLARATIVE, check out the "Debug-item" special register. See (for example):
http://publibz.boulder.ibm.com/cgi-...gy3lr20/1.3.8.2
When/if you ever have a 2002 conforming compiler (and use "exception"
declaratives) check out the following (new) intrinsic functions:
EXCEPTION-FILE Information about the file exception that raised
an exception
EXCEPTION-FILE-N (National) Information about the file exception
that raised an exception
EXCEPTION-LOCATION Implementor-defined location of statement causing an
exception
EXCEPTION-LOCATION-N (National) Implementor-defined location of statement
causing an exception
EXCEPTION-STATEMENT Name of statement causing an exception
EXCEPTION-STATUS Exception-name identifying last exception
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:4137B89D.39484918@mb.sympatico.ca...
> Robert Wagner wrote:
>
> Sure they can: it takes some coding effort, though. Just set up WS
> variables FILE-NAME, WHERE-IN-PROGRAM, and FUNCTION, and fill them
> properly before performing any I-O. Then the Declarative can display
> messages or make decisions based on what it's given. I've been doing it
> for years.
>
> PL
| |
| Russell Styles 2004-09-03, 3:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:ch80hq$t3i$1@peabody.colorado.edu...
>
> On 2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
using[color=darkred]
compilers --[color=darkred]
were[color=darkred]
Margin[color=darkred]
>
> Sure. I remember using the card sorter to put my deck back in order.
But I
> never needed both sets of sequence numbers to do so. One was sufficient.
I never used copy statements back when I worked with punch cards
(college class),
but I can easily imagine having a library of copy members punched on cards.
As such,
their sequence numbers would not fit into the main program. If you put the
name of the
copy in cols 73-80, you could filter the sack full of cards into individual
decks before
sorting them.
Those card sorters were amazingly fast, considering they worked with
physical
cards.
| |
| James J. Gavan 2004-09-03, 3:55 am |
| Peter Lacey wrote:
>"William M. Klein" wrote:
>
>
>
>As Arte Johnson would say: "Verrry interesting". I'd be interested to
>see the implementation of EXCEPTION-LOCATION.
>
>PL
>
>
Peter,
So would I - but more specifically EC-conditions in general. I assume
you are still using Visual Age. The OCTG defined the general outline of
the COBOL OO structure about '93. As one of the first three, (Hitachi,
IBM and Micro Focus), IBM Visual Age syntax must be pretty close to
final 2002 format. Did IBM have an Exception Handler class ?
I note from your other message you said "the get back info" can be coded
*with effort* - but the 'get back info' you are referring to is not my
point. Three ways currently to write a COBOL program :-
1 - Procedural
2 - Procedural invoking OO support where necessary (Robert did this
using Collection classes, and you see it in examples illustrating
features like getting at OLEs - demo-wise it makes it clear).
3 - a Procedural Trigger program - the remainder *completely* OO classes
- which is what I use
#1 and #2 - if you *like* the Declaratives approach - onerous, but
that's a way to pick up on errors.
# 3 - an ABSOLUTE SOD ! Because my error may occur in a Class 5, 6 or 7
steps removed from Class 1 which started the action (Business Class).
I've raised this one before - and it was 'Grinder' with a Pascal
background who mentioned :-
{try...
catch}
a feature now available to Fujitsu users in dot Net ( via Version 7) and
Micro Focus users via N/E Version 4.0.. Not sure of the implications of
the above syntax - but stated simply, if I hit an error condition in
Class 7 which means I should terminate the module, (e.g. Payroll
calculations), but NOT abort the application - but go back to the menu
and use other modules which still work - how the hell can I get Class 7
to signal back to Class 1..
Not here, but if you have any code that illustrates anything similar -
I'd appreciate if you could send me some - and drop the second "J" in
the e-mail address.
Jimmy, Calgary AB
| |
| Richard 2004-09-03, 3:55 am |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> Declaratives are Cobol's equivalent of COME FROM.
There is actually no such thing as a 'come from', that is prely a joke.
They are, as someone else said, the exact equivalent of an 'ON ERROR'.
> Problem is, they don't know where they came from,
Of course they do, they can go back to where that was just like a PERFORM can.
> so they can't describe the error in detail.
No more nor no less than, say, a PERFORMed procedure can.
| |
| Jeff York 2004-09-03, 8:55 am |
| "James J. Gavan" <jjgavan@shaw.ca> wrote:
>Jeff York wrote:
>
>Your Somerset shire bit hits the nail on the head. Started in systems on
>an ICT 1500 at Trowbridge, (we were using Machine Code and mainly FAS
>(1500 Assembler)). All paper tape. Moved to Debenhams in Taunton, ICL
>1900 series where we initially still used paper tape. But already geared
>to going to COBOL as the standard we did exactly as you did with the
>paper tape, reference 1-6 and 73-80; (The identification helped when
>splitting paper-tape and splicing in a correction).
Blimey! You must be even older than me! I first programmed in
machine code and Fortran at uni, then my first "proper job" was at
Evode in Stafford, initially on a Univac 1004 (A plugged-program
machine!) followed by a "real computer" - an ICL 1901A which used
COBOL. The Univac was card input, card and print output. The program
board was about 2 feet square and fully-wired weighed about 40 pounds
so it took a degree of physical strength as it loaded at chest-height
and you had to be delicate otherwise it would knock some of the plugs
loose. It was a hanging-offence should anyone actually drop one!
<>
>That was a bloody feeble attempt at Zummerzet from a Shrop-SHAIRE lad !
T-t-terribly sorry old chap! :-) Oy thort loyke iffn oy daint ger
backter summat loyke ingliish, no bugger ud understaand me. :-)
>Went back in 2000 and visited Yeovil and Taunton - ly just 'townie'
>accents, somewhat 'Estuary English' (London). Noww iff oid garn upt ter
>Dunkery Beacon to voo the Welsh Coast on a dursant day, quate liklee I
>wouldda 'ad sum werds wiv folks wat zounded loike the charaketers from
>Blackmore's "Larna Duuune" (Lorna Doone). :-)
It's all television's fault.. :-) Accents are becoming flattened -
it's so bad that one can return to the town of one's birth (Wednesbury
in the heart of the "black country") and actually hear persons whom
one can understand.. :-)
--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| Robert Wagner 2004-09-03, 8:55 am |
| On Thu, 2 Sep 2004 17:46:49 -0500, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>Do add to Chuck's comment, there is a common "misconception" that the CANCEL
>statement *must* free storage. Not only does the Standard not require this,
>there are a number of implementations that don't do it. The only thing that the
>CANCEL statement is required to do is to insure that the next time the CANCELed
>program is called, it is in initial - not last-used - state.
In the days of memory-starved machines, every system I worked on did
free memory.
They don't free memory today because of the way multi-tasking
operating systems manage shared resources (dll and so). Suppose there
are three tasks -- A, B and C -- calling program P. The operating
system has but one copy of P's procedure division in memory, and three
instances of its data division. When A says it's finished with P, the
operating system could reasonably free one data division but not the
procedure division. It still has two users. The procedure division
shouldn't be freed until its User Count goes to zero.
| |
| Robert Wagner 2004-09-03, 8:55 am |
| On Thu, 2 Sep 2004 14:43:29 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:4s2fj0dubd28r06p92bcvnrmg9jsurin6b@
4ax.com...
>
>
>I actually agree with Robert here in at least part of this: I think
>abbreviated combined relation conditions in particular are a delusion and a
>snare. The big problem with them is that it is at first glance
>*reasonable* but ultimately *erroneous* that abbreviation implies some sort
>of association not otherwise implied by the precedence rules (or the
>parentheses).
That's why I suggested not allowing ACRC to travel through parentheses
-- so people wouldn't make that mistake, become frustrated and ban
ACRC.
> COBOL's arithmetic precedence rules don't bother me that much; they seem to
>match Fortran, ALGOL, Pascal and PL/I at least, so someone coming from those
>languages shouldn't be terribly .
The reason for AND/OR precedence is not obvious to people who don't
think in logical algebra. They have enough trouble with logic;
precedence just adds to the confusion.
The reason is that AND is logical multiplication, OR is logical
addition.
>
>
>Many implementors do this; it's not clear to me that it's the *standard's*
>job to tell the *implementor* how to keep the *programmer* from shooting
>himself in the foot in every case. I believe the standard specifies a
>mechanism for flagging *standards violations*, but not one for *advisories*
>along the lines of "Are you sure that's what you meant?" (or even for the
>method of presentation of syntax *errors*, except that object code shouldn't
>be produced when they occur).
If the objective is a language that's robust, portable and
predictable, seems to me that Standard Warnings would help Cobol
toward that ideal.
Ok, make it a fatal error. They're telling the compiler to do
something illogical -- generate code that will never be executed.
While we're on the topic, this should be an error also:
05 foo pic 9(4).
perform varying foo from 1 by 1 until foo > 10000
The condition will always be false.
> It may actually be a useful technique for
>*incorporating* prototype code into *production* programs before testing is
>complete; I've found it useful to "stub" large blocks of code that way -- or
>even with "IF <enabling-condition> AND FALSE THEN ..." , where all I have to
>do is delete the "AND FALSE" to open up the new logic, in my time.
I do that too. Make an exception for TRUE and FALSE.
| |
| Robert Wagner 2004-09-03, 3:55 pm |
| On Fri, 03 Sep 2004 01:55:28 GMT, Warren Simmons
<wsimmons5@optonline.net> wrote:
>Robert Wagner wrote:
>Come from.....
>
>Perform did a branch and return. Doesn't that count?
It's true that the return address could be fished out of the stack,
but it only counts IN COBOL if the compiler-generated code (or
runtime) does it for you. The return address would then have to be
related to a line number and/or paragraph name, and other means used
to figure out which file threw the error.
The new EC- values Bill Klein posted appear to be doing just that.
When we get the new feature(s), declaratives will have reasonable
support FROM COBOL. Note, however, they require debugging information.
That could be a problem in older shops, where rules prohibit debugging
information in production.
| |
| Lueko Willms 2004-09-03, 3:55 pm |
| .. Am 03.09.04
schrieb robert@wagner.net.yourmammaharvests (Robert Wagner)
auf /COMP/LANG/COBOL
in kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com
ueber Re: If you were inventing CoBOL...
RW> While we're on the topic, this should be an error also:
RW>
RW> 05 foo pic 9(4).
RW> perform varying foo from 1 by 1 until foo > 10000
RW>
RW> The condition will always be false.
A similar thing happened on the first flight of Ariane 5.
That was a very costly programming error, although in all
probability not using COBOL.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
"Das Volk, das ein anderes Volk unterjocht, schmiedet seine eigenen
Ketten." - Karl Marx (1. Januar 1870)
| |
| Howard Brazee 2004-09-03, 3:55 pm |
|
On 2-Sep-2004, "JerryMouse" <nospam@bisusa.com> wrote:
>
> How about the 2000 election (and 2004 in some places)?
Punched cards offer a sold, auditable trace that is very hard to hack. I'm
against changing it to touch-screen and the like.
| |
| Howard Brazee 2004-09-03, 3:55 pm |
|
On 2-Sep-2004, l.willms@jpberlin.de (Lueko Willms) wrote:
> Besides that in my style, I always divided up my programs in
> SECTIONs (having one single paragraph called ANFANG, i.e. German for
> "BEGIN"), you can't do without SECTIONs when you are using
> DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.
Declaratives are something that could have been designed differently.
And certainly, if SORT can remove the requirement that it runs sections, so
could declaratives.
| |
| Chuck Stevens 2004-09-03, 3:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@
4ax.com...
> Segments are a case of procedural modularity.
OK, but so are called programs.
> Only procedural code is pageable.
*WHAT?* Please support the universality of this statement!
> With dynamic calls, working-storage belonging to the
> 'segment' is pageable as well.
Working-storage belonging to the called program is "pageable" in exactly the
same way as any other storage in COBOL or any other language. The Burroughs
B5000 was "paging" working-storage over 40 years ago, and its descendants do
so today.
> That separates the main procedure division from its data division. If
> programs were nested say 2 layers deep, program 3 would similarly
> separate program 2 into two pieces.
Just as has been done in ALGOL and Pascal and related languages, and as was
done a very long time before COBOL decided it had a better idea!
> People would be editing the main program's procedure division, hit
> Page Up to see its data division, and be looking at an unrelated
> program's data division.
That sounds like a problem for the editor, not a problem for the compiler.
> They would say nested programs are too confusing.
Yeah, that's why nobody ever wrote anything in ALGOL or Pascal.
> I like small programs having 'locality of reference' for ease of text
> editing. If one is accustomed to working on very large programs,
> that's not a concern .. there are always two editor windows open.
I understand that; in fact, I think "nested programs" in COBOL are stolen
philosophically from "procedures" in ALGOL and Pascal; the big difference I
see is that "procedures" in those languages are always "INITIAL" in COBOL
terms. But aside from that I think there are more similarities than
differences.
> If you use prototypes, it is controlled by the callee.
OK; I was actually thinking in terms of '85 COBOL semantics and code
compatible with it. I've never understood the particular utility of calling
a program one time with a parameter BY REFERENCE and the next time BY VALUE,
particularly because in our environment what other languages term "by value"
(only allowed for single- or double-word values) is significantly more
efficient than "by reference" or "by name"; the reverse is usually true in
our COBOL85, so the behavior in that language is counterintuitive for the
seasoned MCP user.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-03, 3:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@
4ax.com...
> If the objective is a language that's robust, portable and
> predictable, seems to me that Standard Warnings would help Cobol
> toward that ideal.
Then the presence of Standard Warnings, and a list of things every
implementor should be required to warn about, is the underlying idea. I'd
suggest you write a proposal that it be added to the candidates list,
together with a *list* of warnings you think ought to be included.
> Ok, make it a fatal error. They're telling the compiler to do
> something illogical -- generate code that will never be executed.
As I mentioned before, I oppose the idea of having the standard *prevent*
the "stubbing" of code.
> While we're on the topic, this should be an error also:
>
> 05 foo pic 9(4).
> perform varying foo from 1 by 1 until foo > 10000
>
I don't think *standard* COBOL should differentiate between the above and
05 foo pic 9(4)
05 blivet pic 9.
05 whoosis pic 9.
05 whatsis pic 9(5).
move 1 to blivet whoosis move 10000 to whatsis.
perform varying foo from blivet by whoosis until foo > whatsis.
Nor do I believe the *standard* should encourage such a differentiation.
> The condition will always be false.
Only because all the arguments are literals. The condition might always be
false anyway, even if the PERFORM control items are variables.
> I do that too. Make an exception for TRUE and FALSE.
They don't currently exist in the conditional-expression syntax to begin
with. Proposing such -- e.g. that the keywords TRUE or FALSE may be used
anywhere a <boolean-expression> may be used -- would certainly be another
reasonable addition to the "candidates list". .
-Chuck Stevens
| |
| Chuck Stevens 2004-09-03, 3:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:cha1dr$q67$1@peabody.colorado.edu...
> And certainly, if SORT can remove the requirement that it runs sections,
so
> could declaratives.
Take it from me, the removal of that requirement caused some implementors
quite a few headaches! Things were much simpler when you could determine at
*compile time* whether a RELEASE or RETURN statement was within the confines
of a SORT input or output procedure!
-Chuck Stevens
| |
| Chuck Stevens 2004-09-03, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:btjgj09sa8iedc4m2gnjns4st9rfe8m4do@
4ax.com...
> "It" is the value representing a condition. Indirection means
> 'referred to by name rather than literal value'.
And you can't do this with "CONSTANT" today?
If there are already fourteen approved ways to skin a cat, it's not clear
that we need to standardize a fifteenth!
> Another idea. Suppose the initial value will be set with INITIALIZE
> (with option to initialize fillers). It would be nice if we could
> write:
>
> 05 pic 9 value INITIAL.
> 88 end-of-file value 1 false INITIAL.
>
> With that, if someone changes the pic to X, the false value will
> automatically change from zero to space.
Or a sixteenth!
If the user changes an item from PIC 9 to PIC X, I'd think the user would
want to, and should, examine every reference to it to make sure that the
change didn't break anything. I believe standardizing "The value is ...
well ... whatever" would not be met with much enthusiasm.
And it took the author of the (now-approved) proposal for Structured
Constants in the 2008 draft (see
http://www.cobolportal.com/j4/files/04-0056.doc ) a fair amount of effort to
convince J4 that the content of a Structured Constant should be, at the
beginning of execution, as if a statement of the form "INITIALIZE ... WITH
FILLER ALL TO VALUE" had been executed against it before execution begins.
The idea of having the effects of INITIALIZE "bleed over" into compile-time
was of some concern, and I think doing that in this case would be a hard
sell.
-Chuck Stevens
| |
| Robert Wagner 2004-09-03, 3:55 pm |
| On Fri, 3 Sep 2004 08:41:43 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@
4ax.com...
>
>OK, but so are called programs.
>
>
>*WHAT?* Please support the universality of this statement!
I didn't express the point clearly enough. Second try:
If the program manages memory with priority numbers on segments, the
size of shared memory is the size of procedural code.
If the program manages memory with CALL/CANCEL, the size of shared
memory is larger because the size of some working-storage can be freed
as well.
>
>Working-storage belonging to the called program is "pageable" in exactly the
>same way as any other storage in COBOL or any other language. The Burroughs
>B5000 was "paging" working-storage over 40 years ago, and its descendants do
>so today.
I should have said freeable rather than pageable. The machines we're
discussing didn't have virtual memory. If they had, there would have
been no need for the programmer to manage memory.
>
>Just as has been done in ALGOL and Pascal and related languages, and as was
>done a very long time before COBOL decided it had a better idea!
C is the same. The reason has nothing to do with structure or
philosophy, it's more mundane. The compiler needs to type-check
parameters on the call. There are three ways that could be done:
a. Two passes in the compiler front-end.
Too slow.
b. Prototypes at the top.
Too verbose.
c. Require the callee to be seen before the caller.
The solution they used.
Because Cobol doesn't require type-checking, the better idea was to
put the called program where it logically belongs.
>
>I understand that; in fact, I think "nested programs" in COBOL are stolen
>philosophically from "procedures" in ALGOL and Pascal; the big difference I
>see is that "procedures" in those languages are always "INITIAL" in COBOL
>terms. But aside from that I think there are more similarities than
>differences.
A major difference is data visability. Pascal makes everything in the
equivalent of working-storage global. Parameters? We don't got to pass
no stiinking parameters! Just reach into the pot and help yourself.
Cobol has been criticized for having 'an ocean of global data' since
the beginning. That's WHY nested programs were created.
As for inheritance, I'd say ALGOL got the idea from Fortran's 'blank
common'.
> I've never understood the particular utility of calling
>a program one time with a parameter BY REFERENCE and the next time BY VALUE,
That's not utility, that's an error.
Some day, the solution will be typecasting via introspection. The
compiler will p into the callee to see what it wants, then cast the
call to match.
>particularly because in our environment what other languages term "by value"
>(only allowed for single- or double-word values) is significantly more
>efficient than "by reference" or "by name"; the reverse is usually true in
>our COBOL85, so the behavior in that language is counterintuitive for the
>seasoned MCP user.
To a seasoned Intel assembly programmer, it seems intuitive that a
single instruction, memory-to-memory move is the fastest way to copy a
string. It used to be. Now it's faster to tediously load and store a
word at a time.
We have compilers between us and the machine to automate optimizations
like this. In case you cited, if all targets were nested, a smart
compiler could disregard what the programmer wrote and optimize the
parameter type automatically. If targets were external, a 'full make'
would be required to optimize.
I don't think programmers should have to hold the machine's hand like
we used to. Stuff like this should be automated.
| |
| Robert Wagner 2004-09-03, 3:55 pm |
| On Fri, 3 Sep 2004 15:03:42 GMT, "Howard Brazee" <howard@brazee.net>
wrote:
>On 2-Sep-2004, "JerryMouse" <nospam@bisusa.com> wrote:
>
>
>Punched cards offer a sold, auditable trace that is very hard to hack. I'm
>against changing it to touch-screen and the like.
First 'Hanging Chad' Case Heads to Trial
Federal suit ss to decertify punch-card ballots, upgrade system
Dee McAree
The National Law Journal
07-26-2004
Four years ago, the "hanging chad" became part of the country's
lexicon during the Florida recount in the Bush versus Gore
presidential election.
This w, the first case to litigate the constitutionality of
punch-card voting is scheduled to commence in federal court in Ohio.
[snip]
The lawsuit contends that Ohio voting system inconsistencies violate
the equal protection clause of the 14th Amendment and the Voting
Rights Act of 1965. The suit ss a court order requiring the Ohio
secretary of state to decertify the punch-card ballot. They want to
invalidate the system to put pressure on state officials to come up
with a voting method with an equal statistical error rate for all
voters.
[snip]
Of the 88 counties in Ohio, about 69 use punch-card voting, Saphire
said. Some of the more affluent counties have upgraded to newer
touch-screen technology that has a lower error rate. Therefore,
minorities who live in the less affluent neighborhoods are more likely
to have their votes rejected, allege the plaintiffs' lawyers.
The ACLU's research of the last presidential election found that the
rejected ballots in an Ohio county that used punch cards amounted to
six times higher than a county that used touch-screen technology. A
total of 93,000 Ohio voters had their votes rejected. In some minority
neighborhoods near Akron, the rejected rate reached 10 percent to 15
percent.
[snip]
The plaintiffs' lawyers say the critical problem with punch-card
voting is that it does not allow a user to check his vote. There are
no safeguards to alert a voter who elects too few candidates or elects
too many.
http://www.law.com/jsp/article.jsp?id=1090180166667
| |
| James J. Gavan 2004-09-03, 3:55 pm |
| Jeff York wrote:
>Blimey! You must be even older than me!
>
That's for sure. Some here already know - but now I'm going to give it
to you, but you have to go googling if interested..
The song :-
You must remember this,
A kiss is just a kiss,
A sigh is just a sigh........
Was the rage and popularized in the movie, (film to you), 'Casablanca'
starring Bogey and the then young and pretty Ingrid Bergman. However
that song was written the year I was born - go for it :-)
Jimmy
> I first programmed in
>machine code and Fortran at uni, then my first "proper job" was at
>Evode in Stafford, initially on a Univac 1004 (A plugged-program
>machine!) followed by a "real computer" - an ICL 1901A which used
>COBOL. The Univac was card input, card and print output. The program
>board was about 2 feet square and fully-wired weighed about 40 pounds
>so it took a degree of physical strength as it loaded at chest-height
>and you had to be delicate otherwise it would knock some of the plugs
>loose. It was a hanging-offence should anyone actually drop one!
>
><>
>
>
>
>
>T-t-terribly sorry old chap! :-) Oy thort loyke iffn oy daint ger
>backter summat loyke ingliish, no bugger ud understaand me. :-)
>
>
>
>
>It's all television's fault.. :-) Accents are becoming flattened -
>it's so bad that one can return to the town of one's birth (Wednesbury
>in the heart of the "black country") and actually hear persons whom
>one can understand.. :-)
>
>
>
| |
| S Comstock 2004-09-03, 3:55 pm |
| Peter Lacey writes ...
[snip]
>I would not have some verbs, especially
>EVALUATE (hey! you did say "if YOU were inventing Cobol"! And despite
>study, explanations and examples, I've yet to come across a case where
>an evaluate couldn't be done more clearly and usually simpler with IF's
>and/or CASE statments).
Excuse me? EVALUATE _ IS_ the COBOL CASE statement.
Kind regards,
-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
| |
| Howard Brazee 2004-09-03, 3:55 pm |
|
On 3-Sep-2004, scomstock@aol.com (S Comstock) wrote:
>
> Excuse me? EVALUATE _ IS_ the COBOL CASE statement.
I've seen other languages do case statements that were clearer and easier to
use.
I mean:
Evaluate TRUE Also TRUE
| |
| Chuck Stevens 2004-09-03, 8:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:p68hj0p9f52si1kpsbs870up126ek6lfhh@
4ax.com...
> On Fri, 3 Sep 2004 08:41:43 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> I didn't express the point clearly enough. Second try:
>
> If the program manages memory with priority numbers on segments, the
> size of shared memory is the size of procedural code.
Ummm ... no .... that is not a Universal Truth ...
Going by ANSI X3.23-1974 syntax, where the "Segmentation Module" is not yet
marked as obsolete:
I've heard of *segment numbers*, and I've heard of the segment-limit clause
which may impact the way SECTIONs with various segment-numbers are handled,
with respect to how they're treated. For example, "The fixed portion [of
the procedural code for the program] is that part of the program which is
*logically treated as if it were always in memory*" [emphasis added].
The implementor is *not* obligated to ensure that all portions of the "fixed
portion" is indeed unconditionally and always in memory during the execution
of the program, only that the actions *of the program* are indistinguishable
from that behavior.
The implementor is *not* obligated to ensure that two SECTIONs with the same
"segment number" are phyically or logically associated with one another in
memory, only that the actions of the program are indistinguishable from that
which would obtain with such a physical or logical association.
Moreover, there is no requirement on the part of an implementor to ensure
that two copies of the same program share *any* part of their memory, much
less a specific portion of it. Some implementors choose to do so -- on
Unisys MCP systems a single instance of the object code file on disk is
"managed" by the operating system for all executors of it, and "manages" the
determination of which code segments are in memory based on how they are
used -- the ALTER behavior impacted by section-numbers is managed in the
individual "data spaces".
The *program* is not managing the memory, as I see it; the *operating
environment* is managing the memory using the segment-number of the various
SECTIONs and the SEGMENT-LIMIT clause as *guidelines* in that process.
It is precisely because *all* of this is really an implementation detail,
and because the *specifics* of fixed-versus-overlayable in various
implementations are really none of the standard committee's business, that
led to the Segmentation Module being marked as obsolete in 1985 and to its
elimination from the standard in 2002. The SECTION header remains, but
ALTER, segment-numbers and the SEGMENT-LIMIT clause are gone.
> If the program manages memory with CALL/CANCEL, the size of shared
> memory is larger because the size of some working-storage can be freed
> as well.
It is not the program that is managing the memory in the first place, it is
the operating environment. IN an environment in which program initiation
and termination are costly and in which the operating environment does a
really good job of memory management in the first place, CALL/CANCEL may be
a *much* less efficient approach than what you propose Who says all of
WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
resident for the life of the program?
> I should have said freeable rather than pageable. The machines we're
> discussing didn't have virtual memory. If they had, there would have
> been no need for the programmer to manage memory.
What machines were *we* discussing? As far as I'm concerned, *we* were
discussing what COBOL *ought to do* and what features COBOL *ought to
provide* and why.
> C is the same. The reason has nothing to do with structure or
> philosophy, it's more mundane. The compiler needs to type-check
> parameters on the call. There are three ways that could be done:
>
> a. Two passes in the compiler front-end.
> Too slow.
I know of a two-pass COBOL compiler that is *triple* the speed of its
one-pass counterpart. Show me how slow a two-pass compiler always is
compared to a one-pass compiler. I've also known *six-pass* COBOL compilers
that weren't speed demons *during compilation*, but that generated
blindingly-fast object code. And what's *the* compiler front-end?
> b. Prototypes at the top.
> Too verbose.
also requires prototypes. This is similar to ALGOL's FORWARD I think.
> c. Require the callee to be seen before the caller.
> The solution they used.
The solution ALGOL, Pascal, PL/I, etc., used, which I personally prefer.
> Because Cobol doesn't require type-checking, the better idea was to
> put the called program where it logically belongs.
It's not clear to me that the "because" is true, nor is it clear to me that
"logically belongs" has been established.
> A major difference is data visability. Pascal makes everything in the
> equivalent of working-storage global.
Sort of, and Pascal is very much like its ancestor in this respect. The
philosophy there is that data *at a given level* isn't visible at a higher
level in the program, but you can see the data for all higher levels of the
program from wherever you are. I agree that COBOL's explicit declaration of
what data in the parent level you can and can't see at the child level can
be seen as an improvement.
> Parameters? We don't got to pass
> no stiinking parameters! Just reach into the pot and help yourself.
You don't have to pass "shared data" in COBOL as parameters, you can always
make it global and thus access by anyone beneath is welcome if that's what
you want.
> Cobol has been criticized for having 'an ocean of global data' since
> the beginning. That's WHY nested programs were created.
Yes, but I'd say the "global" issue is a refinement on that. Nested
programs allows the data that is accessed or used only by a given set of
logic to be associated with that logic and thus removed from the "outer
block". And if you're *really* modularizing, how much "local" data does
the "outer block" of a COBOL program in which all its real work is done in
"nested" programs really need?
> As for inheritance, I'd say ALGOL got the idea from Fortran's 'blank
> common'.
Could be, but I think the ALGOL approach is rather more powerful and
sophisticated.
VALUE,[color=darkred]
>
> That's not utility, that's an error.
No, it's *explicitly* allowed by COBOL, and I believe the justification is
that one time you might *not* want to allow the callee to modify the data,
but the next time you *might*, and the standards folks didn't want to
preclude people from writing programs that did that. I wasn't there when
this decision was made, and had I been I'd almost certainly have argued
*strenuously* against it, but I have heard hints that at least one
implementor thought *copying* the data should be obligatory for BY VALUE,
and that's the way it is.
> Some day, the solution will be typecasting via introspection. The
> compiler will p into the callee to see what it wants, then cast the
> call to match.
Not sure what you mean by this, but I think having the compiler do "Well, I
know what you *wrote*, but I've decided what you really *meant* was ..." is
a REALLY bad idea.
> To a seasoned Intel assembly programmer, it seems intuitive that a
> single instruction, memory-to-memory move is the fastest way to copy a
> string. It used to be. Now it's faster to tediously load and store a
> word at a time.
That's actually one of the big differences: COBOL allows just about
anything to be passed BY VALUE; the procedural languages didn't.
> We have compilers between us and the machine to automate optimizations
> like this. In case you cited, if all targets were nested, a smart
> compiler could disregard what the programmer wrote
NO. Can't do that unless it can be guaran-dam-teed that the results are
*unconditionally identical*.
> and optimize the
> parameter type automatically. If targets were external, a 'full make'
> would be required to optimize.
> I don't think programmers should have to hold the machine's hand like
> we used to. Stuff like this should be automated.
Some of it can, some of it is. The *standard* specifies how it should
*behave*; it isn't the *standard*'s job to make sure the implementor does it
efficiently, it's the *implementation's*.
-Chuck Stevens
| |
| Robert Wagner 2004-09-03, 8:55 pm |
|
On Fri, 3 Sep 2004 08:54:15 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@
4ax.com...
>
>
>
>Then the presence of Standard Warnings, and a list of things every
>implementor should be required to warn about, is the underlying idea. I'd
>suggest you write a proposal that it be added to the candidates list,
>together with a *list* of warnings you think ought to be included.
How to compile such a list:
... Start with messages issued by a 2002 compiler
Do-able
... Delete messages related to non-standard extensions
Requires expert knowledge of 2002 & 2008 standards
I'm not that expert
... Delete messages not important enough to make the cut
Do-able
... Add the one about condition always true/false
... Write rules about how to determine same
All literals is easy. How about a variable that never changes?
Never change must distinguish between call by reference/value.
If the only call is to a nested program that doesn't change it
and doesn't call outside by reference, it didn't change.
Watch out for pass via GLOBAL.
Watch out for EXTERNAL.
Watch out for changes via REDEFINES and group names.
Deal with ESQL references. How?
Finally, realize the warning will be issued only when the compiler is
in standard-compliant mode. Has anyone ever used that, outside the
lab? Maybe some government project .. once .. a long time ago.
On second thought, it's not worth the effort.
>
>Only because all the arguments are literals. The condition might always be
>false anyway, even if the PERFORM control items are variables.
See above.
>
>They don't currently exist in the conditional-expression syntax to begin
>with. Proposing such -- e.g. that the keywords TRUE or FALSE may be used
>anywhere a <boolean-expression> may be used -- would certainly be another
>reasonable addition to the "candidates list". .
I ASSumed it was supported for two reasons:
... I use them routinely in Micro Focus.
... Logic. Why would the standard create logical literals and then not
permit them in conditional expressions? That's illogical.
I refuse to write PERFORM UNTIL FALSE. It is common usage in other
languages as DO FOREVER and WHILE TRUE. It implies on an explicit exit
will be issued. Premature exits are for exceptions. The normal exit
condition should be expressible in loop control.
| |
| Richard 2004-09-03, 8:55 pm |
| "Howard Brazee" <howard@brazee.net> wrote
>
> Still, if CoBOL was invented that the only way to get to a paragraph was to
> perform it, coders back then wouldn't have had any problem writing code.
They simply would have ignored the language as being 'broken'. One
reason why Cobol succeeded was that programmers could move most of
their existing code from commercial languages to it. And all their
existing techniques.
There is no doubt that ALTER is a vastly faster mechanism than any 'IF
first-flag' technique, and this is why ALTER was used and required to
be in the language.
It was just earlier in the same decade that mercury tube was a common
memory. You should read 'Early British Computers' to get an
appreciation of the programming techniques used at that time just to
get the program running fast enough.
>
> They wouldn't have needed such a concept so much with that change.
Geez, Robert, you have such perfect hindsight.
| |
| Warren Simmons 2004-09-04, 3:55 am |
| Personally, I favored WHEN instead of IF.
Warren Simmons
S Comstock wrote:
> Peter Lacey writes ...
>
> [snip]
>
>
>
>
> Excuse me? EVALUATE _ IS_ the COBOL CASE statement.
>
> Kind regards,
>
>
> -Steve Comstock
> 800-993-9716
> 303-393-8716
> www.trainersfriend.com
> email: steve@trainersfriend.com
> 256-B S. Monaco Parkway
> Denver, CO 80224
> USA
| |
| Robert Wagner 2004-09-04, 3:55 am |
| On 03 Sep 2004 18:55:36 GMT, scomstock@aol.com (S Comstock) wrote:
>Peter Lacey writes ...
>
>[snip]
>
>
>Excuse me? EVALUATE _ IS_ the COBOL CASE statement.
If I'd made that mistake, hectoring would have gone on for two ws.
| |
| Robert Wagner 2004-09-04, 3:55 am |
| On Fri, 03 Sep 2004 23:56:24 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>Just to "add" to this thread, I think it would be nice if some future Standard
>actually *required* the compiler to produce a listing (which it doesn't and
>never has). It would also be nice if it gave some clue how such a listing
>should handle COPY REPLACING/REPLACE statements - which are currently handled
>very differently by various compilers. (Some show before the replacement, some
>after)
As an alternative, the standard might specify that error messages
refer to _original_ line numbers, before COPY. Most compilers already
do this.
I haven't looked at a listing in 20 years. I edit the source and go to
the line number indicated. If there is a pre-processor involved, I
edit its output, which is input to the compiler.
| |
| James J. Gavan 2004-09-04, 3:55 am |
| Robert Wagner wrote:
>On 03 Sep 2004 18:55:36 GMT, scomstock@aol.com (S Comstock) wrote:
>
>
>
>
>If I'd made that mistake, hectoring would have gone on for two ws.
>
>
Ok - well not hectoring. Just check out your "End-evaluate is not
required" in your other message. I'm pretty certain N/E, (also SE ?),
will give a compile 'non matched pair, i.e. the Evaluate and
End-Evaluate". Could be wrong, perhaps it only occurs with nested
Evaluates. Think on it - the compiler can't check for an end-if because
you might have substituted a period, i.e. 'old style', but I do know for
certain I have had errors with a non-matching "'End" - so that suggests
'Evaluate'.
Jimmy. .
| |
| Robert Wagner 2004-09-04, 3:55 am |
| On Fri, 3 Sep 2004 15:06:49 GMT, "Howard Brazee" <howard@brazee.net>
wrote:
>On 2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
[color=darkred]
>Still, if CoBOL was invented that the only way to get to a paragraph was to
>perform it, coders back then wouldn't have had any problem writing code.
>
>
>They wouldn't have needed such a concept so much with that change.
I agree with Chuck on this. In the early '60s, with a background of
1401 assembly language programming, I thought it would be impossible
to write a Cobol program without GO TO. Had I been on a standards
committee, I would have defended GO TO.
In retrospect, it is obvious I was wrong. All the founders were. In
their defense, they were 'creatures of their time'. They did the best
they could with assembly language antecedents and very little
experience with high-level languages.
Structured programming was discovered in the late '60s and promoted in
the early '70s by people such as Yourdon and Michael Jackson (the
other one). I wish we'd grocked it earlier, but we didn't.
| |
| James J. Gavan 2004-09-04, 3:55 am |
| Robert Wagner wrote:
>On Fri, 3 Sep 2004 09:26:25 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>
>
>
>Hmmm. CONSTANT was new in 2002, but Micro Focus had nearly the same as
>level 78. The HUGECALC demo I posted here had 50-100 inline references
>to 'length of huge / 2'. The code would read much more cleanly if I'd
>used a 78 to equate 'midpoint' to that expression. I apologized for
>the verbosity, saying I didn't know a way around it.
>
>Why didn't anyone point out 78/CONSTANT?
>
>
>
>
>You know what they say about people who refer to themselves in the
>third person. :)
>
>To me, a structured constant is a typedef with values. It also looks
>like an OO constructor. It says (to the compiler) construct one of
>these things and initialize it like this.
>
>A simpler solution would have been TYPEDEF INITIALIZED.
>
>
Well let me give you a little background on this one because I was *very
interested*. I'm not sure Chuck knows the full history, (I might have
told him), but he was the one who did cartwheels trying to resolve this.
We had a discussion group going at Thane's (Hubbell) group
softwaresimple.com discussing COBOL and OO COBOL - tended to majorly be
the latter. Artur Reimann the then representative for Fujitsu at J4 was
taken seriously ill just before emplaning for the meeting at Newbury in
May/June 2000. I don't know specifics but he had to opt out on health
grounds. Thane being a Fujitsu user was probably asked to represent
them. Fresh face, some bright new ideas he picked up on the OO method
syntax. At that time, say around mid to late 2000, a method looked very
much like a 'mini' program and certainly in Micro Focus had
Working-Storage.
So Thane initially picked up on this aspect that a 'min-program' would
take a reference to a COBOL file. It completely blew the concept of
"new" creating a separate instance, if you had files defined in methods.
I can't actually recall but a method "mini program" may have also have
allowed Declaratives. So he proposed take away that file feature in a
method - quite right ! In the process he also said take away
Working-Storage - after all , we had Local-Storage.
Well J4 sure likes to deliberate - but WOOSH ! - this one passed through
their portals before you had a chance to count up to ten. Even if not
actually into OO t | | |