COBOL based data items and dynamic storage allocation

Currently, my COBOL compiler (COBOL for VSE/ESA 1.1.1) supports (after a
fashion) dynamic storage allocation in the following manner:

data division.
linkage section.
01  dynamic-area                                pic x(80).
procedure division.
call 'malloc' using address of dynamic-area, by content function
length(dynamic-area)
*    dynamic-area now has linkage to the dynamically allocated area

(malloc here is not necessary the C malloc function but simply a function
(not written in COBOL!) that dynamically allocates the amount of member
specified in parm 2 and sets parm1 to this address)

This is, of course, not valid according to the COBOL 1985/89 standard, upon
which this compiler is based, but is instead an extension to it.  From my
reading of the "COBOL 2002" standard this is still not valid COBOL.
However, it looks like the following would be.

data division.
working-storage section.
01  dynamic-area                                pic x(80) based.
procedure division.
allocate function length(dynamic-area) characters returning address of
dynamic-area
*    dynamic-area now has linkage to the dynamically allocated area

Alternatively, the allocate statement may look like this:
allocate dynamic-area

Does the above appear to be correct?

From what I can tell it looks like dynamic-area based data item may be
defined in the working-storage section, the local-storage section, or the
linkage section.  The only difference I can think of would be that if
defined in working-storage, dynamic-area would refer to the same area each
time this subroutine is called (probably defined in C parlance as "static
void *dynamic_area"), while defining it in local-storage or linkage would
both have the affect of "losing", as it were, the addressability the next
time the subroutine is called ("auto void *dynamic_area).  In other words,
for non-working-storage the area would still be allocated but dynamic-area
would not point to it (address of dynamic-area would be NULL).

Might the preceding be also correct?  Would there be any difference between
defining a based data item in local-storage versus linkage?

The reason I ask is because I am working on implementing based data items
and the ALLOCATE and FREE statements in to OpenCobol.  I've got it pretty
much working in the manner described above, but I'm not quite sure if I'm
understanding the standard correctly.

By the way, if you know C well enough and are in for a bit of fun(!) I
highly recommend downloading OpenCobol 0.33 and taking a look at it.  I know
nothing about compilers other than what I've learned from OC, but it seems
to be a wonderfully well written piece of software!  You may even feel
inspired, as I did, to implement a yet to be implemented feature!

You can get the pre-release at
http://www.sim-basis.de/open-cobol-0.33.tar.gz
It's not an "official" release yet (that's 0.32, which you can find at
opencobol.org), but I'd still recommend 0.33.

Maybe when 0.34 comes around you might even see my code implemented.
(Assuming it passed muster with the OC maintainer.)

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4fgoekF1i9jmgU1@individual.net...
[snip]
>      allocate function length(dynamic-area) characters returning address
of
> dynamic-area
[snip]
> Does the above appear to be correct?

No. The ALLOCATE statement seems to require a receiving
operand where "address of dynamic-area" appears.

The following would seem to suggest a syntax error.
8.4.2.11 Data-address-identifier.
8.4.2.11.1 General Format
_ADDRESS_ OF identifier-1
8.4.2.11.2 Syntax rules
"5) This identifier format shall not be specified as
a receiving operand."

There is what may seem a conflict with the SET statement
Format 7, which uses SET ADDRESS OF ...; however, this
use of ADDRESS OF is part of the format and not a
data-address-identifier.
[See E.9.1 Data-addresses and data-pointers]

Rick Smith wrote:
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:4fgoekF1i9jmgU1@individual.net...
> [snip]
> 
>
> of
> 
>
> [snip]
> 
>
>
> No. The ALLOCATE statement seems to require a receiving
> operand where "address of dynamic-area" appears.
>
> The following would seem to suggest a syntax error.
> 8.4.2.11 Data-address-identifier.
> 8.4.2.11.1 General Format
> _ADDRESS_ OF identifier-1
> 8.4.2.11.2 Syntax rules
> "5) This identifier format shall not be specified as
> a receiving operand."
>
> There is what may seem a conflict with the SET statement
> Format 7, which uses SET ADDRESS OF ...; however, this
> use of ADDRESS OF is part of the format and not a
> data-address-identifier.
> [See E.9.1 Data-addresses and data-pointers]

Hmm, you know I read that and then forgot about it.  So it appears that
"allocate dynamic-area" is the way to set the address of a based data
item using "allocate".  Or, of course, one could also use two statements
like
allocate 80 characters returning a-pointer
set address of a-based-item to a-pointer

But that would be silly...  :-)

When it says that a data-address-identifier shall not be specified as a
receiving item does that mean that the following would *not* set the
address of a-based-item as one (meaning me) might expect?
call "malloc" using address of a-based-item by content length of
a-based-item

would one have to instead use
call "malloc" using a-pointer by content length of a-based-item
set address of a-based-item to a-pointer

Actually, I think my question is answered with the following (14.8.4.2):
"4) If the BY REFERENCE phrase is not specified or implied for an
identifier-2 or if identifier-2 is an address-identifier, identifier-2
is a sending operand."

Then there's this lovely section:
"E.4.5.2.3 Passing addresses
Passing addresses is a special case, because unlike other identifiers
that are not defined data items, address-identifiers may be passed in
the non-prototype formats of the CALL statements, and with all three
passing mechanisms. Note, however, that the address-identifier is not a
valid receiving operand; therefore, it will never be updated even when
passed by reference. It behaves like being passed by content."

This mystifies me.  The address of non-based working-storage and
local-storage items cannot, of course, be changed, but I see no reason
why if SET ADDRESS OF a-based-item is allowed (as you say, by the
explicit format), why couldn't ADDRESS OF a-based-item be allowed as a
receiving item?

Perplexed...

Frank

Frank,
A couple of comments (hopefully responsive).

There was a reasonable amount of discussion of using (or allowing) the IBM,
Micro Focus (and undcoumented but acceptable) Fujitsu "USAGE POINTER" and "S
ET
ADDRESS OF Linkage-Section-Item" in the '02 Standard.  My *memory* is that
neither the IBM nor the Micro Focus representatives actually supported (or n
ot
actively) using this syntax.

ON THE OTEHR HAND, I find it almost impossible to believe that either of the
se
vendors will ever remove support for the existing syntax - even if/when they
provide an '02 conforming compiler (which niether is currently publicly
committed to doing).

Another relevant comment is to point to the IBM z/OS (rather than VSE) COBOL
documentation, which states (in part) at:
http://publibz.boulder.ibm.com/cgi-.../igy3pg30/4.2.1

"Any changes made by the  subprogram to the address affect the address in th
e
calling program."

This has "change bars" in the V3R4 manual.  It has always worked this way, b
ut
it only recently was documented.  (I think Micro Focus also works this way, 
but
I haven't checked it out).

Bottom-Line:
The '02 method of ALLOCATE, FREE, and "BASED" syntax (and semantics) is
certainly "interesting".  I don't know for surec, but my impression is that 
NO
vendor has actually implemented it (or not completely).  I would probably st
ick
to the IBM, Micro Focus, (semi-) Fujitsu (and possibly other) vendors' suppo
rt
and not worry too much about what the '02 Standard says about this.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <infocat@sprynet.com> wrote in message
news:QoMkg.6953$lp.4009@newsread3.news.pas.earthlink.net...
> Rick Smith wrote: 
>
> Hmm, you know I read that and then forgot about it.  So it appears that
> "allocate dynamic-area" is the way to set the address of a based data item
> using "allocate".  Or, of course, one could also use two statements like
> allocate 80 characters returning a-pointer
> set address of a-based-item to a-pointer
>
> But that would be silly...  :-)
>
> When it says that a data-address-identifier shall not be specified as a
> receiving item does that mean that the following would *not* set the addre
ss
> of a-based-item as one (meaning me) might expect?
> call "malloc" using address of a-based-item by content length of a-based-i
tem
>
> would one have to instead use
> call "malloc" using a-pointer by content length of a-based-item
> set address of a-based-item to a-pointer
>
> Actually, I think my question is answered with the following (14.8.4.2):
> "4) If the BY REFERENCE phrase is not specified or implied for an identifi
er-2
> or if identifier-2 is an address-identifier, identifier-2 is a sending
> operand."
>
> Then there's this lovely section:
> "E.4.5.2.3 Passing addresses
> Passing addresses is a special case, because unlike other identifiers that
 are
> not defined data items, address-identifiers may be passed in the non-proto
type
> formats of the CALL statements, and with all three passing mechanisms. Not
e,
> however, that the address-identifier is not a valid receiving operand;
> therefore, it will never be updated even when passed by reference. It beha
ves
> like being passed by content."
>
> This mystifies me.  The address of non-based working-storage and local-sto
rage
> items cannot, of course, be changed, but I see no reason why if SET ADDRES
S OF
> a-based-item is allowed (as you say, by the explicit format), why couldn't
> ADDRESS OF a-based-item be allowed as a receiving item?
>
> Perplexed...
>
> Frank

William M. Klein<wmklein@nospam.netcom.com> 06/19/06 8:54 AM >>>
>Frank,
>   A couple of comments (hopefully responsive).

Always!

>There was a reasonable amount of discussion of using (or allowing) the IBM,

>Micro Focus (and undcoumented but acceptable) Fujitsu "USAGE POINTER" and
"SET
>ADDRESS OF Linkage-Section-Item" in the '02 Standard.  My *memory* is that

>neither the IBM nor the Micro Focus representatives actually supported (or
not
>actively) using this syntax.


>ON THE OTEHR HAND, I find it almost impossible to believe that either of
these
>vendors will ever remove support for the existing syntax - even if/when
they
>provide an '02 conforming compiler (which niether is currently publicly
>committed to doing).



>Another relevant comment is to point to the IBM z/OS (rather than VSE)
COBOL
>documentation, which states (in part) at:
>
http://publibz.boulder.ibm.com/cgi-.../igy3pg30/4.2.1
>
>"Any changes made by the  subprogram to the address affect the address in
the
>calling program."

That's certainly an interesting note.  But the more I think about it the
less I am sure it makes sense in all cases.  In fact, disregarding BASED
items, I think the only case it makes sense to change the address of a data
item is for a LINKAGE SECTION item that is NOT specified in the PROCEDURE
DIVISION USING clause.  Think of this...

PROGRAM-ID. PROG1.
WORKING-STORAGE SECTION.
01  WS1                PIC X(40).
PROCEDURE DIVISION.
MOVE 'THIS IS A TEST' TO WS1
DISPLAY WS1
CALL 'PROG2' USING ADDRESS OF WS1
DISPLAY WS1
EXIT PROGRAM.

PROGRAM-ID. PROG2.
LINKAGE SECTION.
01  LS1                  PIC X(40).
01  LS2                  PIC X(40).

PROCEDURE DIVISION USING LS1.
CALL 'GETSTORAGE' USING ADDRESS OF LS2
SET ADDRESS OF LS1 TO ADDRESS OF LS2
MOVE 'THIS IS A NEW TEST' TO LS1
EXIT PROGRAM.
END PROGRAM PROG2.

END PROGRAM PROG1.

The call GETSTORAGE makes sense in that LS2 now addresses that storage.  But
does the SET ADDRESS OF LS1 make sense?   My compiler will not allow me to
use ADDRESS OF for a ws field, but I'm curious what result you would get on
Enterprise COBOL.  Would you get a compile error?  Would the result me
THIS IS A TEST
THIS IS A TEST

or would it be

THIS IS A TEST
THIS IS A NEW TEST


I would be very surprised if it was the latter of these, because you can't
(as far as I know) change the address of a working-storage item.

>This has "change bars" in the V3R4 manual.  It has always worked this way,
but
>it only recently was documented.  (I think Micro Focus also works this way,
but
>I haven't checked it out).



>Bottom-Line:
>   The '02 method of ALLOCATE, FREE, and "BASED" syntax (and semantics) is

>certainly "interesting".  I don't know for surec, but my impression is that
NO
>vendor has actually implemented it (or not completely).  I would probably
stick
>to the IBM, Micro Focus, (semi-) Fujitsu (and possibly other) vendors'
support
>and not worry too much about what the '02 Standard says about this.

I don't have a good understanding of how those vendors have this work.  But
here is essentially what I have done to OpenCobol.  Take the following
programs:

PROGRAM-ID. MAIN.
PROCEDURE DIVISION.
CALL 'SUBR'
CALL 'SUBR'
CALL 'SUBR'
STOP RUN.

PROGRAM-ID. SUBR.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  WORK-BASE       PIC X(80) BASED.
LOCAL-STORAGE SECTION.
01  LOCAL-BASE      PIC X(80) BASED.
LINKAGE SECTION.
01  LINK-BASE          PIC X(80) BASED.
PROCEDURE DIVISION.
IF ADDRESS OF WORK-BASE = NULL
DISPLAY 'ALLOCATING NEW WORK-BASE'
ALLOCATE WORK-BASE
END-IF
IF ADDRESS OF LOCAL-BASE = NULL
DISPLAY 'ALLOCATING NEW LOCAL-BASE'
ALLOCATE LOCAL-BASE
END-IF
IF ADDRESS OF LINK-BASE = NULL
DISPLAY 'ALLOCATING NEW LINK-BASE'
ALLOCATE LINK-BASE
END-IF
EXIT PROGRAM.
END PROGRAM SUBR.

END PROGRAM MAIN.

The results would be
ALLOCATING NEW WORK-BASE
ALLOCATING NEW LOCAL-BASE
ALLOCATING NEW LINK-BASE
ALLOCATING NEW LOCAL-BASE
ALLOCATING NEW LINK-BASE
ALLOCATING NEW LOCAL-BASE
ALLOCATING NEW LINK-BASE

Now I should note that none of the storage is being free'd.  Each time SUBR
is called LOCAL-BASE and LINK-BASE have addresses of NULL, because they are
"automatic" data.  WORK-BASE is static data, so it is the same actual data
item each time that SUBR is called.

What is my point?  I'm rambling and having trouble explaining.  I guess what
I am getting at is currently you can have, in COBOL/VSE anyway, the
following...

LINKAGE SECTION.
01  MY-AREA   PIC X(80).
PROCEDURE DIVISION.
CALL 'GETSTORAGE' USING ADDRESS OF MY-AREA, BY CONTENT LENGTH OF
MY-AREA
EXIT PROGRAM.

And with "COBOL 2002" you could have the equivalant:
WORKING-STORAGE SECTION.
01  MY-AREA   PIC X(80) BASED.
PROCEDURE DIVISION.
ALLOCATE MY-AREA
EXIT PROGRAM.

(Note that MY-AREA is now a BASED WS item instead of a "non-based" LINKAGE
item.)

The part of the COBOL 2002 standard I have issue with is that it seems like
one should be able to pass by reference an address of a BASED data item and
allow the called program to change that address.  But any non-based data
item would have to do a pass by content, and this would not affect the
actual address of the item within the calling program.


In any case, I do have both types of ALLOCATE (## characters and
based-data-item) and FREE working in OC, at least in that they are working
the way I understand they should be working.  Which is not to say that it is
correct.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

How about posting your OpenCOBOL changes to the OC list or directly to me ?

Roger

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag
news:4fommiF1jubl9U1@individual.net...
> I don't have a good understanding of how those vendors have this work.
> But
> here is essentially what I have done to OpenCobol.  Take the following
**********
> programs:
>
> PROGRAM-ID. MAIN.
> PROCEDURE DIVISION.
>    CALL 'SUBR'
>    CALL 'SUBR'
>    CALL 'SUBR'
>    STOP RUN.
>
> PROGRAM-ID. SUBR.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01  WORK-BASE       PIC X(80) BASED.
> LOCAL-STORAGE SECTION.
> 01  LOCAL-BASE      PIC X(80) BASED.
> LINKAGE SECTION.
> 01  LINK-BASE          PIC X(80) BASED.
> PROCEDURE DIVISION.
>    IF ADDRESS OF WORK-BASE = NULL
>        DISPLAY 'ALLOCATING NEW WORK-BASE'
>        ALLOCATE WORK-BASE
>    END-IF
>    IF ADDRESS OF LOCAL-BASE = NULL
>        DISPLAY 'ALLOCATING NEW LOCAL-BASE'
>        ALLOCATE LOCAL-BASE
>    END-IF
>    IF ADDRESS OF LINK-BASE = NULL
>        DISPLAY 'ALLOCATING NEW LINK-BASE'
>        ALLOCATE LINK-BASE
>    END-IF
>    EXIT PROGRAM.
> END PROGRAM SUBR.
>
> END PROGRAM MAIN.
>
> The results would be
> ALLOCATING NEW WORK-BASE
> ALLOCATING NEW LOCAL-BASE
> ALLOCATING NEW LINK-BASE
> ALLOCATING NEW LOCAL-BASE
> ALLOCATING NEW LINK-BASE
> ALLOCATING NEW LOCAL-BASE
> ALLOCATING NEW LINK-BASE
>
> Now I should note that none of the storage is being free'd.  Each time
> SUBR
> is called LOCAL-BASE and LINK-BASE have addresses of NULL, because they
> are
> "automatic" data.  WORK-BASE is static data, so it is the same actual data
> item each time that SUBR is called.
>
> What is my point?  I'm rambling and having trouble explaining.  I guess
> what
> I am getting at is currently you can have, in COBOL/VSE anyway, the
> following...
>
> LINKAGE SECTION.
> 01  MY-AREA   PIC X(80).
> PROCEDURE DIVISION.
>     CALL 'GETSTORAGE' USING ADDRESS OF MY-AREA, BY CONTENT LENGTH OF
> MY-AREA
>     EXIT PROGRAM.
>
> And with "COBOL 2002" you could have the equivalant:
> WORKING-STORAGE SECTION.
> 01  MY-AREA   PIC X(80) BASED.
> PROCEDURE DIVISION.
>     ALLOCATE MY-AREA
>     EXIT PROGRAM.
>
> (Note that MY-AREA is now a BASED WS item instead of a "non-based" LINKAGE
> item.)
>
> The part of the COBOL 2002 standard I have issue with is that it seems
> like
> one should be able to pass by reference an address of a BASED data item
> and
> allow the called program to change that address.  But any non-based data
> item would have to do a pass by content, and this would not affect the
> actual address of the item within the calling program.
>
>
> In any case, I do have both types of ALLOCATE (## characters and
> based-data-item) and FREE working in OC, at least in that they are working
> the way I understand they should be working.  Which is not to say that it
> is
> correct.
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO  USA

Roger While<simrw@sim-basis.de> 06/19/06 10:18 PM >>>
> How about posting your OpenCOBOL changes to the OC list or directly to me
?

That's the plan.  I have to clean some stuff up, and write some test cases
for it.

What program do you use for source code comparisons?

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

diff -u (preferably against CVS/prerelease tarball) , then I can use patch
to get it in.
Alternatively, tar and compress the whole OC and send. I can sort it out.
Don't worry about coding style, I'll deal with that.

Roger

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag
news:4fqireF1k54hsU1@individual.net...
> Roger While<simrw@sim-basis.de> 06/19/06 10:18 PM >>> 
> ?
>
> That's the plan.  I have to clean some stuff up, and write some test cases
> for it.
>
> What program do you use for source code comparisons?
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO  USA