I am referring here to Linkage Section items that are not specified in the Procedure Division Using statement, but instead have linkage established by using the SET statement.
My observation is that upon entry to a called subroutine for a second time the linkage that was established the first time through is still in place.  Is this intentional behavior, or just "coincidental"?  And is there a possibility that an RFE would be acceptable to provide alternate behavior?

It seems to me that the COBOL "BASED" clause (from the COBOL 2002 standard) might be useful here.  Rather than placing the field in the Linkage Section, one could place it in either the Working-Storage Section or Local-Storage Section, depending on the desired behavior.  When in working-storage one would get the existing behavior ("static linkage", as it were).  When in local-storage, upon entry to the subroutine there would be no addressability.  That is, the address of the field would be NULL.

If the BASED clause is too much of an ask, perhaps some other way to set the later behavior.  I think Micro Focus provides an option they call "sticky-linkage", where the latter option is default, but the current Enterprise COBOL behavior can be turned on.

Thoughts?

------------------------------
Frank Swarbrick
------------------------------

Addressability for LINKAGE SECTION items/structures is done via BLL (Base Locator for Linkage) cells, which are SET either in the prolog for parameters, or via SET statements for non-parameter linkage section items/structures. You can see the specific BLLs used in the MAP output to the right of the item/structure definition.
You can think of a SET ADDRESS OF template TO some-value as a SET template-bll TO some-value, with subsequent references to the template using the template-bll as the base address.
The BLL cells are in "static" storage (in non-THREAD compiles), so in the current implementation they retain their value from one call to another in the absence of a SET statement.
You could simulate the LOCAL-STORAGE BASED scheme by including a SET ADDRESS OF template TO NULL statement right after the procedure division statement to SET the associated BLL cell to NULL, forcing another SET statement to avoid an addressing error. The compiler does generate warnings if it thinks you're using a template without having established addressability, so such a simulation might be counter productive.
You can of course open an RFE for the implementation of the BASED feature.

------------------------------
Bernie Rataj
Senior Software Developer
IBM Canada Ltd.
Markham ON Canada
https://www.ibm.com/marketplace/ibm-compilers
------------------------------

Original Message:
Sent: Fri January 28, 2022 06:25 PM
From: Frank Swarbrick
Subject: Non-using Linkage Section default values

I am referring here to Linkage Section items that are not specified in the Procedure Division Using statement, but instead have linkage established by using the SET statement.
My observation is that upon entry to a called subroutine for a second time the linkage that was established the first time through is still in place.  Is this intentional behavior, or just "coincidental"?  And is there a possibility that an RFE would be acceptable to provide alternate behavior?

It seems to me that the COBOL "BASED" clause (from the COBOL 2002 standard) might be useful here.  Rather than placing the field in the Linkage Section, one could place it in either the Working-Storage Section or Local-Storage Section, depending on the desired behavior.  When in working-storage one would get the existing behavior ("static linkage", as it were).  When in local-storage, upon entry to the subroutine there would be no addressability.  That is, the address of the field would be NULL.

If the BASED clause is too much of an ask, perhaps some other way to set the later behavior.  I think Micro Focus provides an option they call "sticky-linkage", where the latter option is default, but the current Enterprise COBOL behavior can be turned on.

Thoughts?

------------------------------
Frank Swarbrick
------------------------------