Cobol - Re: Recursive Call

Author

Re: Recursive Call

Joe Zitzelberger

2005-11-09, 3:55 am

In article <dkgfnn$1a4n$1@si05.rsvl.unisys.com>,
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

> "Judson McClendon" <judmc@sunvaley0.com> wrote in message
> news:lNOaf.14$%k.4@bignews6.bellsouth.net...
>
> While recursion isn't a big issue for stack-oriented machines like the
> Unisys MCP systems -- on which the compiler has to go to the trouble to
> generate code to *prevent* recursion -- I believe there was some reluctance
> on the part of J4 to require it until it could be ascertained what the
> pitfalls were and what the appropriate syntax was.

I'm unfamiliar with a non-stack oriented, non-obsolete, machine that has
existed since the 85 standard was written.

Even the IBM mainframe, originally a non-stack machine, made hardware
allowances for stack-style things (e.g. Program Call & Return) somewhere
in the 70's.

Stack machines really have proven their worth over non-stack machines.
What isn't at least simulating a stack these days?

Arnold Trembley

2005-11-09, 3:55 am

Joe Zitzelberger wrote:

> (snip)
> Even the IBM mainframe, originally a non-stack machine, made hardware
> allowances for stack-style things (e.g. Program Call & Return) somewhere
> in the 70's.

Program Call and Return was implemented on System 370 architecture
without hardware or software stacks, to the best of my knowledge. And
even today, IBM Z-series mainframes still do not have hardware
stacks, as far as I know. Perhaps someone can correct me if my
impression is wrong.

--
http://arnold.trembley.home.att.net/

Michael Wojcik

2005-11-09, 6:55 pm

In article <HZfcf.64578$zb5.43562@bgtnsc04-news.ops.worldnet.att.net>, Arnold Trembley <arnold.trembley@worldnet.att.net> writes:
>
> Joe Zitzelberger wrote:
>
>
> Program Call and Return was implemented on System 370 architecture
> without hardware or software stacks, to the best of my knowledge. And
> even today, IBM Z-series mainframes still do not have hardware
> stacks, as far as I know.

Even if zSeries doesn't have a "hardware" stack (which I imagine to
mean opcodes for pushing and popping values, and a register which is
either reserved or used by convention as a stack pointer), I believe
Joe's correct that pretty much all general-purpose systems these
days at least provide some stack mechanism as part of their standard
ABI.

That's no doubt due in part to the popularity of C. C can be
implemented without a classic contiguous stack - for example using
chained activation records - but the language treats function calls,
function parameters and return values, and automatic variable
allocation and deallocation in a stack-oriented fashion, so some
relatively efficient stack mechanism is a must for a reasonable C
implementation.

There are no doubt still small embedded systems that do not provide
a stack, but these days even most embedded machines are programmed
in C or another high-level language with similar requirements.

--
Michael Wojcik michael.wojcik@microfocus.com

Do we have boyfriends? We are interested in delicious food and sweets.
And tiny animals like the cat. -- Naoko Yamano

2005-11-09, 6:55 pm

In article <dkt1h402c2f@news4.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:

[snip]

>There are no doubt still small embedded systems that do not provide
>a stack, but these days even most embedded machines are programmed
>in C or another high-level language with similar requirements.

This brings up a point about which I may have made an error someplace
else... so I might as well try to get information here that I might
correct myself, delicately.

The fellow with whom I was conversing mentioned use of the stack-trace in
debugging; I said that this was not, in my experience, a common method
applied to IBM-architecture mainframes. I based this on my experience as
a mere apps-jockey; when something blows up I look for the PSW, find the
address of the previous statement and proceed from there.

This ignores - in the radical sense of 'in (not) gnosis' - what folks at
the systems level do. Is there something akin to stack tracing done on
Big Blue Big Iron running 'classic' (COBOL/CICS/DB2) systems?

DD

Michael Wojcik

2005-11-11, 6:55 pm

In article <dktc9l$169$1@reader2.panix.com>, docdwarf@panix.com () writes:
>
> The fellow with whom I was conversing mentioned use of the stack-trace in
> debugging; I said that this was not, in my experience, a common method
> applied to IBM-architecture mainframes. I based this on my experience as
> a mere apps-jockey; when something blows up I look for the PSW, find the
> address of the previous statement and proceed from there.
>
> This ignores - in the radical sense of 'in (not) gnosis' - what folks at
> the systems level do. Is there something akin to stack tracing done on
> Big Blue Big Iron running 'classic' (COBOL/CICS/DB2) systems?

I was curious to see answers to this, but it doesn't appear that you've
had any takers.

I've not done much debugging of mainframe systems-level code, but the
folks I've seen do it generally start with a dump, and do sometimes
manually backtrack through subroutine calls. These programs were
mostly written in assembly, and they used some variant of BAL (branch
and link) for subroutine calls, and maintained their own scratch
areas for return addresses, parameters, and so forth. So there was
no contiguous "stack" as there is on x86 and the like, but they did
sometimes trace the flow of execution back using the dump.

--
Michael Wojcik michael.wojcik@microfocus.com

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas

2005-11-11, 6:55 pm

In article <dl2hl00kku@news4.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:
>
>In article <dktc9l$169$1@reader2.panix.com>, docdwarf@panix.com () writes:

[snip]

>
>I was curious to see answers to this, but it doesn't appear that you've
>had any takers.

Oh, that's only because I add nothing but noise to the newsgroup... and
the questions I ask are so *hard*, too!

>
>I've not done much debugging of mainframe systems-level code, but the
>folks I've seen do it generally start with a dump, and do sometimes
>manually backtrack through subroutine calls. These programs were
>mostly written in assembly, and they used some variant of BAL (branch
>and link) for subroutine calls, and maintained their own scratch
>areas for return addresses, parameters, and so forth. So there was
>no contiguous "stack" as there is on x86 and the like, but they did
>sometimes trace the flow of execution back using the dump.

That's what I recall from what I learned of Assembley code, aye... you
always started out with a BALR, a USING and somewhere near the top there'd
be something like ST R14,SAVEAREA to stash away the return address... but
nothing physically built into the system that one would call a 'stack'.

Thanks much.

DD

charles hottel

2005-11-11, 6:55 pm

On IBM mainframes there was/is a standard linkage convention to be followed
that uses a standard 18 fullword save area and certain standard register
usage conventions. Register 15 contains the "branch to" address and Register
14 contains the "Return address". So to "call" another program you would do
something like:

L R15,=V(MYSUBRTN)
BALR R14,R15

Another part of this linkage convention is that the calling program provide
within its storage an 18 fullword save area that the subroutine can use to
save the callers registers. The standard is that Register 13 will point to
this save area at entry to the subroutine. The save areas themselves
contain standard offsets where the register contents are saved plus there
are forward/backward pointers that chain the save areas together into a
linked list stack. Usually the first thing a subroutine does is save the
caller's registers and set register 13 to point to it's save area. When an
abend occurs a save area trace is produced in the dump and shows the call
chain. In assembly language there are SAVE and RETURN macros and the RETURN
macros has an option that can be used to set a bit in the save area to
indicate to the dump program that a save area is no longer active. When a
subroutine ends it restores the callers registers and branches to the return
address.

Of course all of the above was the original convention. As IBM hardware and
addressing modes have evolved there are more/different linkage instructions
and branching instructions. Some of these use a linkage stack area and
there are instructions that are used to access and manipulate it. Some work
with 31-bit addressing and others work with 64-bit addressing. With 64 bit
addressing the save area layout had to be modified to accommodate the larger
addresses and larger/wider registers.

This is a pretty standard process for all the machines that I have worked on
and each has it standard entry/exit magic instruction sequences to
accomplish this. Also not mentioned, there is usually a standard way to
pass parameters to the subroutine. I believe that on the IBM mainframe COBOL
follows the convention when subprograms are CALLed.

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dl2hl00kku@news4.newsguy.com...
>
> In article <dktc9l$169$1@reader2.panix.com>, docdwarf@panix.com () writes:
>
> I was curious to see answers to this, but it doesn't appear that you've
> had any takers.
>
> I've not done much debugging of mainframe systems-level code, but the
> folks I've seen do it generally start with a dump, and do sometimes
> manually backtrack through subroutine calls. These programs were
> mostly written in assembly, and they used some variant of BAL (branch
> and link) for subroutine calls, and maintained their own scratch
> areas for return addresses, parameters, and so forth. So there was
> no contiguous "stack" as there is on x86 and the like, but they did
> sometimes trace the flow of execution back using the dump.
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> Auden often writes like Disney. Like Disney, he knows the shape of
> beasts --
> (& incidently he, too, might have a company of artists producing his
> lines) --
> unlike Lawrence, he does not know what shapes or motivates these beasts.
> -- Dylan Thomas

Joel C. Ewing

2005-11-12, 6:55 pm

Arnold Trembley wrote:
>
>
> Joe Zitzelberger wrote:
>
>
>
> Program Call and Return was implemented on System 370 architecture
> without hardware or software stacks, to the best of my knowledge. And
> even today, IBM Z-series mainframes still do not have hardware stacks,
> as far as I know. Perhaps someone can correct me if my impression is
> wrong.
>
>

At least on ESA architecture and later the PROGRAM CALL and related
instructions do indeed use hardware-supported stacks, the Linkage Stack,
which is allocated in 64 KiB blocks and tracked via hardware control
registers. The Program Call instruction and its management complexity
is generally hidden from application code, as it main (only?) usage from
the application code standpoint is to issue function requests to the
operating system that previously would have required using SVC
Supervisor Calls.
--
Joel C. Ewing, Fort Smith, AR jREMOVEcCAPSewing@acm.org

Sponsored Links