IBM mainframe compilers that I know about, do NOT "destroy" (aka free)
storage
when they cancel a (dynamically called) subprogram. They do place its
working-storage in "initial state" the next time it is called.
(Statically
linked programs don't even do this - which is why IBM do***ents that you
must
compile with DYNAM to be standard-conforming.)
As I recall (but I'll admit that I didn't look this up) Micro Focus has a
"run-time" switch to determine whether storage is or is not freed by a
CANCEL
statement. I think (but again haven't confirmed this) that I have heard
of
other compilers that also have a "storage freeing" option for CANCEL. The
Standard (current and past) is/has always been silent on this issue, i.e.
a
conforming compiler MAY but need not free storage on a CANCEL.
Like ODO itself, the standard is really pretty "neutral" on how
implementations
handle storage. Behavior (at run-time) is defined, but IN GENERAL, not
how an
implementer reaches such behavior.
--
Bill Klein
wmklein <at> ix.netcom.com
"SeaSideSam" <SeaSideSam@[EMAIL PROTECTED]
> wrote in message
news:bdb4c$47d9906d$6214df95$20628@[EMAIL PROTECTED]
> robert. it took me a while but i finally removed all the 'personal'
stuff and
> what remained was this....
> ******************************
> If my program, loaded and running, CALLs a subroutine for the first
> then it will create a new working-storage for that. When I CANCEL it
> will destroy that area and make it available for reuse by another.
>
> This could happen even if the program was linked so that the program
> code loaded with the run unit.
>
> In OO COBOL a new object will dynamically create a new working-storage
> for itself.
> *********************************
>
> you make some claims here as if they were 'absolutes'. 'When I
CANCEL...' and
> 'In OO...' are the two i am refering to. i've noticed that you are a
> sensitive fellow so i'm letting it be known that i have no desire to get
in a
> pissing contest with you, but my 30+ years as a professional computer
> programmer taught me that there are few 'absolutes' when it comes to
hardware
> and software vendors and the way they 'interpret' and 'implement' a
standard.
>
> as an aside... i have yet to see an implementation that 'destroys'
anything
> other than a pointer when a called program returns control to the
calling
> program regardless of the method. any decent ibm assembler programmer
from
> the 70's or 80's could demonstrate this for you.
>
> with the exception of the personal stuff i am enjoying the exchange.
and
> since i haven't been paid to program for... geee... 15 years now... i
not only
> find the exchange informative but entertaining as well.
>
> have a good day.
>
> sss
>
>
>
> --------------= Posted using GrabIt =----------------
> ------= Binary Usenet downloading made easy =---------
> -= Get GrabIt for free from http://www.shemes.com/
=-
>
|
