That, Victor, could still require "IS RECURSIVE" on the PROGRAM-ID to avoid the
abend with the IGZ0064S message (because the "handler" is invoked from the same
program), depending the linkedit/binder RENT/REUS values. So it doesn't make it
any simpler at the level of the mechanics.
Also, when e
Chuck,
Just another weird suggestion which may [or may not] work in your case - why
can't the very SAME entry point also serve as the error handler?
I mean, it is being called with a parameter list, so by parsing the input
parameters can't it determine the exact reason for call?
And if it's fo
Yes, it is documented that a contained/nested program cannot have an ENTRY,
and, separately that a contained/nested program cannot be used for an LE
Condition Handler.
--
For IBM-MAIN subscribe / signoff / archive access instruc
sted COBOL subprogram.
From: IBM Mainframe Discussion List on behalf of
Farley, Peter x23353
Sent: Thursday, August 11, 2016 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does COBOL detect a recursive call?
John,
Using the COBOL "nested programs"
wn
Sent: Thursday, August 11, 2016 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does COBOL detect a recursive call?
> Excluding cursing, and including recursing.
>
> Any IT management who chooses that route over
> TwoSimpleProgramsWithNothingButOrdinaryCodeCompile/
> Link
n List on behalf of
John McKown
Sent: Thursday, August 11, 2016 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does COBOL detect a recursive call?
On Thu, Aug 11, 2016 at 12:48 AM, Bill Woodger
wrote:
> On Thursday, 11 August 2016 01:47:07 UTC+2, John McKown wrote:
> ...>
> >
Yes, I'd not suggest compiling two separate programs as a single source, except
for the idea that they (the Manglerment) seem to want it done in one "program".
I'd kind of hope it doesn't fit into their procedures either - even though it
is as "logically equivalent" to the ENTRY idea as it is th
On Thu, Aug 11, 2016 at 12:48 AM, Bill Woodger
wrote:
> On Thursday, 11 August 2016 01:47:07 UTC+2, John McKown wrote:
> ...>
> > Hum, I would guess this will be a case of "20 lines of code and 200
> lines
> > of comments (excluding cursing)"
> >
> >
> >
> > >
>
> Excluding cursing, and includ
On Thursday, 11 August 2016 01:47:07 UTC+2, John McKown wrote:
...>
> Hum, I would guess this will be a case of "20 lines of code and 200 lines
> of comments (excluding cursing)"
>
>
>
> >
Excluding cursing, and including recursing.
Any IT management who chooses that route over
TwoSimpleP
On Wed, Aug 10, 2016 at 4:04 PM, Bill Woodger
wrote:
> Thanks, Chuck. Tough sitch.
>
> I think as definitive as you are going to get, in a documentary sense, is
> this, from the Programming Guide (doesn't matter which version):
>
> "Calling alternate entry points
>
> Static calls to alternate ent
Thanks, Chuck. Tough sitch.
I think as definitive as you are going to get, in a documentary sense, is this,
from the Programming Guide (doesn't matter which version):
"Calling alternate entry points
Static calls to alternate entry points work without restriction."
I made a static CALL to an E
On Tue, Aug 9, 2016 at 5:52 PM, Bill Woodger wrote:
> OK, it is the RENT or REUS (either will do) on the link-edit/bindering.
>
> Without RENT/REUS you get a new executable for free. With RENT/REUS you
> get to "share" the original program, but it is necessarily a "recursive"
> use, so you get th
@LISTSERV.UA.EDU] On Behalf
Of Bill Woodger
Sent: Wednesday, August 10, 2016 6:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How does COBOL detect a recursive call?
Hi Chuck,
Thanks. Yes, I was able to recreate the issue after making the post with the
questions in.
RENT,REUS or REUS or RENT, ie any
On Wed, Aug 10, 2016 at 12:16 AM, Peter Hunkeler wrote:
>
>
> > I'm a bit OCD about trying to make all my code RENT,REUS. My main way to
> think of this is "would this still run correctly if it were burned into
> ROM?" I try to make the answer to that YES.
>
>
> Put all your RENT modules into an
Hi Chuck,
Thanks. Yes, I was able to recreate the issue after making the post with the
questions in.
RENT,REUS or REUS or RENT, ie any combinaton, on the linkediting/bindering
causes no new executable to be loaeded in this case, so tha ALIASed ENTRY is in
the same executable as the CALL.
Thi
ject: How does COBOL detect a recursive call?
OK, it is the RENT or REUS (either will do) on the link-edit/bindering.
Without RENT/REUS you get a new executable for free. With RENT/REUS you get to
"share" the original program, but it is necessarily a "recursive" use, so yo
> I'm a bit OCD about trying to make all my code RENT,REUS. My main way to
> think of this is "would this still run correctly if it were burned into ROM?"
> I try to make the answer to that YES.
Put all your RENT modules into an APF authorized load library. No AC(1)
required! The code wi
OK, it is the RENT or REUS (either will do) on the link-edit/bindering.
Without RENT/REUS you get a new executable for free. With RENT/REUS you get to
"share" the original program, but it is necessarily a "recursive" use, so you
get the "IGZ0064S A recursive call to active program..." message. W
Thanks :-)
Looks like your LE has about 10 levels of "depth". The handler is getting
invoked, and then itself abending/raising a condition, so it gets invoked
again, and does the same thing - until LE runs out of patience that was defined
for it.
The IGZMSG is the module which informs of a run
On Tue, Aug 9, 2016 at 4:23 PM, Bill Woodger wrote:
> Reading your post rather than going from the title, the U4087 2 is
> Language Environment abend for when an registered abend-handler has been
> entered a subsequent time before processing of the original abend has
> completed - the handler wri
Reading your post rather than going from the title, the U4087 2 is Language
Environment abend for when an registered abend-handler has been entered a
subsequent time before processing of the original abend has completed - the
handler written in COBOL failed, and was entered again to process the
On Tue, Aug 9, 2016 at 11:28 AM, Mike Schwab
wrote:
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/
> com.ibm.zos.v2r1.ieab100/reus.htm
> When you link edit, you indicate the re-usability of the program.
> When the program runs, it reuses the same program if re-entrant. Each
> use has
Well, the SET ... TO ENTRY ... definitely loads (with the assumption that the
module is not already in memory, in which case it just gives you the
entry-point address). At least ordinarily. I don't know about the ENTRY which
is in the same program. An ENTRY in a different program (with an ALIAS)
2016 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does COBOL detect a recursive call?
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/reus.htm
When you link edit, you indicate the re-usability of the program.
When the program runs, it reuses the same pr
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/reus.htm
When you link edit, you indicate the re-usability of the program.
When the program runs, it reuses the same program if re-entrant. Each
use has a different set of registers and working storage.
Serially reusa
Conceptually, it sets a flag at the start of execution, and resets it when the
GOBACK (or other way to get out of a program) is processed.
Prior to setting the flag it tests to see if it is still (already) set. If so,
the program has been entered recursively, either directly or by CALLing (or
o
On Tue, Aug 9, 2016 at 9:40 AM, John McKown
wrote:
> This is a kind of curiosity question. Unless a COBOL program is compiled
> with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
> program cannot CALL itself. I have also found out that if you use an ENTRY
> statement and the c
This is a kind of curiosity question. Unless a COBOL program is compiled
with the THREAD option and the RECURSIVE clause on the PROGRAM-ID, the
program cannot CALL itself. I have also found out that if you use an ENTRY
statement and the compile NAME(ALIAS), you cannot do a CALL of the alias
from th
28 matches
Mail list logo
