COBOL on RosettaCode
axtens
rosettacode.org/wiki/Find_limit_of_recursion#COBOL>. It's OpenCOBOL
1.1 code. Is there some way of catching a recursion failure in code?
Kind regards,
Bruce.
Alistair
No. You are recursively PERFORMing a paragraph 253 times. The limits
are most likely to be vendor specific.
SQL uses WHENEVER to process an error in SQL execs and CICS can handle
errors but not Cobol itself.
If you are only interested in the depth which the recurs can go to
then print the count before each call. For more fun, try to call the
same program from within itself.
Bill Klein
There are other ways of implementing PERFORMs. It might (or might not)
require code changes, but it would be interesting to know what happens with
IBM COBOLs. I think the counter would loop past 999 AND the program would
only end on a "timeout. But I am saying this without actually testing it,
so I could be wrong.
"Alistair" <alis...@ld50macca.demon.co.uk> wrote in message
news:0718fbef-1055-42b3...@q1g2000yqg.googlegroups.com...
Kulin Remailer
> Also, his code stops because it uses "stack based" recursive PERFORMs.
> There are other ways of implementing PERFORMs. It might (or might not)
> require code changes, but it would be interesting to know what happens
> with IBM COBOLs. I think the counter would loop past 999 AND the program
> would only end on a "timeout. But I am saying this without actually
> testing it, so I could be wrong.
Bill,
The last time I looked at this, recursive perform within a single source
deck was impossible and did not work as intended. I debugged a failure in
somebody else's code and I saw he was coding COBOL like a C programmer. As
far as I know, recursive PERFORM is impossible because there is no stacking
of calls the way PERFORM is compiled. Looking at the assembler code
generated from a PERFORM, it's immediately obvious.
I have not looked at the source referenced in your post, I am only speaking
to the issue of whether PERFORM works recursively or not in IBM Enterprise
COBOL.
PERFORM is so bad for performance in the z/OS and prior architectures, it
should really be used only very sparingly and not as a standard way of
coding.
Howard Brazee
wrote:
>PERFORM is so bad for performance in the z/OS and prior architectures, it
>should really be used only very sparingly and not as a standard way of
>coding.
I haven't seen that recommendation in decades.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison
docd...@panix.com
Kulin Remailer <rema...@reece.net.au> wrote:
[snip]
>PERFORM is so bad for performance in the z/OS and prior architectures, it
>should really be used only very sparingly and not as a standard way of
>coding.
That's an interesting recommendation. What might you suggest as an
alternative to PERFORM?
DD
Ken
> In article <I0KSIU7640415.9800115...@reece.net.au>,
> Kulin Remailer <remai...@reece.net.au> wrote:
>
> [snip]
>
> >PERFORM is so bad for performance in the z/OS and prior architectures, it
> >should really be used only very sparingly and not as a standard way of
> >coding.
>
> That's an interesting recommendation. What might you suggest as an
> alternative to PERFORM?
>
> DD
I'd recommend GO TO. But only in the context of using the Code 'n' Fix
Software Development Life Cycle (SDLC). As an hourly contractor, I've
always been a big fan of Code 'n' Fix. I think it is a highly
underrated methodology, even more flexible than Agile, and much more
compatible with "All ya' gotta do..." infinite iterations. Can
somebody provide me a cost-justification in cpu-time saved by
replacing all of our PERFORMs with GO TO's? I'm not ready to retire
yet, and I'd like to extend my project for a while.
Ken
Howard Brazee
wrote:
>I'd recommend GO TO. But only in the context of using the Code 'n' Fix
>Software Development Life Cycle (SDLC). As an hourly contractor, I've
>always been a big fan of Code 'n' Fix. I think it is a highly
>underrated methodology, even more flexible than Agile, and much more
>compatible with "All ya' gotta do..." infinite iterations. Can
>somebody provide me a cost-justification in cpu-time saved by
>replacing all of our PERFORMs with GO TO's? I'm not ready to retire
>yet, and I'd like to extend my project for a while.
I see a huge upside in saving a few CPU micro-seconds by greatly
expanding programming labor needed.
Richard
The code is invalid COBOL, recursive performs are not allowed, neither
directly nor indirectly. The PERFORM stack is not designed to cope
with self-perform, only with nested performs where 253 levels is
perfectly adequate.
To do recursion in COBOL you need to do it as it is done in every
other language, with CALLs. One test shows that it gets 5,734
recursions before running out of stack, but that will vary with the
parameters passed.
Richard
This is how it should be done, note that this is one file with a
nested subroutine:
IDENTIFICATION DIVISION.
PROGRAM-ID. recurse RECURSIVE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Starter PIC S9(8) VALUE 1.
PROCEDURE DIVISION.
Program-Recurse.
CALL "recurse-sub" USING Starter
STOP RUN.
IDENTIFICATION DIVISION.
PROGRAM-ID. recurse-sub.
DATA DIVISION.
WORKING-STORAGE SECTION.
LINKAGE SECTION.
01 Countr PIC S9(8).
PROCEDURE DIVISION USING Countr.
Program-Recursive.
DISPLAY Countr
ADD 1 TO Countr
CALL "recurse-sub" USING Countr
EXIT PROGRAM.
END PROGRAM recurse-sub.
END PROGRAM recurse.
Alistair
I thought code n fix was a deliberate attempt at humour. Then I
googled it. It seems that your method is superseded by test driven
development.
Alistair
I thought Cobol was supposed to be against recursively CALLing itself?
I know that Natural allows recursive CALLs to the CALLing program.
Ken
>
> - Show quoted text -
Test Driven Development (TDD)??? Superseded, NOT! Scoff!!
As a tool to support the "profit center" objective of a contractor
company, the Code 'n' Fix SDLC works best when complemented by Defect
Driven Development (DDD). Differs from TDD and far superior in that
only the _most superficial_ of unit testing, and no integration
testing at all, is performed by the developer/coder/contractor
company. Nearly all testing is pushed outward to the System Test Team,
or most preferably, to the End User. Management justification for this
is that "developer time is just too costly for them to do testing...
let's have other, cheaper folks do it." The code is fixed "when
needed", and not before, and the fix is needed only when a User
detects the defect during production operations. Hence, Defect Driven
Development.
I've seen DDD in action, even participated in it, for my Timesheet was
always signed. Code 'n' Fix combined with DDD works great when the
contractor is on a fixed-bid-initial-development phase to be followed
by a hourly-rate-maintenance-phase follow-on contract and the end-
client is not very sophisticated in conducting their User Acceptance
Test (UAT), which lets a lot of undetected defects into production. As
a business strategy, Code 'n' Fix / DDD can be quite lucrative. For
the contractor, that is :-).
I used to envision Code 'n' Fix as the "baseline" SDLC, you know, the
"least mature" of any of the SDLC methodologies (Code 'n' Fix,
Waterfall, Feedback-Waterfall, Spiral, Agile, Extreme Programming,
etc, etc.) Until I realized that there is an even cruder, "baser" :-)
baseline SDLC, and that is the Code 'n' Not-Fix SDLC. These are not
very lucrative for the original contractor, for eventually they
usually get terminated. Great for the Maintenance Programmer
replacement though :-), as my personal experience can attest to :-).
[Aside: there are actually two variations of Code 'n' Not Fix, and
those are Code 'n' Can't Fix, and Code 'n' Won't Fix. But since they
involve Philosophical discussions revolving around the issues of
Ability and Free Will, they are better addressed at another time...]
There may be one other methodology that is even upstream of Code 'n'
Not Fix, however, and that is the System Shelfware Development (SSD)
methodology. Great effort is expended and great billings are made in
conducting interviews, writing meeting minutes, conducting flow-chart
JAD sessions, drawing lots and lots of Visio flow-charts, blue-sky
wish-listing, etc, the likes of which are captured in about a half-
dozen or so five-inch wide 3-ring binders. No code is ever written,
because that is left for the developers at a later "stage". And that
"stage" never arrives.
This is the most defect-free of any of the methodologies. Nothing is
ever built, so nothing ever breaks. Thus, it is impossible to prove
that any errors exist in the shelfware.
It's great work if you can get it. :-)
Ken
Ken
> On Wed, 25 Aug 2010 11:52:55 -0700 (PDT), Ken <klsha...@att.net>
Hey, Howard, I like the way you think... :-) ... the upside is HUGE!
The Marketing Plan goes like this... "You see, Mr./Ms. Client, as you
know our economy is in deflation, and everybody is focusing on cost-
reduction rather than increasing income. So with our Proprietary Tool
PT-MicroSeconds [tm pending] we take all those saved micro-seconds and
deposit them in the CPU-Bank over here, and you can delay your
mainframe replacement or upgrade for AT LEAST THREE YEARS!!"
Have a diagram showing the saved Micro-Seconds being deposited in a
Virtual Deposit-Only CPU Savings Bank. The words "Deposit-Only" should
be in a very small font. What we are saying is that the micro-seconds
are saved, but can never be "withdrawn." Sort of like "write-only"
memory :-). Also notice that the language in the preceding paragraph
does NOT imply any cause-and-effect relationship, only a "conjunctive
AND" relationship. [Attn Legal Dept: Can you check this out for us?]
If their current CPU can handle our development time in replacing
PERFORMs with GO-TO's, then surely they can handle production
operations _without_ development time, so we just stay on "on project"
until the CPU reaches, say, 90% capacity or so, then announce the
project is Done! CPU utilization will immediately drop to 70% or so
(because no more development/test) thus amply demonstrating the
success of us and our project. Get a reference and go on to the next
client.
Ken
Pete Dashwood
Outstanding!
ROFL!
Thanks Ken, one of the best pieces posted here for years. :-)
Pete.
--
"I used to write COBOL...now I can do anything."
docd...@panix.com
Ken <klsh...@att.net> wrote:
>On Aug 25, 12:00?pm, docdw...@panix.com () wrote:
>> In article <I0KSIU7640415.9800115...@reece.net.au>,
>>
>> [snip]
>>
>> >PERFORM is so bad for performance in the z/OS and prior architectures, it
>> >should really be used only very sparingly and not as a standard way of
>> >coding.
>>
>> alternative to PERFORM?
>>
>> DD
>
>I'd recommend GO TO. But only in the context of using the Code 'n' Fix
>Software Development Life Cycle (SDLC). As an hourly contractor, I've
>always been a big fan of Code 'n' Fix.
Ahhhhh... perhaps that might be one of the variant shadings.
The contractor prefers Code 'n' Fix, where the activity is performed
(purportedly) towards an end.
The consultant prefers Just Code, where the activity is its own
justification.
The Corner Office Idiot prefers endless meetings which result in neither
activity nor (by definition) end.
DD
Bill Klein
news:067c33c1-717a-47be...@n19g2000prf.googlegroups.com...
On Aug 24, 9:14 pm, axtens <bruce.axt...@gmail.com> wrote:
>The code is invalid COBOL, recursive performs are not allowed, neither
> directly nor indirectly. The PERFORM stack is not designed to cope
> with self-perform, only with nested performs where 253 levels is
> perfectly adequate.
Richard,
Recursive PERFORMs are not part of Standard COBOL, but several (many?
Most?) compiler vendors allow it as a either a documented or undocumented
extension.
Bill Klein
On Aug 25, 8:08 pm, Richard <rip...@Azonic.co.nz> wrote:
> On Aug 24, 9:14 pm, axtens <bruce.axt...@gmail.com> wrote:
> I thought Cobol was supposed to be against recursively CALLing itself?
> I know that Natural allows recursive CALLs to the CALLing program.
It was added to Standard COBOL in the '02 Standard and by many compilers
before that as an extension. In many compilers, it came in when they added
Local-Storage Section. In the Standard, it is "allowed" with the "IS
RECURSIVE" phrase of the Identification Division (program-id paragraph).
See the example, in this thread.
Anonymous
> >should really be used only very sparingly and not as a standard way of
> >coding.
>
> That's an interesting recommendation. What might you suggest as an
> alternative to PERFORM?
PERFORM is a solution to a problem that doesn't exist. I don't really
understand the question.
docd...@panix.com
Based on the assertion that 'PERFORM... should not (be used) as a standard
way of coding' (paraphrased from above) then the question of 'what might
you suggest as an alternative to it' could be readily addressed by
completing the sentence:
'I suggest that instead of coding a PERFORM a programmer should, as
readily and frequently as PERFORMs might be used, employ the COBOL
statements of...'
DD
Howard Brazee
>>PERFORM is a solution to a problem that doesn't exist. I don't really
>>understand the question.
>
>Based on the assertion that 'PERFORM... should not (be used) as a standard
>way of coding' (paraphrased from above) then the question of 'what might
>you suggest as an alternative to it' could be readily addressed by
>completing the sentence:
>
>'I suggest that instead of coding a PERFORM a programmer should, as
>readily and frequently as PERFORMs might be used, employ the COBOL
>statements of...'
If CoBOL is dead, then this problem doesn't exist. I've seen
several management decisions that use similar assumptions and logic.
SkippyPB
wrote:
>On 25 Aug 2010 15:31:13 -0000, Kulin Remailer <rema...@reece.net.au>
>wrote:
>
>>PERFORM is so bad for performance in the z/OS and prior architectures, it
>>should really be used only very sparingly and not as a standard way of
>>coding.
>
>I haven't seen that recommendation in decades.
I agree. That's one of the dumbest things I've ever heard about
COBOL.
As for the Assembler portion, it generates it the same way you would
"perform" a routine in Assembler. You save your registers to R13. You
put the address of the routine in R15. Then issue BALR 14,15 to
perform the routine and come back.
Regards,
--
////
(o o)
-oOO--(_)--OOo-
"Never answer an anonymous letter."
-- Yogi Berra
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
SkippyPB
wrote:
>On Aug 25, 4:24 pm, Alistair <alist...@ld50macca.demon.co.uk> wrote:
>> On Aug 25, 7:52 pm, Ken <klsha...@att.net> wrote:
>>
>>
>>
>>
>>
>> > On Aug 25, 12:00 pm, docdw...@panix.com () wrote:
>>
>> > > In article <I0KSIU7640415.9800115...@reece.net.au>,
>> > > Kulin Remailer <remai...@reece.net.au> wrote:
>>
>> > > [snip]
>>
<<snip>>
>
>This is the most defect-free of any of the methodologies. Nothing is
>ever built, so nothing ever breaks. Thus, it is impossible to prove
>that any errors exist in the shelfware.
>
If nothing is ever built, why would they need programmers? They could
get monkeys to do it. But then I might be able to retire after all!
>It's great work if you can get it. :-)
>
>Ken
Regards,
Bill Klein
decade and a half (ever since VS COBOL II, R1.0 - if my memory is correct)
actually MOVE perform code "inline" when the OPT compiler option is
specified and some other situations occur. As I recall (and I could be
mistaken on this) they do not (and cannot) do this for GO TO.
"SkippyPB" <swie...@Nospam.neo.rr.com> wrote in message
news:g33d769oa9etavtff...@4ax.com...
Nomen Nescio
> It may be worth noting about IBM (mainframe) COBOL compilers for the last
> decade and a half (ever since VS COBOL II, R1.0 - if my memory is
> correct) actually MOVE perform code "inline" when the OPT compiler option
> is specified and some other situations occur. As I recall (and I could
> be mistaken on this) they do not (and cannot) do this for GO TO.
Hi Bill,
I tried it on z/OS 1.9 (not sure which COBOL it was) a few years ago and I
didn't see that happen with OPT or NOOPT- I was hoping I would. It may also
have to do with the length of the source or other factors. I didn't do much
tweaking of the source code.
If that was the case I would not feel as strongly as I do about limiting
the use of PERFORM, but I didn't see inlining as I would have hoped.
Pete Dashwood
> On Thu, 26 Aug 2010 12:53:08 +0000 (UTC), docd...@panix.com () wrote:
>
>>> PERFORM is a solution to a problem that doesn't exist. I don't
>>> really understand the question.
>>
>> Based on the assertion that 'PERFORM... should not (be used) as a
>> standard way of coding' (paraphrased from above) then the question
>> of 'what might you suggest as an alternative to it' could be readily
>> addressed by completing the sentence:
>>
>> 'I suggest that instead of coding a PERFORM a programmer should, as
>> readily and frequently as PERFORMs might be used, employ the COBOL
>> statements of...'
>
> If CoBOL is dead, then this problem doesn't exist. I've seen
> several management decisions that use similar assumptions and logic.
I don't think the "problem" exists, whether COBOL is alive or dead.
In both of the threads on this, there has been a huge amount of heat for no
apparent reason that I can see.
It's like people lose their sense of humor and perspective when someone
makes a comment on COBOL.
Fritz says he doesn't like the comments (as I hadn't responded, I decided I
was not guilty on this occasion... :-)), but it is very hard to take
someone seriously (for me, anyway...) when they are suggesting "that PERFORM
is "inefficient" and should be avoided". I really enjoyed Ken's satirical
response and (as in all good satire) there are gems of truth in what he
posted.
If, in Fritz's world, saving millions of instructions is still important
(and given that HeyBub pointed out the actual real time saving would be less
than a second), then that's fair enough. However, it doesn't do any of us
any harm to re-evaluate what we hold to be true, every so often. Fritz has
probably worked a very long time in IT with CPU efficiency as one of his
higher priorities when it comes to development.
I think I mentioned elsewhere that all of us have our personal mix of
priorities when it comes to writing code. (Sometimes it gets overlaid by the
actual site priorities where we are working, but very often Local
Programming standards don't spell out what these priorities should be, so it
is left to the individual programmer to provide code, the understanding
being that everyone agrees the top priority is that it must work
correctly...)
My experience has been that an unconditional branch (GO TO) is USUALLY the
fastest executing instruction in the executable set on most platforms.(And
often many times faster to execute than any other instruction.)
But that doesn't mean I advocate a return to spaghetti coding. (I suspect
that Fritz doesn't either, but he is painted into a bit of a corner if he
rules out PERFORM.)
In this day and age, with the incredible power of modern processors, some
adjustments to coding priorities can be made. It isn't just about COBOL; it
applies to most procedural languages. (Non-procedural languages aren't
really concerned with executable instruction sequences, just accepting that
they will be adequate, and if they prove not to be, optimizing them as a
separate specialised exercise...)
The world has moved on and many of the things that were absolutely critical
half a century ago, are not so critical any longer.
The first machine I ever programmed (in 1965) executed around 200,000
instructions per second; the laptop I am writing this on does around
20,000,000 on two separate cores.
It would be foolish not to adjust my "programming attitude" accordingly.
Richard
Even 25 years ago I had clients running several users on an 8086 of
6MHz using LevelII COBOL with .int byte code. Disk access time was so
much greater than any CPU usage. Today I have a client running 60-80
user sessions on a 7 year old AMD single core of about 2GHz. Checking
'top' shows 98.n% idle currently, occasionally it drops to 70%
(probably doing a postscript merge and print). I've never seen the
idle drop below about 60%.
But these do not run any Microsoft products.
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
[snip]
>Fritz says he doesn't like the comments (as I hadn't responded, I decided I
>was not guilty on this occasion... :-)), but it is very hard to take
>someone seriously (for me, anyway...) when they are suggesting "that PERFORM
>is "inefficient" and should be avoided".
As I recall from my studies in Ancient Greek, e'er-so-long ago - long
enough that it wasn't called 'Ancient!' - 'ta kala, khalepa' (where 'kh'
represents the letter 'chi', pronounced 'khay', and represents not a
diacritically-marked (or 'gutteral') 'h' but a sound more akin to the 'kh'
found in the word 'packhorse') or 'that which is good is
hard/difficult/not easy'.
I took (or tried to take) the suggestions seriously enough to ask for
alternatives and posted code which appeared to contradict some of them...
but this is UseNet and it might take a while for counter-examples to be
produced.
[snip]
>If, in Fritz's world, saving millions of instructions is still important
>(and given that HeyBub pointed out the actual real time saving would be less
>than a second), then that's fair enough.
Not according to the rule that 'a well-functioning system is one which
causes the person who signs the checks for it to smile'. If the Shop
Standard is 'code it for the two-year programmer at 2:am' and Programmer
X's standard is 'code for micro-efficiency to the point of
unmaintainability by anyone except for me' the there seems to be a bit of
a clash.
>However, it doesn't do any of us
>any harm to re-evaluate what we hold to be true, every so often.
I knew someone who re-evaluated his belief that it doesn't do harm to
re-evaluate what he held true and determined it to be false and no longer
worth re-revaluating. Fortunately his memory was poor and he forgot this.
DD
Bruce M. Axtens
> On Aug 24, 9:14 pm, axtens<bruce.axt...@gmail.com> wrote:
>> I've posted something to do with recursion limits at<http://
>> rosettacode.org/wiki/Find_limit_of_recursion#COBOL>. It's OpenCOBOL
>> 1.1 code. Is there some way of catching a recursion failure in code?
>
> This is how it should be done, note that this is one file with a
> nested subroutine:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. recurse RECURSIVE.
... which compiles nicely with OpenCobol 1.1 under Cygwin. Running it
gives (abbreviated):
+00000960
+00000961
+00000962
+00000963
+00000964
recurse.cbl:19: Attempt to reference unallocated memory (Signal SIGSEGV)
Abnormal termination - File contents may be incorrect
How do I catch it before it does an ab-term? Or how do I catch it when
it does the ab-term? Or am I stuck with it crashing when it feels like it?
Kind regards,
Bruce.
Pete Dashwood
> In article <8dogut...@mid.individual.net>,
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>> Fritz says he doesn't like the comments (as I hadn't responded, I
>> decided I was not guilty on this occasion... :-)), but it is very
>> hard to take someone seriously (for me, anyway...) when they are
>> suggesting "that PERFORM is "inefficient" and should be avoided".
>
> As I recall from my studies in Ancient Greek, e'er-so-long ago - long
> enough that it wasn't called 'Ancient!' - 'ta kala, khalepa' (where
> 'kh' represents the letter 'chi', pronounced 'khay', and represents
> not a diacritically-marked (or 'gutteral') 'h' but a sound more akin
> to the 'kh' found in the word 'packhorse') or 'that which is good is
> hard/difficult/not easy'.
This is axiomatically false. There are many simple, easy, things that are
good and are NOT "hard/difficult/not easy".
Maybe difficult for Greeks...
> [snip]
>
>> If, in Fritz's world, saving millions of instructions is still
>> important (and given that HeyBub pointed out the actual real time
>> saving would be less than a second), then that's fair enough.
>
> Not according to the rule that 'a well-functioning system is one which
> causes the person who signs the checks for it to smile'.
However, such a rule has never been established and only exists in your
mind. It was never part of Fritz's discussion or anyone else's, with the
possible exception of yourself. There are many aspects of a well-functioning
system that have nothing whatsoever to do with the person who pays for it
smiling, although that particular aspect can be an important one.
It's funny, I have clients who pay up cheerfully and others who don't smile
at all. The bank assigns equal weight to cheques from both categories. I've
never seen them give me extra credit because the person who wrote the cheque
smiled.
> If the Shop
> Standard is 'code it for the two-year programmer at 2:am' and
> Programmer X's standard is 'code for micro-efficiency to the point of
> unmaintainability by anyone except for me' the there seems to be a
> bit of a clash.
But, in this discussion the Shop standard has never been established so your
'If" is decidedly... iffy. There is no evidence whatsoever to suggest that
the code would be "unmaintainable by anyone but me", apart from the
suggestion that GO TO might be a better alternative to PERFORM. For many
years before structured programming was discovered COBOL code WAS maintained
by COBOL programmers. I remember maintaining spaghetti code (my own and
others). It is not impossible, just more difficult than maintaining well
structured code.
You are adding elements for the sake of argument which were never part of
the original post.
Obviously, how you spend your time is a matter for you, but does the
proposition that PERFORM should be avoided in COBOL really warrant the time
being spent on it?
I should have thought it was easily dismissable, without having to introduce
Greeks and people who pay for systems and possible interpretation of Shop
Standards... Once Fritz's point of view is understood, it becomes clear why
he feels the way he does and it is then fairly simple to point out why
others don't.
>
>> However, it doesn't do any of us
>> any harm to re-evaluate what we hold to be true, every so often.
>
> I knew someone who re-evaluated his belief that it doesn't do harm to
> re-evaluate what he held true and determined it to be false and no
> longer worth re-revaluating. Fortunately his memory was poor and he
> forgot this.
A Greek, perhaps? Or maybe he couldn't remember his nationality, either...?
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
>> In article <8dogut...@mid.individual.net>,
>> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>> Fritz says he doesn't like the comments (as I hadn't responded, I
>>> decided I was not guilty on this occasion... :-)), but it is very
>>> hard to take someone seriously (for me, anyway...) when they are
>>> suggesting "that PERFORM is "inefficient" and should be avoided".
>>
>> As I recall from my studies in Ancient Greek, e'er-so-long ago - long
>> enough that it wasn't called 'Ancient!' - 'ta kala, khalepa' (where
>> 'kh' represents the letter 'chi', pronounced 'khay', and represents
>> not a diacritically-marked (or 'gutteral') 'h' but a sound more akin
>> to the 'kh' found in the word 'packhorse') or 'that which is good is
>> hard/difficult/not easy'.
>
>This is axiomatically false. There are many simple, easy, things that are
>good and are NOT "hard/difficult/not easy".
Mr Dashwood, perhaps you'd be so kind as to point out whether truth or
falsity, axiomatic or idiosyncratic or otherwise, existed for the
statement in question. As you quoted in your response I stated that I was
taught this and nothing about veracity or verifiability.
[snip]
>>> If, in Fritz's world, saving millions of instructions is still
>>> important (and given that HeyBub pointed out the actual real time
>>> saving would be less than a second), then that's fair enough.
>>
>> Not according to the rule that 'a well-functioning system is one which
>> causes the person who signs the checks for it to smile'.
>
>However, such a rule has never been established and only exists in your
>mind.
That is axiomatically false, Mr Dashwood, if the reading of something
causes it to exist (in any form) in the reader's mind. Those whose habit
it is to respond to postings without reading them might have a leg to
stand on.
[snip]
>> If the Shop
>> Standard is 'code it for the two-year programmer at 2:am' and
>> Programmer X's standard is 'code for micro-efficiency to the point of
>> unmaintainability by anyone except for me' the there seems to be a
>> bit of a clash.
>
>But, in this discussion the Shop standard has never been established so your
>'If" is decidedly... iffy.
Mr Dashwood, thanks much for pointing out that a sentence which begins
with a conditional could, just possibly, be based on one or more
conditions; I am certain that many find this to be of infinitely greater
value than others do.
[snip]
>Obviously, how you spend your time is a matter for you, but does the
>proposition that PERFORM should be avoided in COBOL really warrant the time
>being spent on it?
So much for 're-evaluating what we hold true, every so often'... only a
poopie-head might have ever thought to suggest such a thing!
>
>I should have thought it was easily dismissable, without having to introduce
>Greeks and people who pay for systems and possible interpretation of Shop
>Standards... Once Fritz's point of view is understood, it becomes clear why
>he feels the way he does and it is then fairly simple to point out why
>others don't.
When I find a compiler option which takes how one feels into account I'll
use it in, I hope, an appropriate manner... until then the Assembley
listing is still a fairly decent Temple of Truth.
>>> However, it doesn't do any of us
>>> any harm to re-evaluate what we hold to be true, every so often.
>>
>> I knew someone who re-evaluated his belief that it doesn't do harm to
>> re-evaluate what he held true and determined it to be false and no
>> longer worth re-revaluating. Fortunately his memory was poor and he
>> forgot this.
>
>A Greek, perhaps? Or maybe he couldn't remember his nationality, either...?
Unlike some here, Mr Dashwood, I try not to ask too much into peoples'
nationalities.
DD
Ken
<dashw...@removethis.enternet.co.nz> wrote:
>
> I really enjoyed Ken's satirical
> response and (as in all good satire) there are gems of truth in what he
> posted.
>
Gee, Pete, thanks, it makes me feel really good that should I ever
lose my CoBOL day job there is work for me as a standup at the CLC
Comedy Club. ;-) I'll hire Doc as my opening act, but I'll insist
he'll have to 'dumb it down' cause so few of us know Greek, Kant, and
Kierkegaard. :-)
Ken
Richard
> Richard wrote:
> > On Aug 24, 9:14 pm, axtens<bruce.axt...@gmail.com> wrote:
> >> I've posted something to do with recursion limits at<http://
> >> rosettacode.org/wiki/Find_limit_of_recursion#COBOL>. It's OpenCOBOL
> >> 1.1 code. Is there some way of catching a recursion failure in code?
>
> > This is how it should be done, note that this is one file with a
> > nested subroutine:
>
> > IDENTIFICATION DIVISION.
> > PROGRAM-ID. recurse RECURSIVE.
>
> ... which compiles nicely with OpenCobol 1.1 under Cygwin. Running it
> gives (abbreviated):
>
> +00000960
> +00000961
> +00000962
> +00000963
> +00000964
> recurse.cbl:19: Attempt to reference unallocated memory (Signal SIGSEGV)
> Abnormal termination - File contents may be incorrect
The number of recursions available seems to depend on several factors
including the stack size allocated by the compilation.
> How do I catch it before it does an ab-term? Or how do I catch it when
> it does the ab-term? Or am I stuck with it crashing when it feels like it?
For OpenCOBOL I suggest that you direct this question to Roger at
opencobol.org. I would have hoped that an 'ON EXCEPTION' added to the
CALL would have done this, but it didn't using the version that I was
running. It may be that there is some compiler option that makes it do
stack checking, or perhaps allows the size of the stack to be set to
some larger limit.
On Linux the stack size can be set. 'ulimit -s' will show the current
size and 'ulimit -s <newsize>' will set it for the current shell. I
just did a run that did 16,000 recurses by setting it to 32000.
I suspect that this makes the experiment pointless because the limit
on recursion is not dependent on the language, nor the implementation,
but is also dependent on the environment and individual settings
therein.
If I can change external settings so that running the program could
produce almost any number of recursions up to the limit of memory then
what is the point of the whole page ?
Howard Brazee
<wmk...@noreply.ix.netcom.com> wrote:
>It may be worth noting about IBM (mainframe) COBOL compilers for the last
>decade and a half (ever since VS COBOL II, R1.0 - if my memory is correct)
>actually MOVE perform code "inline" when the OPT compiler option is
>specified and some other situations occur. As I recall (and I could be
>mistaken on this) they do not (and cannot) do this for GO TO.
Now that is a fun fact. It's good to remember for a lot of choices
we make outside of programming to remember that as conditions change,
old rules and ways that were found to be best don't always stay the
best.
Clark F Morris
wrote:
>"Bill Klein" <wmk...@noreply.ix.netcom.com> wrote:
>
>> Also, his code stops because it uses "stack based" recursive PERFORMs.
>> There are other ways of implementing PERFORMs. It might (or might not)
>> require code changes, but it would be interesting to know what happens
>> with IBM COBOLs. I think the counter would loop past 999 AND the program
>> would only end on a "timeout. But I am saying this without actually
>> testing it, so I could be wrong.
>
>Bill,
>
>The last time I looked at this, recursive perform within a single source
>deck was impossible and did not work as intended. I debugged a failure in
>somebody else's code and I saw he was coding COBOL like a C programmer. As
>far as I know, recursive PERFORM is impossible because there is no stacking
>of calls the way PERFORM is compiled. Looking at the assembler code
>generated from a PERFORM, it's immediately obvious.
>
>I have not looked at the source referenced in your post, I am only speaking
>to the issue of whether PERFORM works recursively or not in IBM Enterprise
>COBOL.
>
>PERFORM is so bad for performance in the z/OS and prior architectures, it
>should really be used only very sparingly and not as a standard way of
>coding.
>
While there were certain recursive PERFORMS that would work on
pre-1985 standard IBM 360/370/390 series compilers, i.e. you could
PERFORM para-a and in para-a you could PERFORM para-a and it would
work, at best it would defeat the PERFORM optimization in 1985
standard and later compilers (VS COBOL II release 1.4 and newer). If
you have programs with single entry, single exit paragraphs (i.e.
there are only PERFORM statements as opposed to PERFORM THRU
statements) and those paragraphs can only be reached by a PERFORM as
opposed to a GO TO or a fall through, then compile with the OPTIMIZE
option and the appropriate listing option and look at the code
generated. It IS efficient.
Clark Morris