STICKY LINKAGE

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

>>> 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

> 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
>

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 t
he
> 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 a
re
> from the same module.
>

That is news to me, said the Big-Iron-age programmer.

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

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 statem
ent
is used with different parameters  on the ENTRY USING statement.  On the (IB
M)
mainframe, when you call a subprogram by a different ENTRY point, programmer
s
"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
>

"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

>>> 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

Frank,
I don't know for certain.  It seems to me that most of the testing "for null
s"
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 passe
d
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 '0
2
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
>
>

>>> 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