Home > Archive > Cobol > June 2005 > END-IF
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]
|
|
|
| I'm new to Cobol. I would like to know if it is ansi compliant don't put
the period after an END-IF. For example wich of the two following snip
code are more standard.
1)
IF O = "+" THEN
COMPUTE C=A+B
END-IF
2)
IF O = "+" THEN
COMPUTE C=A+B
END-IF.
Thanks, G.
| |
| Pete Dashwood 2005-06-08, 8:55 am |
|
"GLari" <turbolenceATgmailDOTcom> wrote in message
news:42a6ad66$1_1@news.bluewin.ch...
> I'm new to Cobol. I would like to know if it is ansi compliant don't put
> the period after an END-IF. For example wich of the two following snip
> code are more standard.
>
> 1)
> IF O = "+" THEN
> COMPUTE C=A+B
> END-IF
>
> 2)
> IF O = "+" THEN
> COMPUTE C=A+B
> END-IF.
>
It is really a matter of opinion.
Mine is as follows:
"Don't mix coding styles. The days of full stops/periods as part of COBOL
logic are gone. They caused endless heartbreak , wailing, and gnashing of
teeth, particularly on barrel printers which did not always print them
clearly. We have scope delimiters; they were added for a purpose, by people
who understood the need for them. Use them, and relegate the full
stop/period to it's syntactical job of delineating the end of a paragraph
or section. (preceding a procedure-name)."
Number 1 gets my vote (at least as far as full stops/periods go...I have
some other reservations about it which I won't go into here...)
Pete.
| |
|
| Xref: newsfeed-west.nntpserver.com comp.lang.cobol:114302
> "Don't mix coding styles. The days of full stops/periods as part of COBOL
> logic are gone. They caused endless heartbreak , wailing, and gnashing of
> teeth, particularly on barrel printers which did not always print them
> clearly. We have scope delimiters; they were added for a purpose, by people
> who understood the need for them. Use them, and relegate the full
> stop/period to it's syntactical job of delineating the end of a paragraph
> or section. (preceding a procedure-name)."
>
So if I understand clearly, I should avoid this:
IF O = "+"
PERFORM COMPUTE-DISPLAY-ADD.
IF O = "*"
PERFORM COMPUTE-DISPLAY-MUL.
Sorry, but I don't understand why.
G.
| |
| Pete Dashwood 2005-06-08, 8:55 am |
|
"GLari" <turbolenceATgmailDOTcom> wrote in message
news:42a6b6bc_2@news.bluewin.ch...
COBOL[color=darkred]
of[color=darkred]
people[color=darkred]
paragraph[color=darkred]
>
> So if I understand clearly, I should avoid this:
>
> IF O = "+"
> PERFORM COMPUTE-DISPLAY-ADD.
> IF O = "*"
> PERFORM COMPUTE-DISPLAY-MUL.
>
> Sorry, but I don't understand why.
> G.
>
The reasons are long, involved, historic, and arguable.
If you WANT to code that way, do so. It is a choice.
Here's how it would be done with scope delimiters...
IF O = "+"
PERFORM COMPUTE-DISPLAY-ADD
END-IF
IF O = "*"
PERFORM COMPUTE-DISPLAY-MUL
END-IF
.....more code here...
It is immediately obvious what the scope of each IF is. It is with the full
stop/periods, too, if you can see them.... I know it is hard to believe
this, but there are occasions when COBOL Programmers get dragged into work
in the middle of the night to fix something critical that has crashed. It
might not even be you... Make things as obvious as you can. Someone will
bless your name for it and the word will get round that you are a dab hand
at this COBOL code stuff...
Just for completion, here is how I would code it...(If I worked on your
site; it isn't really how I'd code it for my personal use...)
(I hope you have validated the input operands BEFORE doing this .... :-)
(Check out the COBOL 'class' test...it determines the 'class' (alphabetic,
alphanumeric, or numeric,) of a field). Also, try to use meaningful names
for data. Your procedure names are great, but 'O' is not really an adequate
dataname for an arithmetic operator... :-))
EVALUATE O
WHEN "+"
PERFORM COMPUTE-DISPLAY-ADD
WHEN "-"
PERFORM COMPUTE-DISPLAY-SUB
WHEN "/"
PERFORM COMPUTE-DISPLAY-DIV
WHEN "-"
PERFORM COMPUTE-DISPLAY-MUL
WHEN OTHER
PERFORM NOTIFY-INVALID-ARITHMETIC-OPERATOR
END-EVALUATE
Again, the scope delimiters (EVALUATE...END-EVALUATE) show very clearly what
the scope of the EVALUATE statement is.
We used full stops in the old days because we had no choice. Now we do have
a choice, and I, for one, don't use full stops to delineate logic.
But some people do. It isn't 'wrong'; it is a choice.
Pete.
| |
| Pete Dashwood 2005-06-08, 8:55 am |
| I realised, after sending, that the procedure name:
NOTIFY-INVALID-ARITHMETIC-OPERATOR
is more than 30 characters long and thus violates the original COBOL
standard. Some compilers will truncate it, others will accept it as written,
some others will flag it as an error.
Change it to whatever you like that is less than 31 characters. I suggest:
NOTIFY-INVALID-ARITH-OPERATOR
Pete.
TOP POST nothing new below.
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3gnv8dFdel05U1@individual.net...
>
> "GLari" <turbolenceATgmailDOTcom> wrote in message
> news:42a6b6bc_2@news.bluewin.ch...
> COBOL
> of
> people
> paragraph
> The reasons are long, involved, historic, and arguable.
>
> If you WANT to code that way, do so. It is a choice.
>
> Here's how it would be done with scope delimiters...
> IF O = "+"
> PERFORM COMPUTE-DISPLAY-ADD
> END-IF
> IF O = "*"
> PERFORM COMPUTE-DISPLAY-MUL
> END-IF
> ....more code here...
>
> It is immediately obvious what the scope of each IF is. It is with the
full
> stop/periods, too, if you can see them.... I know it is hard to believe
> this, but there are occasions when COBOL Programmers get dragged into work
> in the middle of the night to fix something critical that has crashed. It
> might not even be you... Make things as obvious as you can. Someone will
> bless your name for it and the word will get round that you are a dab hand
> at this COBOL code stuff...
>
> Just for completion, here is how I would code it...(If I worked on your
> site; it isn't really how I'd code it for my personal use...)
>
> (I hope you have validated the input operands BEFORE doing this .... :-)
> (Check out the COBOL 'class' test...it determines the 'class'
(alphabetic,
> alphanumeric, or numeric,) of a field). Also, try to use meaningful names
> for data. Your procedure names are great, but 'O' is not really an
adequate
> dataname for an arithmetic operator... :-))
>
> EVALUATE O
> WHEN "+"
> PERFORM COMPUTE-DISPLAY-ADD
> WHEN "-"
> PERFORM COMPUTE-DISPLAY-SUB
> WHEN "/"
> PERFORM COMPUTE-DISPLAY-DIV
> WHEN "-"
> PERFORM COMPUTE-DISPLAY-MUL
> WHEN OTHER
> PERFORM NOTIFY-INVALID-ARITHMETIC-OPERATOR
> END-EVALUATE
>
> Again, the scope delimiters (EVALUATE...END-EVALUATE) show very clearly
what
> the scope of the EVALUATE statement is.
>
> We used full stops in the old days because we had no choice. Now we do
have
> a choice, and I, for one, don't use full stops to delineate logic.
>
> But some people do. It isn't 'wrong'; it is a choice.
>
> Pete.
>
>
>
>
>
| |
|
| > Here's how it would be done with scope delimiters...
> IF O = "+"
> PERFORM COMPUTE-DISPLAY-ADD
> END-IF
> IF O = "*"
> PERFORM COMPUTE-DISPLAY-MUL
> END-IF
I don't understand why the period solution is more error prone. Isn't
the scope of each if limited to only _one statement_?
If the language would permit more statement inside the if scope I would
be agree to use a well visible keyword to mark where the scope end. But
if the scope is always one istruction I don't understand what is the
difference between the two ways.
> Just for completion, here is how I would code it...(If I worked on your
> site; it isn't really how I'd code it for my personal use...)
Thanks for your solution. Actually I'm trying to understand the "if"
keyword so my example is completely artificial but I expect some more
convenient construct (case of) to manage problem like this.
Anyway it is usefull to me see what I will meet in some days....
Thanks again, Gianmaria
| |
| docdwarf@panix.com 2005-06-08, 3:55 pm |
| In article <42a6ad66$1_1@news.bluewin.ch>,
GLari <turbolenceATgmailDOTcom> wrote:
>I'm new to Cobol. I would like to know if it is ansi compliant don't put
>the period after an END-IF.
That depends, I believe, on where in the paragraph the END-IF is located.
DD
| |
|
| > If the language would permit more statement inside the if scope I would
> be agree to use a well visible keyword to mark where the scope end. But
> if the scope is always one istruction I don't understand what is the
> difference between the two ways.
Sorry I understood. Cobol permits more statement in the if scope!!
Thank for the help.
P.S. Of course now is clear why use end-if.
| |
| docdwarf@panix.com 2005-06-08, 3:55 pm |
| In article <3gnqfaFdgmibU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
[snip]
>It is really a matter of opinion.
>
>Mine is as follows:
>
>"Don't mix coding styles. The days of full stops/periods as part of COBOL
>logic are gone.
Mr Dashwood, in that full stops/periods are, in my experience, to be found
in a fair number of running programs across a variety of installations
their days are nowhere near 'gone'... code that is old enough to rent a
car is not, from what I have seen, all too uncommon.
(note - major automobile rental agencies in the United States of America
are, frequently, loath to have as customers those who are under
twenty-five years old... and there weren't too many scope-delimiters in
COBOL a quarter-century back.)
[snip]
>We have scope delimiters; they were added for a purpose, by people
>who understood the need for them. Use them, and relegate the full
>stop/period to it's syntactical job of delineating the end of a paragraph
>or section. (preceding a procedure-name)."
Don't mix coding styles... but use scope-delimiters unconditionally, no
matter what the coding-style?
DD
| |
| docdwarf@panix.com 2005-06-08, 3:55 pm |
| In article <42a6ccc4$1_1@news.bluewin.ch>,
GLari <turbolenceATgmailDOTcom> wrote:
>
>I don't understand why the period solution is more error prone. Isn't
>the scope of each if limited to only _one statement_?
>
>If the language would permit more statement inside the if scope I would
>be agree to use a well visible keyword to mark where the scope end. But
>if the scope is always one istruction I don't understand what is the
>difference between the two ways.
I am not sure what you are asking here... but I believe it is valid to
code something along the lines of...
IF CURRENT-HOUR < 17
MOVE THUMB TO NOSE
PERFORM LOOK-BUSY THRU LB-EX
PERFORM WATCH-THE-CLOCK THRU WTC-EX
UNTIL IMPETUS-TO-LEAVE > BEARABLE
GO TO CHECK-THE-TIME.
.... and similarly valid to code ...
IF Current-Hour < 17
MOVE Thumb to Nose
PERFORM Look-Busy
PERFORM Watch-the-Clock
UNTIL Impetus-to-Leave > Bearable
PERFORM Check-the-Time
END-IF
.... each with multiple imperatives predicated upon a given conditional.
DD
| |
|
| > I am not sure what you are asking here... but I believe it is valid to
> code something along the lines of...
>
> IF CURRENT-HOUR < 17
> MOVE THUMB TO NOSE
> PERFORM LOOK-BUSY THRU LB-EX
> PERFORM WATCH-THE-CLOCK THRU WTC-EX
> UNTIL IMPETUS-TO-LEAVE > BEARABLE
> GO TO CHECK-THE-TIME.
Of course, I misunderstood. Thanks, G.
| |
| Michael Mattias 2005-06-08, 3:55 pm |
| "GLari" <turbolenceATgmailDOTcom> wrote in message
news:42a6b6bc_2@news.bluewin.ch...
> So if I understand clearly, I should avoid this:
>
> IF O = "+"
> PERFORM COMPUTE-DISPLAY-ADD.
> IF O = "*"
> PERFORM COMPUTE-DISPLAY-MUL.
>
> Sorry, but I don't understand why.
As has been pointed out, the 'all block no dinky little full stops one might
miss at 2:00 AM' style is a lot easier to understand FOR THE NEXT PERSON WHO
HAS TO WORK ON THE PROGRAM.
I use a three-part test to decide if software is "OK"
- Must work
- Must be relatively efficient in terms of both resource usage and exection
speed
- Must be maintainable
Personally, I place an extremely high value on #3: Must be maintainable.
(This probably comes from being on 'the other side of the desk' for ten+
years; that is, paying for maintenance and enhancements).
It's a lot easier to add another "IF .. END-IF" block or an additional
'WHEN' to an 'EVALUATE .. END-EVALUATE' than insert an ' ELSE.. IF ...
ELSE CONTINUE' when you don't have to worry about how the full stops
impact the 'flow' logic.
If you don't place a premium on maintainability, this doesn't matter a whit,
since "works" and "efficiently" aren't impacted significantly by the
difference in coding style.
Maybe it's a little more work 'up front' to use 'all block, no stop' style,
especially if you have worked in the 'straight down the page using stops'
style for a while, but I think it pays for itself the very first time you
need to maintain the software.
YMMV.
MCM
| |
| Joe Zitzelberger 2005-06-08, 3:55 pm |
| In article <42a6b6bc_2@news.bluewin.ch>,
GLari <turbolenceATgmailDOTcom> wrote:
>
> So if I understand clearly, I should avoid this:
>
> IF O = "+"
> PERFORM COMPUTE-DISPLAY-ADD.
> IF O = "*"
> PERFORM COMPUTE-DISPLAY-MUL.
>
> Sorry, but I don't understand why.
> G.
That would be wise to avoid.
The full-stop period as a scope delimiter is a "END-EVERYTHING"
statement. An nuclear scope delimiter as it were.
Far better to use the constructs available for the last several decades
and write:
If O = "+"
Perform Compute-Display-Add
End-If
If O = "*"
Perform compute-Display-Mul
End-If
I'm sure you will hear from those who will say something to the effect
of 'my grandpappy used full-stops, my pappy used full-stops, full-stops
were good enough for them, they are good enough for me'. Just know they
are stuck in an age of disco music and unstructured code. Quite
possibly they don't know any better.
| |
| Joe Zitzelberger 2005-06-08, 3:55 pm |
| In article <42a6ccc4$1_1@news.bluewin.ch>,
GLari <turbolenceATgmailDOTcom> wrote:
>
> I don't understand why the period solution is more error prone. Isn't
> the scope of each if limited to only _one statement_?
That is a common misconception. The END-* delimiters apply only to the
last statement of type '*' and the compiler will enforce this.
The '.' delimiter will apply to ALL scopes currently active. So you
could do something like this:
If condition-1
lots-of-stuff
more-stuff
several-hundered-lines
| |
| Pete Dashwood 2005-06-08, 8:55 pm |
|
<docdwarf@panix.com> wrote in message news:d86kts$pok$1@panix5.panix.com...
> In article <3gnqfaFdgmibU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> Mr Dashwood, in that full stops/periods are, in my experience, to be found
> in a fair number of running programs across a variety of installations
> their days are nowhere near 'gone'... code that is old enough to rent a
> car is not, from what I have seen, all too uncommon.
Well then, your opinion will differ from mine, won't it? That's the nice
thing about opinions. My experience also differs from yours. (Come to think
of it, maybe that's why I have a different opinion...?).
I don't doubt for one minute there are sites that are still running COBOL
code that was written prior to the release of scope delimiters, and I also
don't doubt there are some COBOL Programmers who are perpetuating this style
of code, but I don't know personally of any. Even if I did, it would not
change my opinion that their day is gone. I simply don't believe that the
majority of modern COBOL Programmers would do it. I don't know anyone who
codes in that way today. The people I know who write client server COBOL,
for the most part, use OO and would simply laugh at the suggestion that
coding styles from the 1960s are still viable. The few people I know who are
still working in mainframe COBOL long ago eschewed that style, in favour of
scope delimiters. That is my experience, and that is what my opinion is
based on.
But even if all that were NOT so, do you seriously think I would advise a
newcomer (or ANYBODY) to use that style?
paragraph[color=darkred]
>
> Don't mix coding styles... but use scope-delimiters unconditionally, no
> matter what the coding-style?
>
If you are maintaining code written in the old style you have two options:
1. Make your changes in the same style the program is written in.
2. Make your changes in scope delimited COBOL, which would mean mixing
styles.
There are arguments for and against both approaches.
I would use scope delimiters and accept that the styles were mixed. It is a
lesser evil than perpetuating an error prone style. Or then again, perhaps I
wouldn't...might decide that as it is such old COBOL there's no point in
breaking the mould and nothing to be gained by mixing the styles. Maybe the
answer would be to conform to the installation standards and then go and
have lunch woth a clear conscience...maybe look for a job doing something
else...
Fortunately, I no longer have to make these nail-biting, gut-wrenching
decisions, as I no longer maintain other people's code for a living.
As far as new development goes, my advice stands.
Pete.
| |
| docdwarf@panix.com 2005-06-08, 8:55 pm |
| In article <3goarsFdaf1tU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:d86kts$pok$1@panix5.panix.com...
>
>Well then, your opinion will differ from mine, won't it? That's the nice
>thing about opinions. My experience also differs from yours. (Come to think
>of it, maybe that's why I have a different opinion...?).
>
>I don't doubt for one minute there are sites that are still running COBOL
>code that was written prior to the release of scope delimiters, and I also
>don't doubt there are some COBOL Programmers who are perpetuating this style
>of code, but I don't know personally of any.
I am pleased, Mr Dashwood, that your doubt has been verified by my
experience.
>Even if I did, it would not
>change my opinion that their day is gone.
It strikes me as odd to say 'This construct's day is gone... and the fact
that many programs are being run on a daily basis which contain it is
evidence of that.'
Folks may not be coding it nowadays... but they are out there in code that
works.
>I simply don't believe that the
>majority of modern COBOL Programmers would do it. I don't know anyone who
>codes in that way today.
You also don't know of any sites that have such code... different
experiences, different conclusions, aye.
>The people I know who write client server COBOL,
>for the most part, use OO and would simply laugh at the suggestion that
>coding styles from the 1960s are still viable.
If 'viable' is used in the root sense of 'vis-', 'life', and if code that
executes daily is 'live code' - as opposed to 'dead code', which does not
get executed - then you know some people who would simply laugh at the
suggestion that something which still works and is used... still works and
is used.
>The few people I know who are
>still working in mainframe COBOL long ago eschewed that style, in favour of
>scope delimiters. That is my experience, and that is what my opinion is
>based on.
What a wonderful world it is, where experience can be expanded!
>
>But even if all that were NOT so, do you seriously think I would advise a
>newcomer (or ANYBODY) to use that style?
I barely know what *I* would advise someone to do, Mr Dashwood, let alone
anyone else... but to the best of my knowledge that style has not been
advocated by anyone in this forum.
>
>
>
>If you are maintaining code written in the old style you have two options:
>
>1. Make your changes in the same style the program is written in.
>2. Make your changes in scope delimited COBOL, which would mean mixing
>styles.
>
>There are arguments for and against both approaches.
That is what I thought, hence my confusion about the unequivocal 'don't
mix coding styles'.
>
>I would use scope delimiters and accept that the styles were mixed. It is a
>lesser evil than perpetuating an error prone style. Or then again, perhaps I
>wouldn't...might decide that as it is such old COBOL there's no point in
>breaking the mould and nothing to be gained by mixing the styles.
'I would... or perhaps I wouldn't' seems a moderately widespread
evaluation for many things, aye... Kantians aside, perhaps.
DD
| |
|
| >>I don't understand why the period solution is more error prone. Isn't
>
>
> That is a common misconception. The END-* delimiters apply only to the
> last statement of type '*' and the compiler will enforce this.
>
> The '.' delimiter will apply to ALL scopes currently active. So you
> could do something like this:
[example]
That's very very clear. Thanks a lot.
G.
| |
| Chuck Stevens 2005-06-08, 8:55 pm |
|
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-640046.08500308062005@ispnews.usenetserver.com...
> If O = "+"
> Perform Compute-Display-Add
> End-If
>
> If O = "*"
> Perform compute-Display-Mul
> End-If
If you (or your management) is into both belts and suspenders, and these two
IF statements aren't embedded in other statements, you could also put a
period after each END-IF to clarify that each of them is a *sentence* and
not just a *statement*. It's not *necessary*, but might be *useful* in some
environments.
-Chuck Stevens
| |
| Peter Lacey 2005-06-08, 8:55 pm |
| Pete Dashwood wrote:
<snip>
> Just for completion, here is how I would code it...(If I worked on your
> site; it isn't really how I'd code it for my personal use...)
>
<snip>
> EVALUATE O
> WHEN "+"
> PERFORM COMPUTE-DISPLAY-ADD
> WHEN "-"
> PERFORM COMPUTE-DISPLAY-SUB
> WHEN "/"
> PERFORM COMPUTE-DISPLAY-DIV
> WHEN "-"
> PERFORM COMPUTE-DISPLAY-MUL
> WHEN OTHER
> PERFORM NOTIFY-INVALID-ARITHMETIC-OPERATOR
> END-EVALUATE
>
> Again, the scope delimiters (EVALUATE...END-EVALUATE) show very clearly what
> the scope of the EVALUATE statement is.
>
Perhaps you could add a bit of explanation to this. While this code is
perfectly rational and easy to understand, I don't see what advantage is
conferred by the PERFORMS. Why not use the COMPUTEs there?
PL
| |
| Howard Brazee 2005-06-08, 8:55 pm |
|
On 8-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
> It is really a matter of opinion.
>
> Mine is as follows:
>
> "Don't mix coding styles. The days of full stops/periods as part of COBOL
> logic are gone. They caused endless heartbreak , wailing, and gnashing of
> teeth, particularly on barrel printers which did not always print them
> clearly. We have scope delimiters; they were added for a purpose, by people
> who understood the need for them. Use them, and relegate the full
> stop/period to it's syntactical job of delineating the end of a paragraph
> or section. (preceding a procedure-name)."
In shops that I've worked at, the use of full stop periods is *not* mixing
styles. In fact it is the standard, and is especially useful when a
maintenance programmer comes in the middle of the night without a listing, but
only with the source code before it was expanded by the IDMS pre-compiler. If
you are tracing logic back to look for a flaw - when you hit a period you know
that whatever came before was not part of this particular logic.
| |
| Howard Brazee 2005-06-08, 8:55 pm |
|
On 8-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> I don't doubt for one minute there are sites that are still running COBOL
> code that was written prior to the release of scope delimiters, and I also
> don't doubt there are some COBOL Programmers who are perpetuating this style
> of code, but I don't know personally of any.
But that is not at all the same thing as avoiding periods within a paragraph.
I have worked many places and in my jobs have never come across any program that
did *not* have such periods. That by no means indicates that we eschew scope
indicators.
| |
| Howard Brazee 2005-06-08, 8:55 pm |
|
On 8-Jun-2005, Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
> That would be wise to avoid.
>
> The full-stop period as a scope delimiter is a "END-EVERYTHING"
> statement. An nuclear scope delimiter as it were.
>
> Far better to use the constructs available for the last several decades
> and write:
>
> If O = "+"
> Perform Compute-Display-Add
> End-If
>
> If O = "*"
> Perform compute-Display-Mul
> End-If
So what is wrong with having belts and suspenders? Especially when by using
such, the compiler will notify about some mistakes you might not have caught so
early otherwise?
| |
| Richard 2005-06-08, 8:55 pm |
| Geez, guys, I go away for a few hours and you have a whole religious
war without me.
> do you seriously think I would advise a
> newcomer (or ANYBODY) to use that style?
I would advise a newcomer to be completely incompetent with older
styles, otherwise they could get stuck with maintaining archaic
programs that no one else wants to deal with - leave them to doc I say.
| |
| Howard Brazee 2005-06-08, 8:55 pm |
|
On 8-Jun-2005, "Richard" <riplin@Azonic.co.nz> wrote:
>
> I would advise a newcomer to be completely incompetent with older
> styles, otherwise they could get stuck with maintaining archaic
> programs that no one else wants to deal with - leave them to doc I say.
Of course, I've seen that as an argument to not learn CoBOL.
| |
| docdwarf@panix.com 2005-06-08, 8:55 pm |
| In article <1118261822.381824.286780@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
[snip]
>I would advise a newcomer to be completely incompetent with older
>styles, otherwise they could get stuck with maintaining archaic
>programs that no one else wants to deal with - leave them to doc I say.
It is difficult to remember something without having learned it, Mr
Plinston... and those who have learned what George Santayana had to say
about remembering the past are condemned to repeat it.
DD
| |
| docdwarf@panix.com 2005-06-08, 8:55 pm |
| In article <d87kn8$7kt$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 8-Jun-2005, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
>Of course, I've seen that as an argument to not learn CoBOL.
Now, now, Mr Brazee... what's this? Are you suggesting that Mr Plinston
is a self-hating COBOL coder who displaces his loathing for himself by
projecting it upon others whom he, deeply and secretly, wishes
e'er-so-fervently he was?
Sounds like a dimestore Freudianism to me!
DD
| |
| HeyBub 2005-06-09, 3:55 am |
| Peter Lacey wrote:
> Pete Dashwood wrote:
> <snip>
>
> <snip>
>
>
> Perhaps you could add a bit of explanation to this. While this code
> is perfectly rational and easy to understand, I don't see what
> advantage is conferred by the PERFORMS. Why not use the COMPUTEs
> there?
You could use the compute statement here - I certainly would. This example
is no doubt meant as a schema illustrating that potentially many lines of
mundane computation could be moved out of the logic flow.
| |
| Pete Dashwood 2005-06-09, 3:55 am |
|
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:42A7117C.DEC73B74@mb.sympatico.ca...
> Pete Dashwood wrote:
> <snip>
>
> <snip>
>
what[color=darkred]
>
> Perhaps you could add a bit of explanation to this. While this code is
> perfectly rational and easy to understand, I don't see what advantage is
> conferred by the PERFORMS.
Well, thank you, Peter <g>.
As I mentioned several times, this is NOT how I would personally code it. I
deduced what the code was about from the two IF statements originally given.
PERFORM was used in the originals, so I followed that convention.
> Why not use the COMPUTEs there?
I can think of a number of reasons why not, but all of them are
speculative....
1. Each function may need to do other operation-specific functions, before
doing the compute. e.g.
COMPUTE-DISPLAY-MUL.
PERFORM VALIDATE-MUL-OPERANDS
IF MUL-OPERANDS-OK
COMPUTE A = B * C
PERFORM EDIT-AND-DISPLAY-A
ELSE
PERFORM NOTIFY-MUL-OPERAND-ERROR
END-IF
| |
| HeyBub 2005-06-09, 8:55 am |
| Howard Brazee wrote:
>
> In shops that I've worked at, the use of full stop periods is *not*
> mixing styles. In fact it is the standard, and is especially useful
> when a maintenance programmer comes in the middle of the night
> without a listing, but only with the source code before it was
> expanded by the IDMS pre-compiler. If you are tracing logic back
> to look for a flaw - when you hit a period you know that whatever
> came before was not part of this particular logic.
Where'd I see it.....
Oh well, there's at least one shop "standard" that says "... and thou shalt
pitch it within and without with pitch and thou shalt not have within thy
program a "GO TO" but thou shalt have within each paragraph one period. Thou
shalt not have two periods, nay even three, but one and one alone so that
errors may not be multiplied and this one period that thou must have shall
be among itself alone on a line..."
Modern exegesis thinks this means:
DECIDE-STUFF.
IF O = "+"
PERFORM CALC-SUM
END-IF
IF O = "**"
PERFORM CALC-EXPOTENTIATION
END-IF
. <== Honk if you see the dot
CALC-SUM.
(etc)
| |
| Pete Dashwood 2005-06-09, 8:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d87ee8$33c$1@peabody.colorado.edu...
>
> On 8-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
COBOL[color=darkred]
also[color=darkred]
style[color=darkred]
>
> But that is not at all the same thing as avoiding periods within a
paragraph.
> I have worked many places and in my jobs have never come across any
program that
> did *not* have such periods. That by no means indicates that we eschew
scope
> indicators.
>
And my opinion is that what you are doing is fraught.
You've worked many places? So have I... And my experience is not limited to
one country, vendor, or platform.
Trying to get the best of both worlds often results in getting the worst of
them.
As stated earlier, it is a matter of opinion.
Pete.
| |
| Pete Dashwood 2005-06-09, 8:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1118261822.381824.286780@g14g2000cwa.googlegroups.com...
> Geez, guys, I go away for a few hours and you have a whole religious
> war without me.
>
>
> I would advise a newcomer to be completely incompetent with older
> styles, otherwise they could get stuck with maintaining archaic
> programs that no one else wants to deal with - leave them to doc I say.
>
>
Or Howard... <G>
Pete.
| |
| Pete Dashwood 2005-06-09, 8:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d87kn8$7kt$1@peabody.colorado.edu...
>
> On 8-Jun-2005, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
> Of course, I've seen that as an argument to not learn CoBOL.
>
Can you present any arguments TO learn COBOL in 2005?
Pete.
| |
| Pete Dashwood 2005-06-09, 8:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d87e50$316$1@peabody.colorado.edu...
>
> On 8-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
COBOL[color=darkred]
of[color=darkred]
people[color=darkred]
paragraph[color=darkred]
>
> In shops that I've worked at, the use of full stop periods is *not* mixing
> styles. In fact it is the standard, and is especially useful when a
> maintenance programmer comes in the middle of the night without a listing,
but
> only with the source code before it was expanded by the IDMS pre-compiler.
If
> you are tracing logic back to look for a flaw - when you hit a period you
know
> that whatever came before was not part of this particular logic.
>
Good. Glad it works for you.
I wouldn't use it. And anyone who is still using Networked databases
deserves everything they get... <g>
Pete.
| |
| docdwarf@panix.com 2005-06-09, 8:55 am |
| In article <3gpg4nFda52oU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
>"Howard Brazee" <howard@brazee.net> wrote in message
>news:d87kn8$7kt$1@peabody.colorado.edu...
>Can you present any arguments TO learn COBOL in 2005?
I've found that it puts bread on the table, butter on the bread and is the
most fun I've had making a buck yet... outside of those, nope, no
arguments at all.
DD
| |
| Pete Dashwood 2005-06-09, 8:55 am |
|
<docdwarf@panix.com> wrote in message news:d886ue$hln$1@panix5.panix.com...
> In article <3gpg4nFda52oU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
say.[color=darkred]
>
> I've found that it puts bread on the table, butter on the bread and is the
> most fun I've had making a buck yet... outside of those, nope, no
> arguments at all.
>
Good arguments. I felt that way for many years.
Young people however, need to take a longer view.
Pete.
| |
| docdwarf@panix.com 2005-06-09, 8:55 am |
| In article <3gqeioFdr54eU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:d886ue$hln$1@panix5.panix.com...
[snip]
[color=darkred]
>Good arguments. I felt that way for many years.
We agree? One of us must be wrong, he said, Wildely.
>
>Young people however, need to take a longer view.
I don't see how learning something which others are currently using with
the abovementioned results precludes this, Mr Dashwood... quite the
reverse, it might allow for what some would call 'a decent life' while
other learning takes place.
DD
| |
| Clark Morris 2005-06-09, 3:55 pm |
| On Thu, 9 Jun 2005 12:20:32 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>
>"Howard Brazee" <howard@brazee.net> wrote in message
>news:d87e50$316$1@peabody.colorado.edu...
>COBOL
>of
>people
>paragraph
>but
>If
>know
>Good. Glad it works for you.
>
>I wouldn't use it. And anyone who is still using Networked databases
>deserves everything they get... <g>
Aside from the fact that in some cases I understand the performance is
better than the alternatives, normally the choice of database
management system is at a high level of management. If the database
management system is currently meeting business expectations and not
impeding system upgrades, it becomes difficult to justify the high
cost of change. I believe there are ODBC readers for IDMS.
Indeed I suspect the resistance to OO COBOL is at the management level
far more than at the programmer or analyst levels. I also wonder how
well the various mainframe (IBM, UNISYS, etc.) COBOL OO offerings
interfaced with the rest of the processes on the mainframe. Is there
an adequate repository in those environments that works with all of
the types of objects in the environment?
>
>Pete.
>
>
| |
| Howard Brazee 2005-06-09, 3:55 pm |
|
On 9-Jun-2005, Clark Morris <cfmtech@istar.ca> wrote:
> Aside from the fact that in some cases I understand the performance is
> better than the alternatives, normally the choice of database
> management system is at a high level of management. If the database
> management system is currently meeting business expectations and not
> impeding system upgrades, it becomes difficult to justify the high
> cost of change. I believe there are ODBC readers for IDMS.
>
> Indeed I suspect the resistance to OO COBOL is at the management level
> far more than at the programmer or analyst levels. I also wonder how
> well the various mainframe (IBM, UNISYS, etc.) COBOL OO offerings
> interfaced with the rest of the processes on the mainframe. Is there
> an adequate repository in those environments that works with all of
> the types of objects in the environment?
Heck, our concerns these days are often not so much concerned with persuading a
shop to change archaic CoBOL coding standards, as they are to prepare for when
management decides to replace the whole system with a new one. They're not
going to upgrade how we use CoBOL, they are going to shop the various packages
out there, make a decision, buy the hardware, and then we find out from the
vendor what language we will be programming in. Then we try to learn fast and
maybe have some input in the new standards. We'd better learn good as our
successors will be stuck with whatever we decide upon - just as we've been stuck
with standards from people long gone.
| |
| Peter Lacey 2005-06-09, 3:55 pm |
| docdwarf@panix.com wrote:
>
>
> I've found that it puts bread on the table, butter on the bread and is the
> most fun I've had making a buck yet... outside of those, nope, no
> arguments at all.
>
> DD
According to the site that Kellie Fitton posted, Cobol is the 12th
most-used language. (About a hundred were mentioned. How they gather
their statistics and come to their conclusions is their problem). So
after all these years, neglected, scorned, written off, untaught,
pronounced dead - Cobol STILL seems to be a language to be reckoned
with.
PL
| |
| docdwarf@panix.com 2005-06-09, 3:55 pm |
| In article <42A858FB.3437AB71@mb.sympatico.ca>,
Peter Lacey <lacey@mb.sympatico.ca> wrote:
>docdwarf@panix.com wrote:
>
>
>According to the site that Kellie Fitton posted, Cobol is the 12th
>most-used language. (About a hundred were mentioned. How they gather
>their statistics and come to their conclusions is their problem). So
>after all these years, neglected, scorned, written off, untaught,
>pronounced dead - Cobol STILL seems to be a language to be reckoned
>with.
I reckon I don't know much about reckoning... but I try to maintain a bit
of familiarity with the curious combination of experiences and
coincidences I've learned to call 'My Life'. This combination includes
having been on sites where folks say 'I can't deal with this code' or 'I
never learned about (construct), that's outdated knowledge'... and seeing
such folks looking for a new contract before I have to. Frail, delicate,
sensitive, artistic types, I guess.
('Frail, delicate, sensitive and artistic COBOL-coders'? Waw haw haw haw
haw... sorry, I *tried* to keep a straight face, honest, I did. Whatever
the cause for their statements... I kept on coding, they looked for work.
Granted that they might have wound up at a better site... or maybe not, I
cannot say, I did not keep track of them; all I know is that I prefer
working with code to looking for work working with code.)
DD
| |
| Richard 2005-06-09, 8:55 pm |
| > According to the site that Kellie Fitton posted, Cobol is the 12th
> most-used language.
The measurement was not of usage but was entirely of references to it.
Such references may be advertising courses or discussing problems or
seeling services. This may not even reflect demand for the language but
might indicate the need for help with it. A language that is complex,
convoluted and obscure may generate more references for the same usage
then one that is easy to use and clear.
In particular I noted the disparity between Perl and Python. Though
Perl is probably used more, I suspect that it generates traffic out of
all proportion to the lines written.
| |
| Pete Dashwood 2005-06-10, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:d891d3$9rl$1@panix5.panix.com...
> In article <3gqeioFdr54eU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
news:d886ue$hln$1@panix5.panix.com...[color=darkred]
>
> [snip]
>
the[color=darkred]
>
> We agree? One of us must be wrong, he said, Wildely.
>
>
> I don't see how learning something which others are currently using with
> the abovementioned results precludes this, Mr Dashwood... quite the
> reverse, it might allow for what some would call 'a decent life' while
> other learning takes place.
>
Yes, we can agree again. :-)
Pete.
| |
| Pete Dashwood 2005-06-10, 3:55 am |
|
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:42A858FB.3437AB71@mb.sympatico.ca...
> docdwarf@panix.com wrote:
>
the[color=darkred]
>
> According to the site that Kellie Fitton posted, Cobol is the 12th
> most-used language. (About a hundred were mentioned. How they gather
> their statistics and come to their conclusions is their problem). So
> after all these years, neglected, scorned, written off, untaught,
> pronounced dead - Cobol STILL seems to be a language to be reckoned
> with.
>
It certainly is on COBOL sites... :-)
I made a living directly from COBOL for over 25 years. The Doc is still
doing so and I'm sure there are others here who do so also. I love COBOL as
a programming language, but it isn't a blind infatuation. The world has
moved on. The reasons WHY we used COBOL are no longer as valid as they were,
and procedural programming in general is not as effective as other
methodologies for dealing with modern networks.
Why did we use COBOL? (I could easily write a full article on this, but for
this forum, I'll spare the details and outline only the salient points):
1. It was better than the alternatives (low level, hard to maintain
languages).
2. Maintenance was a prime consideration, and COBOL is excellent for this.
3. Most of the processing was sequential batch. COBOL excels at that.
4. It wasn't really hard to learn COBOL. There was no 'computer science' and
Dijkstrya was just a name you might use in a Limerick, or a tongue twister.
5. People could become 'computer programmers' easily and with little or no
formal training in logic, mathematics, or 'computer science'. In fact, COBOL
was considered the language for implementing 'sound common sense' and valued
as such. The things it was required to do were (for the most part) not
complex (in the sense that putting a man on the moon, or load levelling the
dynamic pressures on network resources, is complex...); implementing
business procedures into a sequential Von Neumann model architecture. Not
rocket science and easily achieved in COBOL.
6. COBOL was a public domain language, freely available, until ANSI got
their hands on it in 1974. Now it isn't free (even the documentation is
charged for), and it takes 17 years to change it or enhance it...
As long as the world of commerce remained static, and all of the above were
still valid, COBOL's future was assured.
But the world (even the conservative world of corporate commerce) did not
remain static. Other technologies promised more commercial advantage. The
Internet, from being an ungraspable concept in the mind of a few nerds,
became something the world has rushed to embrace and is now becoming
integrated into most facets of our daily lives. The 'information (and
disinformation) explosion' has hit us, and the Net serves over 3 billion
pages a day.
It isn't programmed in COBOL, and there are sound reasons why it isn't.
COBOL (along with other similar languages) must, inevitably, decline. It has
certainly declined from it 's position as 'King of the Hill', or 'the only
game in town', even in the last 10 years.
So, could you honestly recommend a young person to s a career in COBOL
today? I don't think so.
Kellie's site is highly suspect, but even if it weren't, I would have
serious reservations about encouraging young people to learn COBOL. (Mind
you, that doesn't mean much; I wouldn't encourage them to learn Latin
either, but it is very useful sometimes to have at least some knowledge of
it...)
I would see no reason to discourage them from learning it as a useful skill,
EXCEPT that my experience has been that once people learn COBOL, they close
their minds and decide that is 'how it's done'. They then have GREAT
difficulty in coming to grips with other concepts that are more pertinent in
this day and age.
(It's a bit like first year Philosophy students having their minds blown
when they encounter Aristotle, and then proceeding to measure the rest of
the course in terms of Aristotelean logic... By the time they realise his
view of the world was not the only possible one or even the best, it is
often too late...)
So, I would recommend COBOL learning as an adjunct to the core skills being
studied for a future career. Decide your career; accounting is good and has
a future, IT has a future but that isn't in COBOL programming, there are
many other career possibilities which are not really relevant here. If you
opt for IT, learn an OO language first, (C++, Java) learn about components,
do some interrupt-driven programming, design and build a web site, THEN
learn COBOL. (And never with a view to making a career as a COBOL
programmer.)
To make a career in COBOL these days means there needs to be a market for
the skill. (instead of relying on suspect web sites, and surveys by people
like Gartner (who have a huge investment in COBOL and can hardly be
disinterested), search the job sites and see what percentage of jiobs
available are for COBOL (in any flavour - mainframe or client/server.).
There ARE some places still using it, there will be others who plan on
continuing to use it (whether they will be able to realise this plan, may
depend on factors which are not yet predictable - technology changes rapidly
and takes unexpected turns...), but the question of the future of COBOL has
virtually been decided.
The Doc correctly pointed out that COBOL can be a useful skill to have while
you are learning something else. How much longer that will be true is
debatable.
The 'glory days' when COBOL was all that was needed are definitely gone.
Meanwhile, we can have hours of fun in CLC deciding on the placement of a
full stop, or whether NEXT SENTENCE should be dropped from the language, or
the philosophy of installation COBOL standards. And it does no harm.
Don't think that what is discussed here has any relevance in the real world;
this forum is 'entertainment only'....(occasionally, and incidentally,
someone gets helped, which is a bonus...)
Pete.
| |
| Pete Dashwood 2005-06-10, 3:55 am |
|
"Clark Morris" <cfmtech@istar.ca> wrote in message
news:r1dfa1d889peoc0j1kubbb7dgufak962kc@
4ax.com...
> On Thu, 9 Jun 2005 12:20:32 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
gnashing[color=darkred]
them[color=darkred]
mixing[color=darkred]
listing,[color=darkred]
pre-compiler.[color=darkred]
you[color=darkred]
>
My comment was decidedly tongue-in-ch; I think people should use whatever
DMS they find effective and are comfortable with, even Hierarchic...I still
have manuals on IMS :-) (now watch the thread get deluged with mail from
sites who are using IMS...)
Of course, my choice is Relational, but I'm a 'go-with-the-flow' kinda
guy....(If you believe that, you haven't read much of CLC... <g> ).
[color=darkred]
> Aside from the fact that in some cases I understand the performance is
> better than the alternatives, normally the choice of database
> management system is at a high level of management. If the database
> management system is currently meeting business expectations and not
> impeding system upgrades, it becomes difficult to justify the high
> cost of change. I believe there are ODBC readers for IDMS.
>
> Indeed I suspect the resistance to OO COBOL is at the management level
> far more than at the programmer or analyst levels. I also wonder how
> well the various mainframe (IBM, UNISYS, etc.) COBOL OO offerings
> interfaced with the rest of the processes on the mainframe. Is there
> an adequate repository in those environments that works with all of
> the types of objects in the environment?
Fair comments/question, Clark, so I'll respond seriously...
First off, your point about Management (rather than the shop floor) deciding
technical things, is well taken. (If you think I give some programmers here
a hard time, it is nothing compared to what I give managers, in private, as
a consultant.) I don't want to digress into the problems of management of IT
facilities, but I can say that the old hierarchic management model with
isolation between the layers, is good only for senior managers, not for the
company...
Poor Managers take decisions that they impose on the shop without doing
proper research or inviting proper scrutiny. (Sometimes it comes down to who
had the best lunch, or the trip abroad, to look at vendor facilities in
Bermuda or wherever...). Fortunately, this is becoming less and less the
norm. Improved corporate communication and management attitudes are leading
to more networking and better understanding in some companies. (I hope this
is 'many' companies, but I'm limiting my comments to personal experience.)
Good Managers listen and lead. They promote free, honest communication and
'blame-free' cultures. It is a privelege to work with them, and they get
fierce loyalty from their troops...
I think you MAY be right about OO COBOL resistance, but it is academic now.
COBOL simply missed the boat. I don't believe the implementations of it into
compilers, by vendors, were at fault. (Actually, I think the design and
implementation of OO facilities into standard COBOL is one of the most
amazing feats of software engineering I have ever seen. Vendors spent a huge
amount of time and resource doing this and it was rejected for the most part
by the COBOL community at large. Why? Innate inertia, conservatism, and
laziness. "Everything I want to do, I can do with standard COBOL...").
Object repository. There has been much acadaemic debate about Object
Databases and most of the early attempts have faded into obscurity. But I
really don't think it is THAT important. I use OO (COBOL and other) and find
that Relational DBs support my objects without problem. It is relatively
(sorry...unconscious pun ;-)) simple to see an object as a structure and
store it. This takes care of its attributes, but not its methods. In most
cases the attributes of an instance are what we want to store anyway, so
that is OK. I think the objections are more theoretical than practical.
Pete.
| |
| Pete Dashwood 2005-06-10, 3:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d89h42$kia$1@peabody.colorado.edu...
>
> On 9-Jun-2005, Clark Morris <cfmtech@istar.ca> wrote:
>
>
> Heck, our concerns these days are often not so much concerned with
persuading a
> shop to change archaic CoBOL coding standards, as they are to prepare for
when
> management decides to replace the whole system with a new one. They're
not
> going to upgrade how we use CoBOL, they are going to shop the various
packages
> out there, make a decision, buy the hardware, and then we find out from
the
> vendor what language we will be programming in. Then we try to learn
fast and
> maybe have some input in the new standards. We'd better learn good as
our
> successors will be stuck with whatever we decide upon - just as we've been
stuck
> with standards from people long gone.
A succinct summary of how it is and has been on many sites, Howard. It has
to change, and the indications are that it may be starting to...(see my
response to Clark, above).
It is another reason why I advocate standards that encourage, rather than
mandate. They can be more flexible for subsequent generations.
Some people will argue that there is no point in having a standard if you
don't mandate it.
So, maybe what we need are not 'standards', but 'best practice guidelines'
....
It has a lot to do with the 'culture' of the installation.
Perhaps another thread on this.
Pete.
| |
| Peter Lacey 2005-06-10, 8:55 am |
| Pete Dashwood wrote:
>
>
> I would see no reason to discourage them from learning it as a useful skill,
> EXCEPT that my experience has been that once people learn COBOL, they close
> their minds and decide that is 'how it's done'. They then have GREAT
> difficulty in coming to grips with other concepts that are more pertinent in
> this day and age.
>
Everything else in your post is reasonable and subject to discussion -
you even use the word "disinterested" properly - yet you had to include
this little gem. You qualify it by saying "my experience has been" -
but then generalize to "people". This is ridiculous! Not to mention
insulting and untrue. I don't dispute that there are people who fit the
description - but you are tarring everybody with the same brush.
Including yourself, I suppose, since you've learned Cobol.
PL
| |
| Pete Dashwood 2005-06-10, 8:55 am |
|
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:42A9009E.2E6CF324@mb.sympatico.ca...
> Pete Dashwood wrote:
>
>
skill,[color=darkred]
close[color=darkred]
pertinent in[color=darkred]
>
> Everything else in your post is reasonable and subject to discussion -
> you even use the word "disinterested" properly - yet you had to include
> this little gem. You qualify it by saying "my experience has been" -
> but then generalize to "people". This is ridiculous! Not to mention
> insulting and untrue. I don't dispute that there are people who fit the
> description - but you are tarring everybody with the same brush.
> Including yourself, I suppose, since you've learned Cobol.
>
I think you're over-reacting. Maybe I touched a nerve. If so, it wasn't
intentional.
It was not intended to be insulting and it is certainly not untrue.
As you were not one of the people I referred to, I'm at a loss to understand
why you are insulted...
I agree, it is ridiculous; but,  ly, true, in my experience. (I haven't
found an exception to it yet, but it is some time since I stopped training
people.)
Of course this can't be true of all people, but it is certainly true of
people I have met who know COBOL and are then required to learn something
else that is 'completely different'. I wish I could qualify it to "some
people", but I can't.
However, if it makes you feel any better, the total number is not great,
around 10.
On the other hand, people who have NOT learned COBOL and have no
pre-judgements, learn things like OO quickly and easily. (in this case the
number is around 15.)
Leaving aside my personal experience, based on courses and seminars run "in
house", look at all the posts that have been made here (by myself and
others) trying to simplify and explain what are really not complex concepts;
and the resistance to them. The tendency is to look for an argument, based
on what is already understood, rather than to accept an idea and get to
grips with it, THEN argue its merits or lack thereof. People who have no
previous understanding DON'T make these ITSA snap judgements. I gave it up
some time ago. Pointless waste of time.
Peter, I don't write here to offend people. I write here for 5 reasons (not
in any articular priority):
1. To genuinely try and help people if their problem is within my sphere of
experience.
2. To stimulate and provoke thought.
3. To entertain and amuse. (myself, and hopefully, others.)
4. To try and steer young people looking at IT careers away from the
rocks.(You don't do that by 'gilding the lily' and pretending all they have
to do is learn COBOL for a good life.)
5. It is a welcome relief to be able to write something that does not have
to be politically correct and carefully worded (although, from your post, it
looks like I may have to re-evaluate that..), as opposed to the things I get
paid to write, which certainly do.
There is no malice in any of my posts and there has never been. I am just as
upset about what's happening to COBOL as anybody else here, but I will not
pretend it's all OK and we can all go on calmly exactly as we have for the
past x decades.
Take what you find useful from my posts.
If you feel I made an unqualified statement and it offends you, let me know
(as you have done, prompting this post.)
If I screwed up, I'll admit it; if I'm sorry, I'll say so.
Beyond that, I stand by what I write.
Pete.
| |
|
| >>Perhaps you could add a bit of explanation to this. While this code is[color=darkred]
The reason is simple:
1 I didn't understand I could put more statements inside an if
2 It's just an exercise, not a real prg. I'm trying to get used to the
Cobol syntax.
Thank for all your help!
| |
|
| >>Can you present any arguments TO learn COBOL in 2005?
>
>
> I've found that it puts bread on the table, butter on the bread and is the
> most fun I've had making a buck yet... outside of those, nope, no
> arguments at all.
That's absolutely my situation.
| |
| docdwarf@panix.com 2005-06-10, 3:55 pm |
| In article <42a99373$1_1@news.bluewin.ch>,
GLari <turbolenceATgmailDOTcom> wrote:
>
>That's absolutely my situation.
It is? Maybe we are related... what was your milkman's name?
DD
| |
| Howard Brazee 2005-06-10, 3:55 pm |
|
On 9-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> I made a living directly from COBOL for over 25 years. The Doc is still
> doing so and I'm sure there are others here who do so also. I love COBOL as
> a programming language, but it isn't a blind infatuation. The world has
> moved on. The reasons WHY we used COBOL are no longer as valid as they were,
> and procedural programming in general is not as effective as other
> methodologies for dealing with modern networks.
I have as well. I expect to leave it because I expect to keep my present job
until I retire, and hopefully after I retire. And I expect my employer to
replace the system I work on with a new system before then. None of the new
systems that are available are based upon CoBOL.
In the Olden Dayze, purchased packages were not a major consideration in what
languages and platforms a company chose. Instead, the major part of their code
was home built and designed. As packages have come to take larger and larger
percentages of companies' data processing needs, tools to work with them become
more important. We adjust our programming, systems, and tools around the
packages instead of the other way around.
CoBOL's future is being determined by companies selling software packages. It
may be that their decisions are being made by analysts or maybe even by their
marketing teams.
It's not being determined by people like me.
| |
| Howard Brazee 2005-06-10, 3:55 pm |
| NNTP-Posting-Host: ums.cusys.edu
X-Trace: peabody.colorado.edu 1118412053 24409 192.12.240.129 (10 Jun 2005 14:00:53 GMT)
X-Complaints-To: abuse@colorado.edu
NNTP-Posting-Date: 10 Jun 2005 14:00:53 GMT
X-Newsreader: News Rover 10.2.3 (http://www.NewsRover.com)
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:114548
On 9-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> So, maybe what we need are not 'standards', but 'best practice guidelines'
> ...
>
> It has a lot to do with the 'culture' of the installation.
>
> Perhaps another thread on this.
Every once in a while it is worth while to start a reply, then cut and paste it
and not post it. Then start a new thread that deserves attention separate from
the earlier topic.
| |
| Howard Brazee 2005-06-10, 3:55 pm |
|
On 9-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> I think you MAY be right about OO COBOL resistance, but it is academic now.
> COBOL simply missed the boat. I don't believe the implementations of it into
> compilers, by vendors, were at fault. (Actually, I think the design and
> implementation of OO facilities into standard COBOL is one of the most
> amazing feats of software engineering I have ever seen. Vendors spent a huge
> amount of time and resource doing this and it was rejected for the most part
> by the COBOL community at large. Why? Innate inertia, conservatism, and
> laziness. "Everything I want to do, I can do with standard COBOL...").
It's not so much that CoBOL missed the boat, but that most CoBOL programmers are
programming in old environments where there is no real incentive to tear down
the structure and switch to OO.
Meanwhile other environments were being created that had new tools. One
characteristic that was common in those new tools was OO. But the main reason
for this is that library languages and OO are easier tools to make and modify.
People don't write in Java because it is OO, they write in Java because it
works well with the new on-line environment. But after creating an environment
that uses OO, its benefits become more apparent.
So while it still doesn't make sense to convert the mainframe batch jobs to OO,
the new system designed to integrate the data warehouse with browser based
terminals will use tools developed for the Web.
One of the nice tools that CoBOL has is its easy-to-understand explicit file
structure system. But that was before the database wanted to handle all of
that stuff on the fly.
| |
| Pete Dashwood 2005-06-10, 3:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d8c69e$nh2$1@peabody.colorado.edu...
>
> On 9-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
as[color=darkred]
were,[color=darkred]
>
> I have as well. I expect to leave it because I expect to keep my present
job
> until I retire, and hopefully after I retire. And I expect my employer
to
> replace the system I work on with a new system before then. None of
the new
> systems that are available are based upon CoBOL.
>
> In the Olden Dayze, purchased packages were not a major consideration in
what
> languages and platforms a company chose. Instead, the major part of
their code
> was home built and designed. As packages have come to take larger and
larger
> percentages of companies' data processing needs, tools to work with them
become
> more important. We adjust our programming, systems, and tools around
the
> packages instead of the other way around.
>
> CoBOL's future is being determined by companies selling software packages.
It
> may be that their decisions are being made by analysts or maybe even by
their
> marketing teams.
>
> It's not being determined by people like me.
I completely sympathise with the above and, as usual from Howard, it is on
the button and sensible.
I don't completely agree with the packages dictating the future of COBOL,
but I certainly agree the deployment of packages has influenced it. In the
Olden Dayse, the packages were, frankly, poor. COBOL systems ran rings round
them. That is not true today. The packages employ modern (often component
based) techniques in their development and are very modular and pluggable.
Interfaces are provided for customization and these are high level, even
4GL, interfaces.
Having had personal experience with implementations of SAP and Siebel (and
knocked up a bit of ABAPS as an execise) I have to say these packages are
now light years ahead of where they were 20 years ago. (I remember in the
80s evaluating SAP in Germany (it was developed there) and deciding that it
was simply not capable of doing what was required, and the cost of tailoring
it (in those days it was done in Assembler) would be prohibitive. As a
result, the company I was acting for retained their COBOL development. They
eventually dropped it in the mid 90s when SAP was evaluated again and found
to be better.(I wasn't involved in that round).
But the reason COBOL cannot compete is not because of the packages. It is
inherent in the way COBOL is developed and deployed. It just isn't cost
effective to have expensive programmers writing and maintaining thousands
(even millions, on some sites) of lines of source code that require high
maintenance, when you don't have to. Especially when that code is no longer
enough in and of itself to guarantee competitive edge for the business. In
addition to the COBOL you need the Network support guys, the help desk, the
techies, the Windows gurus, the DB specialists, the mainframe support and
operations... it is no wonder that for Directors with their eye on the
bottom line, a package becomes very attractive. Outsource the Network and
tech stuff, and let the Business configure the package, with help from the
vendor until they learn how to do it themselves.
The in house IT department gets downsized and millions are trimmed off the
operating expenses.
I know of one company who cut their annual IT bill from over $25,000,000 a
year to just $6,000,000 a year by doing this. In the process they dropped
COBOL. (Actually they sold all their in house development, then leased it
back from the company they sold it to. No more maintenance; no more
development. Let someone else worry about it...)
All of these things are contributing to the decline of COBOL; it isn't just
about whether the language itself has relevance in a modern environment.
Pete.
| |
| Pete Dashwood 2005-06-10, 3:55 pm |
| X-Trace: individual.net IjyfrrbAqbGhTvm+/IdASwv49gNL9QmtdFFSKJUCPFuPIGsDVf
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:114556
"Howard Brazee" <howard@brazee.net> wrote in message
news:d8c6vm$o07$1@peabody.colorado.edu...
>
> On 9-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
now.[color=darkred]
into[color=darkred]
huge[color=darkred]
part[color=darkred]
>
> It's not so much that CoBOL missed the boat, but that most CoBOL
programmers are
> programming in old environments where there is no real incentive to tear
down
> the structure and switch to OO.
Yes, I think that's fair. Maybe it wasn't COBOL that missed the boat...:-)
>
> Meanwhile other environments were being created that had new tools. One
> characteristic that was common in those new tools was OO. But the main
reason
> for this is that library languages and OO are easier tools to make and
modify.
> People don't write in Java because it is OO, they write in Java because
it
> works well with the new on-line environment. But after creating an
environment
> that uses OO, its benefits become more apparent.
Absolutely true.
>
> So while it still doesn't make sense to convert the mainframe batch jobs
to OO,
> the new system designed to integrate the data warehouse with browser based
> terminals will use tools developed for the Web.
I can't see batch jobs ever being converted to OO, neither would I advocate
it. My own feeling is that the future is on the Web and your post seems to
endorse this viewpoint.
>
> One of the nice tools that CoBOL has is its easy-to-understand explicit
file
> structure system. But that was before the database wanted to handle all
of
> that stuff on the fly.
Hahaha! That same nice file system was one of the major nails in COBOL's
coffin... It is closed. You can't get at information without writing a
COBOL program. In modern environments where data has to be shared easily,
and flies around the network getting updated, having data in repositories
that can't be accessed with standard tools, like spreadsheets and local
databases, is just unaceptable. By the time ODBC drivers became available it
was too late...
Pete.
|
|
|
|
|