Home > Archive > Cobol > August 2007 > STICKY LINKAGE
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]
|
|
| Roger While 2007-08-17, 7:55 am |
| Got a mind block here.
I am not sure whether I asked this before.
MF has the STICKY-LINKAGE option
(as does OC).
This was to cater for big iron progs that
relied on this behaviour.
Anybody come across something like this?
I only experienced once with a port.
Roger
| |
| Frank Swarbrick 2007-08-17, 6:55 pm |
| >>> On 8/17/2007 at 6:13 AM, in message
<fa43d0$cdg$00$1@news.t-online.com>,
Roger While<simrw@sim-basis.de> wrote:
> Got a mind block here.
> I am not sure whether I asked this before.
> MF has the STICKY-LINKAGE option
> (as does OC).
> This was to cater for big iron progs that
> relied on this behaviour.
> Anybody come across something like this?
> I only experienced once with a port.
What exactly is the definition of "sticky linkage"?
There is no such clause or option in IBM mainframe COBOL, so if it is
supported then it must be the default (and only) behavior.
Frank
| |
| Sergey Kashyrin 2007-08-17, 6:55 pm |
| > What exactly is the definition of "sticky linkage"?
It's an ability to keep the values of previously passed parameters if
currently parameter is not passed.
Currently by default (I don't know if it's any options for that) IBM Cobol
is not doing sticky linkage within different modules, but does it within the
same module, i.e.
CALL "SUB" USING "ABC", "DEF".
CALL "SUB" USING "ABC".
On the second call SUB will get "DEF" in second parameter if those calls are
from the same module.
Regards,
Sergey
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46C5651E.6F0F.0085.0@efirstbank.com...
> <fa43d0$cdg$00$1@news.t-online.com>,
> Roger While<simrw@sim-basis.de> wrote:
>
> What exactly is the definition of "sticky linkage"?
> There is no such clause or option in IBM mainframe COBOL, so if it is
> supported then it must be the default (and only) behavior.
>
> Frank
>
| |
| Alistair 2007-08-17, 6:55 pm |
| On 17 Aug, 17:26, "Sergey Kashyrin" <s...@resqnet.com> wrote:
>
> It's an ability to keep the values of previously passed parameters if
> currently parameter is not passed.
> Currently by default (I don't know if it's any options for that) IBM Cobol
> is not doing sticky linkage within different modules, but does it within the
> same module, i.e.
> CALL "SUB" USING "ABC", "DEF".
> CALL "SUB" USING "ABC".
>
> On the second call SUB will get "DEF" in second parameter if those calls are
> from the same module.
>
That is news to me, said the Big-Iron-age programmer.
| |
| HeyBub 2007-08-17, 6:55 pm |
| Roger While wrote:
> Got a mind block here.
> I am not sure whether I asked this before.
> MF has the STICKY-LINKAGE option
> (as does OC).
> This was to cater for big iron progs that
> relied on this behaviour.
> Anybody come across something like this?
> I only experienced once with a port.
Double weird. But here's a reference:
http://docs.hp.com/cgi-bin/doc3k/BB243390046.15153/44
| |
| William M. Klein 2007-08-22, 3:55 am |
| As the original designer of "Sticky-Linkage" (in my job as "Mainframe
compatibility expert at Micro Focus), the MAIN reason for this (truly UGLY
directive) is not to handle cases where there are less parameters passed the 2nd
thru Nth time, but rather the case of where the (IBM mainframe) ENTRY statement
is used with different parameters on the ENTRY USING statement. On the (IBM)
mainframe, when you call a subprogram by a different ENTRY point, programmers
"expect" the originally passed parameters to still be valid.
To the best of my knowledge, this was NEVER considered a "good" thing to do (for
mainframe programs) but LOTS of programs did it (and therefore, Micro Focus had
to provide "compatibility" for the expected behavior)
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:fa43d0$cdg$00$1@news.t-online.com...
> Got a mind block here.
> I am not sure whether I asked this before.
> MF has the STICKY-LINKAGE option
> (as does OC).
> This was to cater for big iron progs that
> relied on this behaviour.
> Anybody come across something like this?
> I only experienced once with a port.
>
> Roger
>
| |
| Michael Mattias 2007-08-22, 7:55 am |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:s%Pyi.41089$HL1.25643@fe05.news.easynews.com...
> As the original designer of "Sticky-Linkage" (in my job as "Mainframe
> compatibility expert at Micro Focus), the MAIN reason for this (truly UGLY
> directive) is not to handle cases where there are less parameters passed
> the 2nd thru Nth time, but rather the case of where the (IBM mainframe)
> ENTRY statement is used with different parameters on the ENTRY USING
> statement. On the (IBM) mainframe, when you call a subprogram by a
> different ENTRY point, programmers "expect" the originally passed
> parameters to still be valid.
>
> To the best of my knowledge, this was NEVER considered a "good" thing to
> do (for mainframe programs) but LOTS of programs did it (and therefore,
> Micro Focus had to provide "compatibility" for the expected behavior)
Sheesh, I'd certainly agree this is would be a crummy way to write code.
Sounds like one of those 'if we add this feature <prospect with lots of $$$>
will buy' things. (Not that this would be unique to Microfocus, IBM or any
other software publisher).
MCM
| |
| Frank Swarbrick 2007-08-22, 6:55 pm |
| >>> On 8/21/2007 at 11:40 PM, in message
<s%Pyi.41089$HL1.25643@fe05.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> As the original designer of "Sticky-Linkage" (in my job as "Mainframe
> compatibility expert at Micro Focus), the MAIN reason for this (truly
> UGLY
> directive) is not to handle cases where there are less parameters passed
> the 2nd
> thru Nth time, but rather the case of where the (IBM mainframe) ENTRY
> statement
> is used with different parameters on the ENTRY USING statement. On the
> (IBM)
> mainframe, when you call a subprogram by a different ENTRY point,
> programmers
> "expect" the originally passed parameters to still be valid.
>
> To the best of my knowledge, this was NEVER considered a "good" thing to
> do (for
> mainframe programs) but LOTS of programs did it (and therefore, Micro
> Focus had
> to provide "compatibility" for the expected behavior)
Hmm! It never would have occurred to me to do something like that!
Now I will say that something I *do* use is the following:
LINKAGE SECTION.
01 LS-PARM1 PIC X.
01 LS-PARM2 PIC X.
01 LS-AREA PIC X(10000).
PROCEDURE DIVISION USING LS-PARM1 LS-PARM2.
IF ADDRESS OF LS-AREA = NULL
EXEC CICS GETMAIN
SET (ADDRESS OF LS-AREA)
FLENGTH (LENGTH OF LS-AREA)
END-EXEC
END-IF
...
This does depend on the address of LS-AREA being persistent between calls.
Would this be considered "sticky linkage"?
Frank
| |
| William M. Klein 2007-08-22, 6:55 pm |
| Frank,
I don't know for certain. It seems to me that most of the testing "for nulls"
in CICS is after EXEC CICS LINK/XCTL and not after a COBOL CALL statement. The
rules are (slightly) different (as I recall) at least on the MVS side (don't
know about VSE).
The *STANDARD* rules of COBOL are,
"Thou SHALT NOT reference a Linkage Section item that does not match a passed
parameter"
(well things changed a LITTLE with the '02 Standard, but it is still a good rule
of thumb).
Your use of testing for "address of ... = Null" is (I think) valid in the '02
Standard, but as we both know that CICS doesn't run anywhere with an '02
Standard compiler, this is probably poorly defined.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46CC0A8F.6F0F.0085.0@efirstbank.com...
> <s%Pyi.41089$HL1.25643@fe05.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
> Hmm! It never would have occurred to me to do something like that!
> Now I will say that something I *do* use is the following:
>
> LINKAGE SECTION.
> 01 LS-PARM1 PIC X.
> 01 LS-PARM2 PIC X.
> 01 LS-AREA PIC X(10000).
>
> PROCEDURE DIVISION USING LS-PARM1 LS-PARM2.
> IF ADDRESS OF LS-AREA = NULL
> EXEC CICS GETMAIN
> SET (ADDRESS OF LS-AREA)
> FLENGTH (LENGTH OF LS-AREA)
> END-EXEC
> END-IF
> ...
>
> This does depend on the address of LS-AREA being persistent between calls.
> Would this be considered "sticky linkage"?
>
> Frank
>
>
| |
| Frank Swarbrick 2007-08-22, 6:55 pm |
| >>> On 8/22/2007 at 1:38 PM, in message
<zg0zi.98344$jE4.59954@fe12.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> Frank,
> I don't know for certain. It seems to me that most of the testing "for
> nulls"
> in CICS is after EXEC CICS LINK/XCTL and not after a COBOL CALL
> statement. The
> rules are (slightly) different (as I recall) at least on the MVS side
> (don't
> know about VSE).
>
> The *STANDARD* rules of COBOL are,
> "Thou SHALT NOT reference a Linkage Section item that does not match a
> passed
> parameter"
Yes, well, I'm guessing that few, if any, COBOLs follow this rule, for the
simple reason that LINKAGE SECTION items can be, in the compilers I know of,
set by some way other using a passed parameter. Specifically, by using a
CICS GETMAIN or some other way of doing dynamic storage allocation.
> (well things changed a LITTLE with the '02 Standard, but it is still a
> good rule
> of thumb).
>
> Your use of testing for "address of ... = Null" is (I think) valid in
> the '02
> Standard, but as we both know that CICS doesn't run anywhere with an '02
> Standard compiler, this is probably poorly defined.
If we could go back in time implement the "BASED" clause and LOCAL-STORAGE
section in COBOL '85 my guess is what we'd have now is the following:
----IF ONLY section begins----
All items in the linkage section must be present as parameters on the
PROCEDURE DIVISION USING statement.
Items in the linkage section may *not* include the BASED clause.
The BASED clause may be present only for 01 or 77 level items in the
WORKING-STORAGE or LOCAL-STORAGE sections.
Addressability to BASED items in the WORKING-STORAGE section are persistent
across COBOL calls.
Addressability to BASED items in the LOCAL-STORAGE section are not
persistent across COBOL calls.
In the "SET ADDRESS OF data-item-1" statement, data-item-1 must be a data
item with the BASED clause specified.
----IF ONLY section ends---
So, specifically, if one wanted to use CICS GETMAIN to dynamically allocate
some storage and make it available to a COBOL program one would declare the
following in either the WORKING-STORAGE or LOCAL-STORAGE sections:
01 MY-DYNAMIC-AREA PIC X(10000) BASED.
And then do the GETMAIN as usual:
EXEC CICS GETMAIN
SET (ADDRESS OF MY-DYNAMIC-AREA)
FLENGTH (LENGTH OF MY-DYNAMIC-AREA)
END-EXEC
Or, of course, one could use the ALLOCATE statement (if it had been present
at the time):
ALLOCATE MY-DYNAMIC-AREA
Seems to me that the only reason that the current COBOL standard allows
LINKAGE section items to refer to this type of dynamic storage is simply
because so many compilers allowed it already, as an extension.
Just a guess, of course. :-)
Frank
| |
| Sergey Kashyrin 2007-08-23, 7:55 am |
| Hi Frank,
We just discussed this topic recently with Roger about OpenCobol, and I just
want to tell my understanding (correct me if I wrong).
1. Unreferenced items in linkage (i.e. which are not referenced in USING) in
IBM Cobol will keep their values
across the calls (like GETMAIN in your sample). It's just the IBM way to
implement BASED which IBM does not have.
Basically IBM implements that as a pointer in a WORKING (read STATIC) and
that's why it keeps....
2. According Roger and 2002, items in LINKAGE should NOT keep the values
across the calls, and that corresponds MicroFocus "default".
3. OC current behavior is to keep if "sticky linkage" is ON (thinking to
change that as a separate option).
4. My understanding of the correct approach is that even in IBM you can have
POINTER in WORKING (which will keep its value) and you can set the "base" of
the LINKAGE item each call. That should work with any Cobol.
Regards,
Sergey
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46CC6354.6F0F.0085.0@efirstbank.com...
> <zg0zi.98344$jE4.59954@fe12.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
> Yes, well, I'm guessing that few, if any, COBOLs follow this rule, for the
> simple reason that LINKAGE SECTION items can be, in the compilers I know
> of,
> set by some way other using a passed parameter. Specifically, by using a
> CICS GETMAIN or some other way of doing dynamic storage allocation.
>
>
> If we could go back in time implement the "BASED" clause and LOCAL-STORAGE
> section in COBOL '85 my guess is what we'd have now is the following:
>
> ----IF ONLY section begins----
> All items in the linkage section must be present as parameters on the
> PROCEDURE DIVISION USING statement.
>
> Items in the linkage section may *not* include the BASED clause.
>
> The BASED clause may be present only for 01 or 77 level items in the
> WORKING-STORAGE or LOCAL-STORAGE sections.
>
> Addressability to BASED items in the WORKING-STORAGE section are
> persistent
> across COBOL calls.
> Addressability to BASED items in the LOCAL-STORAGE section are not
> persistent across COBOL calls.
>
> In the "SET ADDRESS OF data-item-1" statement, data-item-1 must be a data
> item with the BASED clause specified.
> ----IF ONLY section ends---
>
> So, specifically, if one wanted to use CICS GETMAIN to dynamically
> allocate
> some storage and make it available to a COBOL program one would declare
> the
> following in either the WORKING-STORAGE or LOCAL-STORAGE sections:
>
> 01 MY-DYNAMIC-AREA PIC X(10000) BASED.
>
> And then do the GETMAIN as usual:
>
> EXEC CICS GETMAIN
> SET (ADDRESS OF MY-DYNAMIC-AREA)
> FLENGTH (LENGTH OF MY-DYNAMIC-AREA)
> END-EXEC
>
> Or, of course, one could use the ALLOCATE statement (if it had been
> present
> at the time):
>
> ALLOCATE MY-DYNAMIC-AREA
>
> Seems to me that the only reason that the current COBOL standard allows
> LINKAGE section items to refer to this type of dynamic storage is simply
> because so many compilers allowed it already, as an extension.
>
> Just a guess, of course. :-)
>
> Frank
>
>
>
| |
| Frank Swarbrick 2007-08-23, 9:55 pm |
| >>> On 8/23/2007 at 6:34 AM, in message
<h9fzi.58$9F7.53301@news.sisna.com>,
Sergey Kashyrin<ska@resqnet.com> wrote:
> Hi Frank,
>
> We just discussed this topic recently with Roger about OpenCobol, and I
> just
> want to tell my understanding (correct me if I wrong).
> 1. Unreferenced items in linkage (i.e. which are not referenced in
> USING) in
> IBM Cobol will keep their values
> across the calls (like GETMAIN in your sample). It's just the IBM way to
> implement BASED which IBM does not have.
> Basically IBM implements that as a pointer in a WORKING (read STATIC)
> and
> that's why it keeps....
Yes, this is how I observe IBM mainframe Cobol to work.
> 2. According Roger and 2002, items in LINKAGE should NOT keep the values
> across the calls, and that corresponds MicroFocus "default".
Does the 2002 standard even actually allow for procedure division reference
to linkage section items that are not either formal parameters or returning
items? The very first lines under "13.6 Linkage Section" state: "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."
Additionally, syntax item 2 states: "The description of the formal
parameters and the returning item that appear in the linkage section of a
function prototype or a program prototype shall match the description of the
formal parameters and the returning item in the corresponding function
definition or program definition, respectively."
This says to me that there shall not be a Linkage Section item specified
that is not either a formal parameter or a return item.
> 3. OC current behavior is to keep if "sticky linkage" is ON (thinking to
> change that as a separate option).
Sounds correct.
> 4. My understanding of the correct approach is that even in IBM you can
> have
> POINTER in WORKING (which will keep its value) and you can set the
> "base" of
> the LINKAGE item each call. That should work with any Cobol.
Absolutely.
Anyway, it seems to me that if the dialect compile option specified is
either "-std=cobol2002" or "-std=default" (or not specified) then it
shouldn't even allow linkage section items that are not either formal
parameters or a return item. (Of course last time I looked OC didn't even
support return items yet. I think.)
On the other hand, if "-std=mvs" or "-std=ibm" (what is the difference
between those two?) is specified then it should be allowed, and additionally
should set "sticky linkage".
I guess then if "-std=mf" is specified then it should be allowed, but
"sticky linkage" would not be set (unless specified separately).
Does this sound right? It all gets a bit confusing!
Frank
| |
| Roger While 2007-08-23, 9:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag
news:46CD5B6C.6F0F.0085.0@efirstbank.com...
> <h9fzi.58$9F7.53301@news.sisna.com>,
> Sergey Kashyrin<ska@resqnet.com> wrote:
>
> Yes, this is how I observe IBM mainframe Cobol to work.
>
>
> Does the 2002 standard even actually allow for procedure division
> reference
> to linkage section items that are not either formal parameters or
> returning
> items? The very first lines under "13.6 Linkage Section" state: "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."
>
It's specifically in 13.6.4 -
4) A based data item may be referenced as described in 13.16.5, BASED
clause; otherwise, a data item defined in
the linkage section of a source element may be referenced within the
procedure division of that source element
if, and only if, it satisfies one of the following conditions:
a) It is an operand of the USING phrase or the RETURNING phrase of the
procedure division header.
b) It is subordinate to an operand of the USING phrase or the RETURNING
phrase of the procedure division
header.
c) It is defined with a REDEFINES or RENAMES clause, the object of which
satisfies one of the above
conditions.
d) It is subordinate to any item that satisfies the condition in subrule c.
e) It is a condition-name or index-name associated with a data item that
satisfies one of the above conditions.
> Additionally, syntax item 2 states: "The description of the formal
> parameters and the returning item that appear in the linkage section of a
> function prototype or a program prototype shall match the description of
> the
> formal parameters and the returning item in the corresponding function
> definition or program definition, respectively."
>
> This says to me that there shall not be a Linkage Section item specified
> that is not either a formal parameter or a return item.
>
>
> Sounds correct.
>
See below.
>
> Absolutely.
>
> Anyway, it seems to me that if the dialect compile option specified is
> either "-std=cobol2002" or "-std=default" (or not specified) then it
> shouldn't even allow linkage section items that are not either formal
> parameters or a return item. (Of course last time I looked OC didn't even
> support return items yet. I think.)
>
Yes it does :-)
> On the other hand, if "-std=mvs" or "-std=ibm" (what is the difference
> between those two?) is specified then it should be allowed, and
> additionally
> should set "sticky linkage".
>
> I guess then if "-std=mf" is specified then it should be allowed, but
> "sticky linkage" would not be set (unless specified separately).
Well actually, after discussion with Sergey, the "stickiness" of
non-USING L/S items has been sperated out to another compile time option :
-fstatic-linkage
It is confusing especially if one is trying to combine newer features with
compatibility features.
eg. What should happen here (if sticky-linkage is set) (I haven't tried it
yet)
CALL "prog" USING P1 P2 P3.
CALL "prog" USING P1 OMITTED P4.
CALL "prog" USING P1.
With "sticky", what does/should "prog" see for the second parameter on the
last call?
Roger
| |
| Frank Swarbrick 2007-08-23, 9:55 pm |
| >>> On 8/23/2007 at 12:17 PM, in message
<fakiv8$a0j$01$1@news.t-online.com>,
Roger While<simrw@sim-basis.de> wrote:
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag
> news:46CD5B6C.6F0F.0085.0@efirstbank.com...
to[color=darkred]
values[color=darkred]
> of
>
> It's specifically in 13.6.4 -
> 4) A based data item may be referenced as described in 13.16.5, BASED
> clause; otherwise, a data item defined in
> the linkage section of a source element may be referenced within the
> procedure division of that source element
> if, and only if, it satisfies one of the following conditions:
> a) It is an operand of the USING phrase or the RETURNING phrase of the
> procedure division header.
> b) It is subordinate to an operand of the USING phrase or the RETURNING
> phrase of the procedure division
> header.
> c) It is defined with a REDEFINES or RENAMES clause, the object of which
>
> satisfies one of the above
> conditions.
> d) It is subordinate to any item that satisfies the condition in subrule
> c.
> e) It is a condition-name or index-name associated with a data item that
> satisfies one of the above conditions.
Didn't see that. I don't think any of a-e are true, but it does look like
(maybe!) that a Linkage Section item can be referred to, when not meeting
criteria a-e, if it is a based data item. Do you agree with this
interpretation?
It is interesting to note that 8.6.4 "Based entries and based data items"
states:
"The association ends: ...
-- when the based entry is defined in the linkage section, at the end of the
execution of the runtime element."
Does this not imply so-called "sticky linkage" for these items?
> a
[color=darkred]
>
to[color=darkred]
>
> See below.
>
> even
>
> Yes it does :-)
Can you give an example of how it works? According to the standard I should
be able to, in a called program, do the following:
LINKAGE SECTION.
01 LS-LINK-AREA PIC X(100).
01 RTN-AREA PIC X(16).
PROCEDURE DIVISION USING LS-LINK-AREA
RETURNING RTN-AREA.
MOVE "something" TO RTN-AREA
EXIT PROGRAM.
OpenCobol does not appear to like this.
>
>
> Well actually, after discussion with Sergey, the "stickiness" of
> non-USING L/S items has been sperated out to another compile time option
> :
> -fstatic-linkage
>
> It is confusing especially if one is trying to combine newer features
> with
> compatibility features.
> eg. What should happen here (if sticky-linkage is set) (I haven't tried
> it
> yet)
> CALL "prog" USING P1 P2 P3.
> CALL "prog" USING P1 OMITTED P4.
> CALL "prog" USING P1.
>
> With "sticky", what does/should "prog" see for the second parameter on
> the
> last call?
I still probably have this wrong, but I'm still thinking that
"sticky-linkage" has only to do with Linkage Section items that are *not*
formal parameters or returned items, so I don't think that the question is
even valid. I would expect in either case that on the third call,
parameters two and three are "omitted". So lets say the called program
looks like this.
linkage section
01 parm1 pic x.
01 parm2 pic x.
01 parm3 pic x.
01 based-ls based pic x.
procedure division using parm1 optional parm2 optional parm3.
if address of based-ls = null
allocate based-ls
display 'based-ls area now allocated'
else
display 'based-ls area already allocated'
end-if
if parm2 is omitted
display 'parm2 not present'
end-if
if parm3 is omitted
display 'parm3 not present'
end-if
exit program.
I would expect call 1 to display
based-ls area now allocated
....call 2 to display
based-ls area already allocated
parm2 not present
....and call 3 to display
based-ls area already allocated
parm2 not present
parm3 not present
Just my opinion...
Frank
| |
| Robert 2007-08-24, 3:55 am |
| On Thu, 23 Aug 2007 10:03:24 -0600, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com>
wrote:
><h9fzi.58$9F7.53301@news.sisna.com>,
>Sergey Kashyrin<ska@resqnet.com> wrote:
>
>Yes, this is how I observe IBM mainframe Cobol to work.
>
Wrong on both points. 8.6.4 says:
An association is established linking the based entry to actual data when its implicit
data-address pointer is assigned the address of an existing data item or assigned the
address of storage obtained with an ALLOCATE statement.
This association establishes a based data item. The association is maintained in an
IMPLICIT DATA-ADDRESS POINTER ...
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.
Micro Focus does, by default, keep pointers to non-parameter linkage section items across
calls.
[color=darkred]
>Does the 2002 standard even actually allow for procedure division reference
>to linkage section items that are not either formal parameters or returning
>items? The very first lines under "13.6 Linkage Section" state: "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."
>
>Additionally, syntax item 2 states: "The description of the formal
>parameters and the returning item that appear in the linkage section of a
>function prototype or a program prototype shall match the description of the
>formal parameters and the returning item in the corresponding function
>definition or program definition, respectively."
13.6.2 does not say the linkage section ONLY contains parameters and returning items. It
says that the section also contains based data items.
4) A based data item may be referenced as described in 13.16.5, BASED clause; *OTHERWISE*,
a data item defined in the linkage section of a source element may be referenced within
the procedure division of that source element if, and only if, it satisfies one of the
following conditions:
a) It is an operand of the USING phrase or the RETURNING phrase of the procedure division
header.
How is the address of a based data item assigned? By receiving it as a parameter? In that
case the BASED clause would be superfluous. This section says there are two ways to
establish addressibility, and receiving a parameter is not one of them.
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. A based entry is not
initially associated with an actual data item. An association is established linking the
based entry to actual data when its implicit data-address pointer is assigned
the address of an existing data item or assigned the address of storage obtained with an
ALLOCATE statement.
There is a third way, probably the most common: SET ADDRESS OF data-name-1 TO
data-pointer.
>This says to me that there shall not be a Linkage Section item specified
>that is not either a formal parameter or a return item.
See above. If you think BASED structures belong in working-storage, it would be consistant
to put all external structures there, including those passed as parameters. After all, the
parameter is usually a pointer, not a value. A strong argument for doing so can be made
when there is a naming standard mandating a prefix of WS- and LS-. You don't want two
copybooks. One solution (widely used by a giant company) is to write the copybook like
this:
05 ()-field-1 pic x.
05 ()-field-2 pic xx.
working-storage section.
01 ws-param. copy xxx replacing ==()== by ==ws==.
....................
linkage section.
01 ls-param. copy xxx replacing ==()== by ==ls==.
A better way would be:
call 'xxx' using address of ws-param.
----called program-----------------
working-storage section.
01 ws-param based. copy xxx.
linkage section.
01 p-param pointer.
procedure division using p-param.
set address of ws-param to p-param.
If you wake to find the last 30 years were a bad dream, you'll be able to find the
thing in a greenbar listing. Real programmers don't use text editors.
>
>Sounds correct.
>
>
>Absolutely.
It is not necessary. The implicit base to linkage section persists across calls.
Local-storage is the one that disappears across calls.
>Anyway, it seems to me that if the dialect compile option specified is
>either "-std=cobol2002" or "-std=default" (or not specified) then it
>shouldn't even allow linkage section items that are not either formal
>parameters or a return item. (Of course last time I looked OC didn't even
>support return items yet. I think.)
>
>On the other hand, if "-std=mvs" or "-std=ibm" (what is the difference
>between those two?) is specified then it should be allowed, and additionally
>should set "sticky linkage".
Sticky linkage refers to parameters, not to dynamically assigned structures in linkage
section.
The difference between ibm and mvs is that mvs was obsolete in 1995, replaced by OS/390,
later z/OS.
I read somewhere that IBM makes 70% of its profit from mainframes, primarily support and
consulting, not hardware. Can anyone confirm or refute?
| |
| Roger While 2007-08-24, 7:55 am |
|
"Robert" <no@e.mail> schrieb im Newsbeitrag
news:kcksc3hmbhss428sf4549k1cjtpt2sa3o6@
4ax.com...
> On Thu, 23 Aug 2007 10:03:24 -0600, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com>
> wrote:
>
>
> Wrong on both points. 8.6.4 says:
>
> An association is established linking the based entry to actual data when
> its implicit
> data-address pointer is assigned the address of an existing data item or
> assigned the
> address of storage obtained with an ALLOCATE statement.
> This association establishes a based data item. The association is
> maintained in an
> IMPLICIT DATA-ADDRESS POINTER ...
>
> 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.
>
And you are wrong. The runtime element IS the actual module.
Therefore a BASED (implicit in legacy progs) item in L/S will lose it's
addressability when the prog exits. (if I am understandarding the standard
correctly)
> Micro Focus does, by default, keep pointers to non-parameter linkage
> section items across
> calls.
Oh no it doesn't! (SE 2.2 and 4.0)
That's why STICKY-LINKAGE is there.
It's confusing in that it is combing two things.
The first is missing params on the caller side. The second is
non-USING L/S params.
Note the MF param has settings =1 and =2
Refer to the online docs which interestingly enough for the
STICKY-LINKAGE param have an example; which will
not work as documented unless you specify other options :-)
Roger
>
>
> 13.6.2 does not say the linkage section ONLY contains parameters and
> returning items. It
> says that the section also contains based data items.
>
> 4) A based data item may be referenced as described in 13.16.5, BASED
> clause; *OTHERWISE*,
> a data item defined in the linkage section of a source element may be
> referenced within
> the procedure division of that source element if, and only if, it
> satisfies one of the
> following conditions:
> a) It is an operand of the USING phrase or the RETURNING phrase of the
> procedure division
> header.
>
> How is the address of a based data item assigned? By receiving it as a
> parameter? In that
> case the BASED clause would be superfluous. This section says there are
> two ways to
> establish addressibility, and receiving a parameter is not one of them.
>
> 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. A based
> entry is not
> initially associated with an actual data item. An association is
> established linking the
> based entry to actual data when its implicit data-address pointer is
> assigned
> the address of an existing data item or assigned the address of storage
> obtained with an
> ALLOCATE statement.
>
> There is a third way, probably the most common: SET ADDRESS OF data-name-1
> TO
> data-pointer.
>
>
>
> See above. If you think BASED structures belong in working-storage, it
> would be consistant
> to put all external structures there, including those passed as
> parameters. After all, the
> parameter is usually a pointer, not a value. A strong argument for doing
> so can be made
> when there is a naming standard mandating a prefix of WS- and LS-. You
> don't want two
> copybooks. One solution (widely used by a giant company) is to write the
> copybook like
> this:
> 05 ()-field-1 pic x.
> 05 ()-field-2 pic xx.
>
> working-storage section.
> 01 ws-param. copy xxx replacing ==()== by ==ws==.
> ...................
> linkage section.
> 01 ls-param. copy xxx replacing ==()== by ==ls==.
>
> A better way would be:
>
> call 'xxx' using address of ws-param.
>
> ----called program-----------------
> working-storage section.
> 01 ws-param based. copy xxx.
> linkage section.
> 01 p-param pointer.
> procedure division using p-param.
> set address of ws-param to p-param.
>
> If you wake to find the last 30 years were a bad dream, you'll be able to
> find the
> thing in a greenbar listing. Real programmers don't use text editors.
>
>
> It is not necessary. The implicit base to linkage section persists across
> calls.
> Local-storage is the one that disappears across calls.
>
>
> Sticky linkage refers to parameters, not to dynamically assigned
> structures in linkage
> section.
>
> The difference between ibm and mvs is that mvs was obsolete in 1995,
> replaced by OS/390,
> later z/OS.
>
> I read somewhere that IBM makes 70% of its profit from mainframes,
> primarily support and
> consulting, not hardware. Can anyone confirm or refute?
| |
| Robert 2007-08-24, 9:55 pm |
| On Fri, 24 Aug 2007 12:43:36 +0200, "Roger While" <simrw@sim-basis.de> wrote:
>
>"Robert" <no@e.mail> schrieb im Newsbeitrag
> news:kcksc3hmbhss428sf4549k1cjtpt2sa3o6@
4ax.com...
>
>And you are wrong. The runtime element IS the actual module.
>Therefore a BASED (implicit in legacy progs) item in L/S will lose it's
>addressability when the prog exits. (if I am understandarding the standard
>correctly)
This test program shows you are correct. The implicit pointer is destroyed on exit from a
called program, but the memory is NOT DEALLOCATED. What a wonderful tool for creating
memory leaks.
call 'test4called' using 'call 1'
call 'test4called' using 'call 2'
working-storage section.
01 p-dynamic pointer value null.
linkage section.
01 param-1 pic x(3).
01 dynamic-memory pic x(10).
procedure division using param-1.
display param-1
if address of dynamic-memory = null
display 'address is null'
if p-dynamic not equal to null
display ', but pointer is notl'
set address of dynamic-memory to p-dynamic
display 'Contents: ' dynamic-memory
display 'I did not crash'
else
call 'CBL_ALLOC_MEM'
using p-dynamic by value 16, 0
returning return-code
if return-code equal to zero
set address of dynamic-memory to p-dynamic
display 'allocated now'
move 'my data' to dynamic-memory
else
display 'allocation failed ' return-code
end-if
end-if
else
display 'already allocated ' dynamic-memory
end-if
goback
call 1
address is null
allocated now
call 2
address is null
, but pointer is not
Contents: my data
I did not crash
>
>Oh no it doesn't! (SE 2.2 and 4.0)
>That's why STICKY-LINKAGE is there.
>It's confusing in that it is combing two things.
>The first is missing params on the caller side. The second is
>non-USING L/S params.
>Note the MF param has settings =1 and =2
>Refer to the online docs which interestingly enough for the
>STICKY-LINKAGE param have an example; which will
>not work as documented unless you specify other options :-)
Better to write huge monolithic programs. I believe in the MISS Principle -- Make It
Simple, Stupid, even when it isn't.
| |
| William M. Klein 2007-08-25, 3:55 am |
| "Robert" <no@e.mail> wrote in message
news:oevuc3p14g4rs76gsdsib68fu3feto1l0m@
4ax.com...
> On Fri, 24 Aug 2007 12:43:36 +0200, "Roger While" <simrw@sim-basis.de> wrote:
<snip>
>
> This test program shows you are correct. The implicit pointer is destroyed on
> exit from a
> called program, but the memory is NOT DEALLOCATED. What a wonderful tool for
> creating
> memory leaks.
>
I believe that this is correct (that addressability to the LS item is lost on
"EXIT PROGRAM" or equivalent exiting statement). It is (I think) intentional
that no storage is freed, because it is unknown who else might have
addressability to that storage. (For example, the RETURNING item could be the
address of the storage).
I think that most people agree that whenever you get into using
allocation/deallocation/pointers that the RISK of "storage leaks" is relatively
high. There was SOME sentiment for NOT putting POINTERS into the '02 Standard -
even though many implementations already had it.
--
Bill Klein
wmklein <at> ix.netcom.com
<snip>
| |
| William M. Klein 2007-08-25, 3:55 am |
| Sergey, Roger (et al)
Just to repeat something that I posted earlier, the MAIN reason that Micro Focus
added Sticky-Linkage was for applications with ENTRY statements (with different
numbers of parameters).
It is also worth noting that both the Micro Focus and IBM reps to J4 were aware
of the difference between IBM's linkage retention and the '02 Standard handling
of BASED items (that may be in Linkage or OTHER data division sections). In
general, the thought was that standard-conforming applications would SAVE
pointer information between calls and reset addressability - if it was "desired"
for BASED items. (Non-based items do need to be explicitly passed in
Standard-conforming programs, so the issue never arises)
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Roger While 2007-08-25, 6:55 pm |
| Thnks Bill for this.
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:1PPzi.6733$Jz.2080@fe01.news.easynews.com...
> Sergey, Roger (et al)
>
> Just to repeat something that I posted earlier, the MAIN reason that Micro
> Focus added Sticky-Linkage was for applications with ENTRY statements
> (with different numbers of parameters).
>
> It is also worth noting that both the Micro Focus and IBM reps to J4 were
> aware of the difference between IBM's linkage retention and the '02
> Standard handling of BASED items (that may be in Linkage or OTHER data
> division sections). In general, the thought was that standard-conforming
> applications would SAVE pointer information between calls and reset
> addressability - if it was "desired" for BASED items. (Non-based items
> do need to be explicitly passed in Standard-conforming programs, so the
> issue never arises)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
|
|
|
|
|