Home > Archive > Cobol > July 2006 > Attribute BASED and LINKAGE SECTION
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]
| Author |
Attribute BASED and LINKAGE SECTION
|
|
| Roger While 2006-06-26, 7:55 am |
| Need some enlightenment here.
Isn't a LINKAGE SECTION item implicitly BASED ?
If not, why not. If so, what does BASED do ?
Roger
| |
| Frank Swarbrick 2006-06-26, 6:55 pm |
| >>>> Roger While<simrw@sim-basis.de> 06/26/06 5:08 AM >>>
>Need some enlightenment here.
>Isn't a LINKAGE SECTION item implicitly BASED ?
>If not, why not. If so, what does BASED do ?
You and me both, brother!
My personal thought, and I believe this is also the view of the 2002
standard (*), is that the LINKAGE section should be used strictly for that;
linkage between a calling program and a called program. Dynamically
allocated (ALLOCATE verb or other method) storage should be assigned to
either a WORKING-STORAGE SECTION based data item or a LOCAL-STORAGE SECTION
based data item, depending on whether or not you want the reference to
survive between calls.
(*) "13.6 Linkage section
The linkage section describes formal parameters and returning items.
Formal parameters and returning items described in the linkage section of a
source element are referred to both
by that source element, when it is activated, and by the activating source
element."
But I certainly would love to know the difference, if any, between a based
local-storage item and a based linkage item. Take the following....
local-storage section.
01 local-based pic x(80) based.
linkage section.
01 linkage-parm1 pic x(80).
01 linkage-based pic x(80) based.
procedure division using linkage-parm1.
allocate local-based
allocate linkage-based
* do stuff here
exit program.
The use of the linkage-based item in this manner seems, to be, to be in
conflict with statement 13.6 above. However there is the (rather vague, it
seems to me) statement 13.6.2-4 "A based data item may be referenced as
described in 13.16.5, BASED clause;...".
Then there's the following:
"14.1.2 Syntax rules
FORMATS 1 AND 2
1) Data-name-1 shall be defined as a level 01 entry or a level 77 entry in
the linkage section. A particular
user-defined word shall not appear more than once as data-name-1. The data
description entry for
data-name-1 shall not contain a BASED clause or a REDEFINES clause.
NOTES
1 This restriction for based items does not prohibit passing based items as
arguments.
2 A data item defined subsequently in the linkage section may specify
REDEFINES data-name-1."
This latter statement says to me that the following is not allowed (and I
agree should not be allowed):
linkage section.
01 linkage-based pic x(80) based.
procedure division using linkage-based.
If one were to allow it then it would also allow "set address of
linkage-based to a-pointer", which doesn't really make sense since
linkage-based was already assigned an address via the PROCEDURE DIVISION
USING phrase.
The only reason I can see for allowing the based clause at all in a linkage
section data item it is that many of the current COBOL implementations, most
(all?) of which do not support the BASED data-division clause, allow linkage
section items that are not specified in the PROCEDURE DIVISION
USING...RETURNING statement to have addressability established by assigning
a pointer value to it via the ADDRESS OF convention. To make this "2002
compliant" one would have to only add the requirement that the BASED clause
be specified. (Or perhaps, as you say, it could be implicitly assumed,
though I don't think it would be 100% compliant in that case.)
It is interesting to note that it appears that the following *is* allowed:
program-id. my-subr.
linkage section.
01 based-return pic x(80) based.
procedure division returning based-return.
Does that mean that you could continue the procedure division as follows?
allocate based-return
exit program.
and then call it as follows?
program-id. my-main.
working-storage section.
01 my-based pic x(80) based.
procedure division.
call 'my-subr' returning my-based
* my-based now addresses the storage allocated by the my-subr subprogram
I'm not sure if this would or even should work. Seems to me that the call
would still have pass "address of my-based" and not just "based", but then
it doesn't look link the descriptions of the returning items match. Or do
they, since one could think of a based item as being an implicit pointer.
Or something like that. Argh, confusing!
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Rick Smith 2006-06-26, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4gaf0dF1m0jsdU1@individual.net...
[snip]
> It is interesting to note that it appears that the following *is* allowed:
> program-id. my-subr.
> linkage section.
> 01 based-return pic x(80) based.
> procedure division returning based-return.
No, that is prohibited. See 14.1.2 Syntax rules,
"5) Data-name-2 shall be defined as a level 01 entry
or level 77 entry in the linkage section. The data description
entry for data-name-2 shall not contain a BASED clause
or a REDEFINES clause."
Data-name-2 refers to the parameter in a RETURNING
phrase.
| |
| Rick Smith 2006-06-26, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7of6i$ouj$02$1@news.t-online.com...
> Need some enlightenment here.
> Isn't a LINKAGE SECTION item implicitly BASED ?
> If not, why not. If so, what does BASED do ?
Only if it has a TYPE clause and the typedef contains the
BASED clause.
....
linkage section.
1 my-based-type typedef based.
...
1 based-1 type my-based-type.
1 based-2 type my-based-type based.
....
Here based-1 is implicitly based while based-2 is
explicitly based.
| |
| Frank Swarbrick 2006-06-26, 6:55 pm |
| Rick Smith<ricksmith@mfi.net> 06/26/06 11:23 AM >>>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4gaf0dF1m0jsdU1@individual.net...
>[snip]
allowed:[color=darkred]
>
>No, that is prohibited. See 14.1.2 Syntax rules,
>"5) Data-name-2 shall be defined as a level 01 entry
>or level 77 entry in the linkage section. The data description
>entry for data-name-2 shall not contain a BASED clause
>or a REDEFINES clause."
>
>Data-name-2 refers to the parameter in a RETURNING
>phrase.
Boy am I blind. I saw the reference to data-name-1 but not data-name-2.
Thanks,
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-06-26, 6:55 pm |
| Basically, you are "confusing" the current implementations (as extensions) of
"programmatically addressed data" with the ALLOCATE and BASED features of the
'02 Standard.
No, in the '02 Standard Linkage Section items are not "implicitly" BASED - but
can have the BASED attribute (as can WS and Local-Storage) items.
As stated in another post, the Linkage Section (in the '02 Standard - and the
'85 Standard - but not most existing implementations) is LIMITED to
"communication" between programs (or functions or whatever)
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7of6i$ouj$02$1@news.t-online.com...
> Need some enlightenment here.
> Isn't a LINKAGE SECTION item implicitly BASED ?
> If not, why not. If so, what does BASED do ?
>
> Roger
>
| |
| Frank Swarbrick 2006-06-26, 6:55 pm |
| Not to repeat myself (or perhaps you don't know the answer), but is there
any discernable difference between a based data item declared in the
local-storage section and a based data item declared in the linkage section
(and not used in the USING or RETURNING clause of the PROCEDURE DIVISION
header)?
Frank
Basically, you are "confusing" the current implementations (as extensions)
of
"programmatically addressed data" with the ALLOCATE and BASED features of
the
'02 Standard.
No, in the '02 Standard Linkage Section items are not "implicitly" BASED -
but
can have the BASED attribute (as can WS and Local-Storage) items.
As stated in another post, the Linkage Section (in the '02 Standard - and
the
'85 Standard - but not most existing implementations) is LIMITED to
"communication" between programs (or functions or whatever)
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7of6i$ouj$02$1@news.t-online.com...[color=darkred]
> Need some enlightenment here.
> Isn't a LINKAGE SECTION item implicitly BASED ?
> If not, why not. If so, what does BASED do ?
| |
| William M. Klein 2006-06-26, 6:55 pm |
| I have NOT looked this up and I certainly won't swear to what the answer is,
but I would look at whether "addressability" is maintained
A) across calls, e.g.
A Calls B, B sets addressability, B exits to A, A calls B again
B) when recursion is used is addressability maintained, e.g.
A Calls B, B sets addressability, B calls C, C calls B
And for "B", is it "pusshed and popped" as other Local-Storage "values" are?
I am off for the evening, so I'll try and check this later. My best GUESS is
that they do work differently, but that is only a guess.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4gba0iF1mhuj4U1@individual.net...
> Not to repeat myself (or perhaps you don't know the answer), but is there
> any discernable difference between a based data item declared in the
> local-storage section and a based data item declared in the linkage section
> (and not used in the USING or RETURNING clause of the PROCEDURE DIVISION
> header)?
>
> Frank
>
> Basically, you are "confusing" the current implementations (as extensions)
> of
> "programmatically addressed data" with the ALLOCATE and BASED features of
> the
> '02 Standard.
>
> No, in the '02 Standard Linkage Section items are not "implicitly" BASED -
> but
> can have the BASED attribute (as can WS and Local-Storage) items.
>
> As stated in another post, the Linkage Section (in the '02 Standard - and
> the
> '85 Standard - but not most existing implementations) is LIMITED to
> "communication" between programs (or functions or whatever)
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e7of6i$ouj$02$1@news.t-online.com...
>
>
>
| |
| Roger While 2006-06-27, 3:55 am |
| Let's see if I get this -
In the LINKAGE SECTION, if a top-level item
is NOT referred to in the USING clause of the
PROCEDURE DIVISION, then it MUST have
the BASED attribute - correct ?
If so, why ? - The item is implicitly BASED and therefore
the BASED attribute should be optional or ?
Also, is it correct that top-level items in LINKAGE
whether formal USING params or BASED may be used directly in
SET ADDRESS OF LS-ITEM TO ....
Seems like it should be as they are both of CATEGORY data-pointer or ?
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:bUYng.389357$W33.238485@fe03.news.easynews.com...
> Basically, you are "confusing" the current implementations (as extensions)
> of "programmatically addressed data" with the ALLOCATE and BASED features
> of the '02 Standard.
>
> No, in the '02 Standard Linkage Section items are not "implicitly"
> BASED - but can have the BASED attribute (as can WS and Local-Storage)
> items.
>
> As stated in another post, the Linkage Section (in the '02 Standard - and
> the '85 Standard - but not most existing implementations) is LIMITED to
> "communication" between programs (or functions or whatever)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e7of6i$ouj$02$1@news.t-online.com...
>
>
| |
| Rick Smith 2006-06-27, 7:55 am |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7qs9j$do9$02$1@news.t-online.com...
> Let's see if I get this -
> In the LINKAGE SECTION, if a top-level item
> is NOT referred to in the USING clause of the
> PROCEDURE DIVISION, then it MUST have
> the BASED attribute - correct ?
> If so, why ? - The item is implicitly BASED and therefore
> the BASED attribute should be optional or ?
>
> Also, is it correct that top-level items in LINKAGE
> whether formal USING params or BASED may be used directly in
> SET ADDRESS OF LS-ITEM TO ....
> Seems like it should be as they are both of CATEGORY data-pointer or ?
The linkage section may contain three types of entries:
77-level-entry, constant-entry, and record-description-entry.
A constant-entry does not contain a BASED clause.
A record-description-entry that contains a TYPEDEF
clause may also contain a BASED clause.
A 77-level-entry or record-description-entry identified
in the procedure-division-header shall not contain a
BASED clause.
A 77-level-entry or record-description-entry that contains
a BASED clause may be associated with storage by using
an ALLOCATE statement or the data-pointer-assignment
format of the SET statement (specifically SET ADDRESS).
Otherwise the item is inaccessible.
Note, in particular, for 2002, 14.8.35.2 [SET statement]
Syntax rules, for SET ADDRESS OF data-name-1 ...,
"18) Data-name-1 shall be a based data item." and
8.6.4 Based entries and based data items, A based entry
is a data description entry in the working-storage section,
local-storage section, or linkage section that is described
with a BASED clause."; therefore any use of this format
of the SET statement not in conformance with the standard
is an extension.
Also note in,
....
linkage section.
77 a-pointer usage pointer.
procedure division using a-pointer.
....
a-pointer is category data-pointer by its usage but it does
not have associated with it an implicit data-address pointer
that would also be category data-pointer. However, it does
have an address that may be accessed with
SET a-pointer-address TO ADDRESS OF a-pointer
where a-pointer-address is defined with USAGE POINTER.
Interestingly, the address of a-pointer is not necessarily the
same as the address of the corresponding argument in the
activating run time element due to 14.1.3 [Procedure division
structure] General rules, "8) If the argument is passed by
reference, the activated runtime element operates as if the
formal parameter occupies the same storage area as the
argument." and "9) If the argument is passed by content, the
activated runtime element operates as if the record in the
linkage section were allocated by the activating runtime
element during the process of initiating the activation and as
if this record does not occupy the same storage area as the
argument in the activating runtime element."
Under GR 8, the argument could be moved to a temporary
location, the call made, and the content of the temporary
location moved back to the original location of the argument.
Under GR 9, changes in the temporary location would not
be moved to the original location.
| |
| Rick Smith 2006-06-27, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4gba0iF1mhuj4U1@individual.net...
> Not to repeat myself (or perhaps you don't know the answer), but is there
> any discernable difference between a based data item declared in the
> local-storage section and a based data item declared in the linkage
section
> (and not used in the USING or RETURNING clause of the PROCEDURE DIVISION
> header)?
In my research, thus far, I can find no statements
that tell whether a based item in the linkage section
should be treated as static or automatic data. This
distinction is important in the case of a recursive
program. If it is treated as static data, then it should
behave the same as a based item in the
working-storage section. If it is treated as automatic
data, then it should behave the same as a based item
in the local-storage section.
There is 8.6.4 Based entries and based data items
which states, in part, "The association ends: ...
- when the based entry is defined in the linkage
section, at the end of the execution of the runtime
element.";
but it is not clear, to me, whether "the end of the
execution of the runtime element" refers to only the first
or to each instance of a recursive program.
In my opinion, treating based item in the linkage
section the same as automatic data is more useful.
| |
| Frank Swarbrick 2006-06-27, 6:55 pm |
| What do you intend that the following would do?
linkage section.
01 ls-parm1 pic x(80).
procedure division using ls-parm1.
set address of ls-parm1 to some-pointer.
move 'abcd' to ls-parm1
exit program.
Since you cannot change the address of a working-storage item, what should
happen if the above is called with
call 'sub-prog' using ws-data
From the 200x standard (I have 2002 at home but keep forgetting to make a
work copy) 14.8.35.2-18, refering to "SET ADDRESS OF data-name-1 TO
identifier-6". states: "Data-name-1 shall be a based data item".
So this disallows the above, in any case.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Let's see if I get this -
In the LINKAGE SECTION, if a top-level item
is NOT referred to in the USING clause of the
PROCEDURE DIVISION, then it MUST have
the BASED attribute - correct ?
If so, why ? - The item is implicitly BASED and therefore
the BASED attribute should be optional or ?
Also, is it correct that top-level items in LINKAGE
whether formal USING params or BASED may be used directly in
SET ADDRESS OF LS-ITEM TO ....
Seems like it should be as they are both of CATEGORY data-pointer or ?
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:bUYng.389357$W33.238485@fe03.news.easynews.com...[color=darkred]
> Basically, you are "confusing" the current implementations (as extensions)
> of "programmatically addressed data" with the ALLOCATE and BASED features
> of the '02 Standard.
>
> No, in the '02 Standard Linkage Section items are not "implicitly"
> BASED - but can have the BASED attribute (as can WS and Local-Storage)
> items.
>
> As stated in another post, the Linkage Section (in the '02 Standard - and
> the '85 Standard - but not most existing implementations) is LIMITED to
> "communication" between programs (or functions or whatever)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e7of6i$ouj$02$1@news.t-online.com...
>
>
| |
| Frank Swarbrick 2006-06-27, 6:55 pm |
| Rick Smith<ricksmith@mfi.net> 06/27/06 8:44 AM >>>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4gba0iF1mhuj4U1@individual.net...
there[color=darkred]
>section
>
>In my research, thus far, I can find no statements
>that tell whether a based item in the linkage section
>should be treated as static or automatic data. This
>distinction is important in the case of a recursive
>program. If it is treated as static data, then it should
>behave the same as a based item in the
>working-storage section. If it is treated as automatic
>data, then it should behave the same as a based item
>in the local-storage section.
>
>There is 8.6.4 Based entries and based data items
>which states, in part, "The association ends: ...
>- when the based entry is defined in the linkage
> section, at the end of the execution of the runtime
> element.";
>but it is not clear, to me, whether "the end of the
>execution of the runtime element" refers to only the first
>or to each instance of a recursive program.
>
>In my opinion, treating based item in the linkage
>section the same as automatic data is more useful.
That is definitely very vague. For my changes to OpenCobol to support the
BASED clause I have defined working-storage based items as C-language (OC is
written in C) local static data [static unsigned char *b_a = NULL;] and
local-storage and linkage based items as local automatic data [unsigned char
*b_b = NULL;]. I have no idea what I might do to handle that statement in
8.6.4 about based data in the linkage section; whatever it may mean.
Anyway, its not important only for recursive calls but also for multiple
"iterative" calls. Taking the above definitions, if a main program called
multiple times a sub-program with the above data items b_a would retain its
value between calls (assuming that the program was not cancelled or defined
with the IS INITAL clause), while b_b would not. (I'm sure you know that.)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-06-27, 6:55 pm |
| I can't find where in this thread the question was asked about "persistance" of
BASED items wherever they are defined Linkage Section, but page 117 of the '02
Standard says,
"The association ends:
- when its implicit data-address pointer is set to a different value,
- when the based entry is defined in the working-storage or local-storage
section, at the end of the life cycle
of the data items defined in that section,
- when the based entry is defined in the linkage section, at the end of the
execution of the runtime element."
For anyone TRYING to create IBM or Micro Focus "compatibility" (for non-BASED
linkage section items), check out the Micro Focus "STICKY-LINKAGE" directive.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Rick Smith 2006-06-27, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4gd10iF1m6ml1U1@individual.net...
> Rick Smith<ricksmith@mfi.net> 06/27/06 8:44 AM >>>
[snip]
[snip][color=darkred]
>
> That is definitely very vague.
[snip]
>
> Anyway, its not important only for recursive calls but also for multiple
> "iterative" calls.
[snip]
14.8.13.3 [EXIT statement] General rules,
"6) The execution of an EXIT PROGRAM statement
causes the executing program to terminate, and control to
return to the calling statement. ...
7) The execution of an EXIT METHOD statement
causes the executing method to terminate, and control to
return to the invoking statement. ...
8) The execution of an EXIT FUNCTION statement
causes the executing function to terminate, and control to
return to the activating statement. ..."
This would seem to answer my question concerning "the
end of the execution of the runtime element" and, when
taken with the text of 8.6.4, would seem to suggest that
based items in the linkage section should behave in a
manner similar to local-storage for both recursive and
multiple non-recursive calls.
| |
| Michael Wojcik 2006-06-27, 6:55 pm |
|
In article <4gd10iF1m6ml1U1@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> Rick Smith<ricksmith@mfi.net> 06/27/06 8:44 AM >>>
>
> That is definitely very vague. For my changes to OpenCobol to support the
> BASED clause I have defined working-storage based items as C-language (OC is
> written in C) local static data [static unsigned char *b_a = NULL;] and
> local-storage and linkage based items as local automatic data [unsigned char
> *b_b = NULL;]. I have no idea what I might do to handle that statement in
> 8.6.4 about based data in the linkage section; whatever it may mean.
Considering other discussions of the "execution of the runtime
element" (eg in the discussion of the PROPAGATE directive), I believe
this means "execution of the current activation of the runtime
element", so the association would end when the current activation
ends - that is, for a recursive call, when the current call ends.
When the program returns to the activating statement (ie the
recursive call), the previous association would be restored.
In other words, it seems to me that based items in linkage should
be treated like automatic data, like local-storage based items.
--
Michael Wojcik michael.wojcik@microfocus.com
Thus, the black lie, issuing from his base throat, becomes a boomerang to
his hand, and he is hoist by his own petard, and finds himself a marked man.
-- attributed to a "small-town newspaper editor in Wisconsin"
| |
| Roger While 2006-06-28, 3:55 am |
| OpenCOBOL already has the STICKY-LINKAGE facility.
(Frank - check out codegen.c , difference is partly automatic
versus static declaration of the pointer).
Question is whether this should also be applied to BASED
LINKAGE items. I think yes.
Does the standard, as per Bill's quote below, imply that
an implicit FREE be done on EXITing the element ?
Consider a BASED LINKAGE item, prog does an ALLOCATE (on every entry):
1) There is no implicit FREE at EXIT.
The sy min is going to love your ever growing memory footprint.
2) There is an implicit FREE at exit
OK but what if we have set a WORKING-S pointer to the address
of the BASED item ?
Then we have the case with STICKY-LINKAGE.
In this case, of course, we should only ever do one ALLOCATE
and (1),(2) do not apply.
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:A0iog.411884$Bk2.187387@fe05.news.easynews.com...
>I can't find where in this thread the question was asked about
>"persistance" of BASED items wherever they are defined Linkage Section,
>but page 117 of the '02 Standard says,
>
> "The association ends:
> - when its implicit data-address pointer is set to a different value,
> - when the based entry is defined in the working-storage or local-storage
> section, at the end of the life cycle
> of the data items defined in that section,
> - when the based entry is defined in the linkage section, at the end of
> the execution of the runtime element."
>
> For anyone TRYING to create IBM or Micro Focus "compatibility" (for
> non-BASED linkage section items), check out the Micro Focus
> "STICKY-LINKAGE" directive.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
| |
| Rick Smith 2006-06-28, 7:56 am |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7t7ct$oub$03$1@news.t-online.com...
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:A0iog.411884$Bk2.187387@fe05.news.easynews.com...
[snip][color=darkred]
[snip][color=darkred]
> Does the standard, as per Bill's quote [above], imply that
> an implicit FREE be done on EXITing the element ?
No!
> Consider a BASED LINKAGE item, prog does an ALLOCATE (on every entry):
Instead, consider:
....
linkage section.
....
1 a-pointer pointer.
1 a-based type my-type.
procedure division using ... a-pointer.
set address of a-based to a-pointer
...
This is similar to (in ISO C) passing a pointer to void with
the SET statement being similar to a cast.
If the storage for a-based were freed on exit, the
runtime element would free storage it never allocated.
The standard is saying, in effect, that, upon exit, there
is no longer, in this case, any association between
a-based and a-pointer.
| |
| Roger While 2006-06-28, 6:55 pm |
| Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.t-online.com 1151506699 02 30923 z2U2vSeJJAK0qDi 060628 14:58:19
X-Complaints-To: usenet-abuse@t-online.de
X-ID: ZBbGVOZVoe5ELW2xSkLJ+Mg0I51H+A+DeLIs7tdx
qHeiixC0AjJPQu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:159437
No ??
So an ALLOCATE'd BASED LS item does an EXIT PROGRAM, the
association to memory is lost and the memory is therefore not reclaimable ?
I agree in your example that no action is necessary.
However, it would appear that ALLOCATE/FREE does require
some behind-the-scenes handling.
There is a reference to "implicit FREE" in the 2002/2008
under General rules (2) of the FREE verb.
?
Roger
"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:12a51gdgbj67mf6@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e7t7ct$oub$03$1@news.t-online.com...
> [snip]
> [snip]
>
> No!
>
>
> Instead, consider:
>
> ...
> linkage section.
> ...
> 1 a-pointer pointer.
> 1 a-based type my-type.
> procedure division using ... a-pointer.
> set address of a-based to a-pointer
> ...
>
> This is similar to (in ISO C) passing a pointer to void with
> the SET statement being similar to a cast.
>
> If the storage for a-based were freed on exit, the
> runtime element would free storage it never allocated.
>
> The standard is saying, in effect, that, upon exit, there
> is no longer, in this case, any association between
> a-based and a-pointer.
>
>
>
| |
| Frank Swarbrick 2006-06-28, 6:55 pm |
| Hmm, I just looked up the meaning of "sticky-linkage", and here's what I
find
PROCEDURE DIVISION:
STICKY-LINKAGE - controls whether addressability to Linkage Section items is
maintained between calls to different entry points in the same program.
ENTRY statement:
STICKY-LINKAGE - controls whether addressability to Linkage Section items is
maintained between calls to different entry points in the same program.
SET statement:
STICKY-LINKAGE - determines whether addresses of data items placed in
pointer data items by the SET statement are retained between invocations of
a subprogram.
Are the first two relevant to the COBOL 2002 standard? As far as I can
tell, COBOL 2002 does not support alternate entry points in any manner. So
it seems the first two usages above wouldn't relate to COBOL 2002. As for
the third one, it seems to me that that would be supported by based
working-storage.
As for implicit FREEs, I would say that, if that was to be done it would not
be done for based working-storage items but could be done for based
local-storage items. As for based linkage, well that depends on determining
what based linkage is.
This still doesn't address your point about a working-storage pointer
pointing to ALLOCATEd storage.
Are implicit FREEs even allowed per the standard? Or is the fact that they
are not disallowed mean they could be implemented. Seems to me you'd *have*
to implement some type of garbage collection process to make this feasible
at all.
Hmmm...
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
OpenCOBOL already has the STICKY-LINKAGE facility.
(Frank - check out codegen.c , difference is partly automatic
versus static declaration of the pointer).
Question is whether this should also be applied to BASED
LINKAGE items. I think yes.
Does the standard, as per Bill's quote below, imply that
an implicit FREE be done on EXITing the element ?
Consider a BASED LINKAGE item, prog does an ALLOCATE (on every entry):
1) There is no implicit FREE at EXIT.
The symin is going to love your ever growing memory footprint.
2) There is an implicit FREE at exit
OK but what if we have set a WORKING-S pointer to the address
of the BASED item ?
Then we have the case with STICKY-LINKAGE.
In this case, of course, we should only ever do one ALLOCATE
and (1),(2) do not apply.
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:A0iog.411884$Bk2.187387@fe05.news.easynews.com...[color=darkred]
>I can't find where in this thread the question was asked about
>"persistance" of BASED items wherever they are defined Linkage Section,
>but page 117 of the '02 Standard says,
>
> "The association ends:
> - when its implicit data-address pointer is set to a different value,
> - when the based entry is defined in the working-storage or local-storage
> section, at the end of the life cycle
> of the data items defined in that section,
> - when the based entry is defined in the linkage section, at the end of
> the execution of the runtime element."
>
> For anyone TRYING to create IBM or Micro Focus "compatibility" (for
> non-BASED linkage section items), check out the Micro Focus
> "STICKY-LINKAGE" directive.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
| |
| Frank Swarbrick 2006-06-28, 6:55 pm |
| Michael Wojcik<mwojcik@newsguy.com> 06/27/06 5:24 PM >>>
>
>In article <4gd10iF1m6ml1U1@individual.net>, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> writes:
the[color=darkred]
is[color=darkred]
char[color=darkred]
in[color=darkred]
>
>Considering other discussions of the "execution of the runtime
>element" (eg in the discussion of the PROPAGATE directive), I believe
>this means "execution of the current activation of the runtime
>element", so the association would end when the current activation
>ends - that is, for a recursive call, when the current call ends.
>When the program returns to the activating statement (ie the
>recursive call), the previous association would be restored.
>
>In other words, it seems to me that based items in linkage should
>be treated like automatic data, like local-storage based items.
Which still begs the question (if I'm using that term correctly!), what is
the difference (if any) between based local-storage items and based linkage
items? And if there is no difference, why are the both specified by the
standard?
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-06-28, 6:55 pm |
| Well, I wouldn't say it's *lost*. Consider the following...
program-id. main-prog.
working-storage section.
01 my-data pic x(80) based.
01 my-pointer pointer.
procedure division.
perform 10 times
call 'sub-prog' using my-pointer
set address of my-data to my-pointer
display my-data
free my-pointer *> or free address of my-data
end-perform
stop run.
program-id. sub-prog.
working-storage section.
01 test-nbr pic 9999 value zero.
local-storage section.
01 local-data pic x(80) based.
linkage section.
01 ls-pointer pointer.
procedure division using ls-pointer.
allocate local-data returning ls-pointer
add 1 to test-nbr
string "test number " test-nbr into local-data
exit program.
end program sub-prog.
end program main-prog.
This should result in:
test number 0001
test number 0002
test number 0003
test number 0004
test number 0005
test number 0006
test number 0007
test number 0008
test number 0009
test number 0010
With all storage being freed (explicitly) once it is no longer needed.
Not necessarily a useful example, but I think it makes my point. In COBOL,
like in C, you have to keep track of allocated memory and make sure you free
it when you no longer need it, or before its addressability goes out of
scope.
One thing I just thought of, though, is that (I believe) even after the
"free my-pointer" is executed above, the address of my-data still points to
that freed storage area, since only the target of the FREE statement is set
to NULL.
As for what an "implicit FREE" is, I have no idea.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
[color=darkred]
No ??
So an ALLOCATE'd BASED LS item does an EXIT PROGRAM, the
association to memory is lost and the memory is therefore not reclaimable ?
I agree in your example that no action is necessary.
However, it would appear that ALLOCATE/FREE does require
some behind-the-scenes handling.
There is a reference to "implicit FREE" in the 2002/2008
under General rules (2) of the FREE verb.
?
Roger
| |
| Rick Smith 2006-06-28, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:e7u5eb$u6b$02$1@news.t-online.com...
> No ??
> So an ALLOCATE'd BASED LS item does an EXIT PROGRAM, the
> association to memory is lost and the memory is therefore not reclaimable
?
> I agree in your example that no action is necessary.
> However, it would appear that ALLOCATE/FREE does require
> some behind-the-scenes handling.
>
> There is a reference to "implicit FREE" in the 2002/2008
> under General rules (2) of the FREE verb.
> ?
14.8.14.3 [FREE statement] General rules
"2) If more than one data-name-1 is specified in a FREE
statement, the result of executing this FREE statement is
the same as if a separate FREE statement had been written
for each data-name-1 in the same order as specified
in the FREE statement. If an implicit FREE statement
results in the execution of a declarative procedure that
executes a RESUME statement with the NEXT
STATEMENT phrase, processing resumes at the next
implicit FREE statement, if any."
FREE ptr1 ptr2 is the same as FREE ptr1 FREE ptr2.
The "FREE" preceding ptr2, together with ptr2 is an
implicit FREE statement.
The rule that applies is:
14.8.3.3 [ALLOCATE statement] General rules,
"10) The allocated storage persists until explicitly released
with a FREE statement or the run unit is terminated,
whichever occurs first."
However, I do not believe this rule is so strict as to prevent
garbage collection when the programmer errors; that is, the
latter case is more to require that a COBOL implementation
behave well (clean-up after the programmer) if storage is
obtained from the operating system.
| |
| Michael Wojcik 2006-06-28, 6:55 pm |
|
In article <4gfn94F1n162fU2@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> Michael Wojcik<mwojcik@newsguy.com> 06/27/06 5:24 PM >>>
>
> Which still begs the question (if I'm using that term correctly!), what is
> the difference (if any) between based local-storage items and based linkage
> items? And if there is no difference, why are the both specified by the
> standard?
(I've lost track of just what bits of the standard have been cited in
this thread, so some of this may be repeating, to some extent, what
others have posted.)
I just took another look at 8.6.4 ("Based entries and based data
items"), and it says that for based items in local-storage, the
association ends "at the end of the life cycle of the data items
defined in that section", whereas for based items in linkage, it
ends "at the end of the execution of the runtime element".
If I'm correct about what the latter phrase means, then based items
in linkage always lose their association when the current activation
of the runtime element ends.
However, per 8.5.3 ("Automatic, initial, and static internal items"),
data items in local-storage always have automatic persistence, which
appears to mean that their life cycle always ends ... when the
current activation of the runtime element ends.
So it appears that based items in linkage and local-storage behave
the same.
I imagine that the committee may have introduced based local-storage
items as automatic based items, but also defined based linkage items
with the same behavior to simplify the migration of programs that use
popular vendor extensions for setting the address of linkage items.
(To answer your other question: In rhetoric, "beg the question"
means to phrase a question in a manner that suggests an answer, and
some prescriptivists claim that this is the only "correct" use.
Descriptivists, however, note that the meaning you employ here -
"prompt the question" - is well-established and widely recognized.
I avoid the latter usage myself, preferring to duel with my fellow
pedants over other trivia, but it's a common one.)
--
Michael Wojcik michael.wojcik@microfocus.com
The surface of the word "profession" is hard and rough, the inside mixed with
poison. It's this that prevents me crossing over. And what is there on the
other side? Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)
| |
| Roger While 2006-06-29, 7:55 am |
| Which still does not answer the question of whether
the memory acquired by an ALLOCATE for a
BASED LINKAGE/LOCAL item is automatically reaped.
(Taking into account possibly STICKY-LINKAGE).
And what (should) happen(s) when a BASED item is
subject to more than one ALLOCATE without an intervening FREE ?
Roger
"Michael Wojcik" <mwojcik@newsguy.com> schrieb im Newsbeitrag
news:e7us2j025s4@news3.newsguy.com...
>
> In article <4gfn94F1n162fU2@individual.net>, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> writes:
>
> (I've lost track of just what bits of the standard have been cited in
> this thread, so some of this may be repeating, to some extent, what
> others have posted.)
>
> I just took another look at 8.6.4 ("Based entries and based data
> items"), and it says that for based items in local-storage, the
> association ends "at the end of the life cycle of the data items
> defined in that section", whereas for based items in linkage, it
> ends "at the end of the execution of the runtime element".
>
> If I'm correct about what the latter phrase means, then based items
> in linkage always lose their association when the current activation
> of the runtime element ends.
>
> However, per 8.5.3 ("Automatic, initial, and static internal items"),
> data items in local-storage always have automatic persistence, which
> appears to mean that their life cycle always ends ... when the
> current activation of the runtime element ends.
>
> So it appears that based items in linkage and local-storage behave
> the same.
>
> I imagine that the committee may have introduced based local-storage
> items as automatic based items, but also defined based linkage items
> with the same behavior to simplify the migration of programs that use
> popular vendor extensions for setting the address of linkage items.
>
> (To answer your other question: In rhetoric, "beg the question"
> means to phrase a question in a manner that suggests an answer, and
> some prescriptivists claim that this is the only "correct" use.
> Descriptivists, however, note that the meaning you employ here -
> "prompt the question" - is well-established and widely recognized.
> I avoid the latter usage myself, preferring to duel with my fellow
> pedants over other trivia, but it's a common one.)
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> The surface of the word "profession" is hard and rough, the inside mixed
> with
> poison. It's this that prevents me crossing over. And what is there on
> the
> other side? Only what people longingly refer to as "the other side".
> -- Tawada Yoko (trans. Margaret Mitsutani)
| |
| Frank Swarbrick 2006-06-29, 6:55 pm |
| Michael Wojcik<mwojcik@newsguy.com> 06/28/06 3:24 PM >>>
>
>(I've lost track of just what bits of the standard have been cited in
>this thread, so some of this may be repeating, to some extent, what
>others have posted.)
>
>I just took another look at 8.6.4 ("Based entries and based data
>items"), and it says that for based items in local-storage, the
>association ends "at the end of the life cycle of the data items
>defined in that section", whereas for based items in linkage, it
>ends "at the end of the execution of the runtime element".
>
>If I'm correct about what the latter phrase means, then based items
>in linkage always lose their association when the current activation
>of the runtime element ends.
>
>However, per 8.5.3 ("Automatic, initial, and static internal items"),
>data items in local-storage always have automatic persistence, which
>appears to mean that their life cycle always ends ... when the
>current activation of the runtime element ends.
>
>So it appears that based items in linkage and local-storage behave
>the same.
>
>I imagine that the committee may have introduced based local-storage
>items as automatic based items, but also defined based linkage items
>with the same behavior to simplify the migration of programs that use
>popular vendor extensions for setting the address of linkage items.
That was my thought as well. And if that's the reason behind it, I'm fine
with it. I just want to make sure I'm not missing some subtle difference.
Anyway, unless someone can come up with an actual difference I will go ahead
and treat them the same.
>(To answer your other question: In rhetoric, "beg the question"
>means to phrase a question in a manner that suggests an answer, and
>some prescriptivists claim that this is the only "correct" use.
>Descriptivists, however, note that the meaning you employ here -
>"prompt the question" - is well-established and widely recognized.
>I avoid the latter usage myself, preferring to duel with my fellow
>pedants over other trivia, but it's a common one.)
Ah yes. I thought I was probably using it wrong, but I was too lazy to look
it up at the time.
Thanks,
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-06-29, 6:55 pm |
| I can only imagine that the based item would be assigned to the new storage,
and the old storage would be orphaned unless pointed to by another based
item or a data pointer. I just can't imagine that the data should be
automatically freed (unless one traces through every other data item to make
sure its not being referred to elsewhere). I just don't see any useful
middle ground between totally manual (programmatic) de-allocation and pretty
much full-blown garbage collection.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
[color=darkred]
Which still does not answer the question of whether
the memory acquired by an ALLOCATE for a
BASED LINKAGE/LOCAL item is automatically reaped.
(Taking into account possibly STICKY-LINKAGE).
And what (should) happen(s) when a BASED item is
subject to more than one ALLOCATE without an intervening FREE ?
| |
| Michael Wojcik 2006-07-05, 6:55 pm |
|
In article <e80iu1$gtn$03$1@news.t-online.com>, "Roger While" <simrw@sim-basis.de> writes:
> Which still does not answer the question of whether
> the memory acquired by an ALLOCATE for a
> BASED LINKAGE/LOCAL item is automatically reaped.
I don't see how it possibly can be. (Standard) COBOL does not
distinguish between calls to other COBOL programs and calls to non-
COBOL code. Allocated storage passed to the latter could not be
validly garbage-collected, since there's no way for the collector to
detect whether it's still in use. (Even conservative heuristic GCs
like Boehm can be fooled.)
Garbage collection only works in production environments when memory
"exported" outside the GC's domain is clearly flagged to the GC. Even
if the 2002 COBOL standard allows for GC (and I don't believe it does,
based on what I've read of it so far, though I admit that's only a
relatively small portion), the lack of explicit GC control would make
it unusable in a mixed-language program.
--
Michael Wojcik michael.wojcik@microfocus.com
They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James
| |
| William M. Klein 2006-07-08, 6:55 pm |
| Roger,
My understanding (and memory) is that
BASED (allocated) storage is NEVER required to be "freed" EXCEPT
- upon an explicit FREE
- or upon a STOP RUN
An implementation is "free" to do as much or as little "garbage" collection as
it might want. HOWEVER, you are required to "watch" for stored pointers.
Consider:
Allocate Based1 Returning Ptr1
Set Ptr2 to Ptr1
Call "Non-Cobol" Using Ptr1
Allocate Based2 Returning Ptr1
If you implicitly free the storage pointed to by the FIRST ptr1, then you better
be careful that "Non-COBOL" didn't do something to assume that it is still
available in future application use.
P.S. Is this good coding? NO - is it possible, yes!
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e80iu1$gtn$03$1@news.t-online.com...
> Which still does not answer the question of whether
> the memory acquired by an ALLOCATE for a
> BASED LINKAGE/LOCAL item is automatically reaped.
> (Taking into account possibly STICKY-LINKAGE).
>
> And what (should) happen(s) when a BASED item is
> subject to more than one ALLOCATE without an intervening FREE ?
>
> Roger
>
> "Michael Wojcik" <mwojcik@newsguy.com> schrieb im Newsbeitrag
> news:e7us2j025s4@news3.newsguy.com...
>
>
|
|
|
|
|