Dynamic memory in standard COBOL; using large data fields

My review of available literature seems to indicate that COBOL-85 does
not support the notion of dynamic memory.  That is, there is no standard
malloc or calloc style keywords or calls I can make to allocate and grow
a hunk of memory for an application.

I've got a simple buffer I want to be able to hold a significant amount
of data if necessary (say, 64k) but is often asked to just hold a few
hundred bytes.

I've seen that the latest ANSI/ISO standard for COBOL has the notion of
a pointer into a reserved chunk of memory, and obviously I could
implement my own "heap" for the whole program.  The program is pretty
simple, though, so the only heap I might use is the fixed size of the
field anyway.

I'm just a bit concerned that my app (though short-running) grabs such a
large chunk of memory that it only uses a fraction of normally.  I'm
also sort of stuck with passing the data (what I call a response) in a
data field (and not, for example, in file) because my app is a bit of
glue between a Java server and something else.

That "something else" is up to the customer, and I've provided a
copybook for them to get at the response via procedures in the glue app.
The notion is to provide controlled access to our Java server from
COBOL applications.

In retrospect I suppose I _can_ write out to a short-live "file" of some
manner, and pass a "handle" or reference to that file.  Would this be
the correct COBOL way for such an application?  I know nothing of files
on mainframes, but I'm a pretty smart guy and can figure this stuff out.

My main concern is that I want to ensure that the same code will work
fairly easily with a number of mainframe environments.  Right now we
target OS/390 on zOS, but conceivably we could end up supporting almost
any COBOL-enabled system.

Thanks.

-- cm

If all of your target systems are LE, you can call LE routines to
allocate and deallocate memory. Or, write a subroutine to do
getmain-freemain's. If all programs call this subroute then you will
only need one subroutine per platform.

On Tue, 31 May 2005 11:59:02 -0400, clvrmnky
<clvrmnky-uunet@coldmail.com.invalid> wrote:

>My review of available literature seems to indicate that COBOL-85 does
>not support the notion of dynamic memory.  That is, there is no standard
>malloc or calloc style keywords or calls I can make to allocate and grow
>a hunk of memory for an application.
>
>I've got a simple buffer I want to be able to hold a significant amount
>of data if necessary (say, 64k) but is often asked to just hold a few
>hundred bytes.
>
>I've seen that the latest ANSI/ISO standard for COBOL has the notion of
>a pointer into a reserved chunk of memory, and obviously I could
>implement my own "heap" for the whole program.  The program is pretty
>simple, though, so the only heap I might use is the fixed size of the
>field anyway.
>
>I'm just a bit concerned that my app (though short-running) grabs such a
>large chunk of memory that it only uses a fraction of normally.  I'm
>also sort of stuck with passing the data (what I call a response) in a
>data field (and not, for example, in file) because my app is a bit of
>glue between a Java server and something else.
>
>That "something else" is up to the customer, and I've provided a
>copybook for them to get at the response via procedures in the glue app.
> The notion is to provide controlled access to our Java server from
>COBOL applications.
>
>In retrospect I suppose I _can_ write out to a short-live "file" of some
>manner, and pass a "handle" or reference to that file.  Would this be
>the correct COBOL way for such an application?  I know nothing of files
>on mainframes, but I'm a pretty smart guy and can figure this stuff out.
>
>My main concern is that I want to ensure that the same code will work
>fairly easily with a number of mainframe environments.  Right now we
>target OS/390 on zOS, but conceivably we could end up supporting almost
>any COBOL-enabled system.
>
>Thanks.
>
>-- cm

"clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
news:aR%me.8324$5u4.27086@nnrp1.uunet.ca...
> My review of available literature seems to indicate that COBOL-85 does
> not support the notion of dynamic memory.  That is, there is no standard
> malloc or calloc style keywords or calls I can make to allocate and grow
> a hunk of memory for an application.

Indeed, ANSI X3.23-1985 provides neither standard syntax nor standard
functions to provide this capability.  Nor does ISO/IEC 1989:2002.

The COBOL standard being developed for approval in 2008 includes in the
current draft both "any-length elementary items" and "dynamic-capacity
tables", alone or in combination.  This isn't so much based on the C or
Pascal models of the "heap" as it is oriented toward adding true
variable-length capabilities to existing COBOL applications.

-Chuck Stevens

Slight correction or clarification to Chuck's post.

The '02 Standard *does* introduce the ALLOCATE and FREE statements to do wha
t
you are calling "getmain" and "freemain" (IBM mainframe terminology - I don'
t
know how common this is).  It also includes POINTER data items and based dat
a.

What the (currently under development) '08 Standard will introduce is "dynam
ic
capacity tables" (and any-length items).  The former will provide a method f
or a
new type of OCCURS where a table will "grow" and/or shrink - along with the
storage it uses.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:d7i4em$22fo$1@si05.rsvl.unisys.com...
>
> "clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
> news:aR%me.8324$5u4.27086@nnrp1.uunet.ca... 
>
> Indeed, ANSI X3.23-1985 provides neither standard syntax nor standard
> functions to provide this capability.  Nor does ISO/IEC 1989:2002.
>
> The COBOL standard being developed for approval in 2008 includes in the
> current draft both "any-length elementary items" and "dynamic-capacity
> tables", alone or in combination.  This isn't so much based on the C or
> Pascal models of the "heap" as it is oriented toward adding true
> variable-length capabilities to existing COBOL applications.
>
>    -Chuck Stevens
>
>

For the z/OS environment, see:
http://publibz.boulder.ibm.com/cgi-.../ceea2150/3.3.5

and the related information about those callable services.

As has been pointed out by others, if you place the "allocated" storage rout
ines
in a called program, this would be quite easy to port to other systems.  MOS
T
(not all) COBOL compilers (pre-'02 Standard)  work in environments where the
re
is some method of requesting the "system" to allocate (and free) storage - a
nd
provide a way for your COBOL application to "address" such storage.

--
Bill Klein
wmklein <at> ix.netcom.com
"clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
news:aR%me.8324$5u4.27086@nnrp1.uunet.ca...
> My review of available literature seems to indicate that COBOL-85 does
> not support the notion of dynamic memory.  That is, there is no standard
> malloc or calloc style keywords or calls I can make to allocate and grow
> a hunk of memory for an application.
>
> I've got a simple buffer I want to be able to hold a significant amount
> of data if necessary (say, 64k) but is often asked to just hold a few
> hundred bytes.
>
> I've seen that the latest ANSI/ISO standard for COBOL has the notion of
> a pointer into a reserved chunk of memory, and obviously I could
> implement my own "heap" for the whole program.  The program is pretty
> simple, though, so the only heap I might use is the fixed size of the
> field anyway.
>
> I'm just a bit concerned that my app (though short-running) grabs such a
> large chunk of memory that it only uses a fraction of normally.  I'm
> also sort of stuck with passing the data (what I call a response) in a
> data field (and not, for example, in file) because my app is a bit of
> glue between a Java server and something else.
>
> That "something else" is up to the customer, and I've provided a
> copybook for them to get at the response via procedures in the glue app.
> The notion is to provide controlled access to our Java server from
> COBOL applications.
>
> In retrospect I suppose I _can_ write out to a short-live "file" of some
> manner, and pass a "handle" or reference to that file.  Would this be
> the correct COBOL way for such an application?  I know nothing of files
> on mainframes, but I'm a pretty smart guy and can figure this stuff out.
>
> My main concern is that I want to ensure that the same code will work
> fairly easily with a number of mainframe environments.  Right now we
> target OS/390 on zOS, but conceivably we could end up supporting almost
> any COBOL-enabled system.
>
> Thanks.
>
> -- cm

clvrmnky wrote:
> My review of available literature seems to indicate that COBOL-85 does
> not support the notion of dynamic memory.  That is, there is no
> standard malloc or calloc style keywords or calls I can make to
> allocate and grow a hunk of memory for an application.
>
> I've got a simple buffer I want to be able to hold a significant
> amount of data if necessary (say, 64k) but is often asked to just
> hold a few hundred bytes.
>
> I've seen that the latest ANSI/ISO standard for COBOL has the notion
> of a pointer into a reserved chunk of memory, and obviously I could
> implement my own "heap" for the whole program.  The program is pretty
> simple, though, so the only heap I might use is the fixed size of the
> field anyway.
>
> I'm just a bit concerned that my app (though short-running) grabs
> such a large chunk of memory that it only uses a fraction of
> normally.  I'm also sort of stuck with passing the data (what I call
> a response) in a data field (and not, for example, in file) because
> my app is a bit of glue between a Java server and something else.
>
> That "something else" is up to the customer, and I've provided a
> copybook for them to get at the response via procedures in the glue
> app. The notion is to provide controlled access to our Java server
> from COBOL applications.
>
> In retrospect I suppose I _can_ write out to a short-live "file" of
> some manner, and pass a "handle" or reference to that file.  Would
> this be the correct COBOL way for such an application?  I know
> nothing of files on mainframes, but I'm a pretty smart guy and can
> figure this stuff out.
>
> My main concern is that I want to ensure that the same code will work
> fairly easily with a number of mainframe environments.  Right now we
> target OS/390 on zOS, but conceivably we could end up supporting
> almost any COBOL-enabled system.

64K is piddly. Don't worry about it.

Or you could write a file. In the documentation, tell the user the name of
the file.

If you start using dynamic memory and pointers, the chances are excellent
something will go amiss.

In article <aR%me.8324$5u4.27086@nnrp1.uunet.ca>,
clvrmnky <clvrmnky-uunet@coldmail.com.invalid> wrote:

> My review of available literature seems to indicate that COBOL-85 does
> not support the notion of dynamic memory.  That is, there is no standard
> malloc or calloc style keywords or calls I can make to allocate and grow
> a hunk of memory for an application.
>
> I've got a simple buffer I want to be able to hold a significant amount
> of data if necessary (say, 64k) but is often asked to just hold a few
> hundred bytes.
>
> I've seen that the latest ANSI/ISO standard for COBOL has the notion of
> a pointer into a reserved chunk of memory, and obviously I could
> implement my own "heap" for the whole program.  The program is pretty
> simple, though, so the only heap I might use is the fixed size of the
> field anyway.
>
> I'm just a bit concerned that my app (though short-running) grabs such a
> large chunk of memory that it only uses a fraction of normally.  I'm
> also sort of stuck with passing the data (what I call a response) in a
> data field (and not, for example, in file) because my app is a bit of
> glue between a Java server and something else.
>
> That "something else" is up to the customer, and I've provided a
> copybook for them to get at the response via procedures in the glue app.
>  The notion is to provide controlled access to our Java server from
> COBOL applications.
>
> In retrospect I suppose I _can_ write out to a short-live "file" of some
> manner, and pass a "handle" or reference to that file.  Would this be
> the correct COBOL way for such an application?  I know nothing of files
> on mainframes, but I'm a pretty smart guy and can figure this stuff out.
>
> My main concern is that I want to ensure that the same code will work
> fairly easily with a number of mainframe environments.  Right now we
> target OS/390 on zOS, but conceivably we could end up supporting almost
> any COBOL-enabled system.
>
> Thanks.
>
> -- cm

On z/OS you can use the LE routines CEEGTST & CEEFRST to allocate and
deallocate storeage.

But really, why would you want to.  The days when 64k is a significant
amount of storage are long gone.  I suspect you would get better
performance by putting the 64k chunk in working storage and letting it
be allocated with everything else rather than doing a separate getmain.

Some environments, CICS/TS with storage protection and transaction
isolation comes to mind, will not even do an allocation that small.  If
you allocate EUDSA in CICS/TS you might ask for 64k, but you will get
1M.  The overhead of slicing and dicing memory into smaller chunks is
more work on the machine that the larger, "wasteful" allocations.

As always, your milage may vary depending upon OS, et al.

On 31/05/2005 11:05 PM, Joe Zitzelberger wrote:
> In article <aR%me.8324$5u4.27086@nnrp1.uunet.ca>,
>  clvrmnky <clvrmnky-uunet@coldmail.com.invalid> wrote:
>
> 
>
>
> On z/OS you can use the LE routines CEEGTST & CEEFRST to allocate and
> deallocate storeage.
>
> But really, why would you want to.  The days when 64k is a significant
> amount of storage are long gone.  I suspect you would get better
> performance by putting the 64k chunk in working storage and letting it
> be allocated with everything else rather than doing a separate getmain.
>
> Some environments, CICS/TS with storage protection and transaction
> isolation comes to mind, will not even do an allocation that small.  If
> you allocate EUDSA in CICS/TS you might ask for 64k, but you will get
> 1M.  The overhead of slicing and dicing memory into smaller chunks is
> more work on the machine that the larger, "wasteful" allocations.
>
> As always, your milage may vary depending upon OS, et al.

Thanks for the perspective.  My main problem is that I have no idea what
a typical mainframe developer (if such a thing exists) will think when
confronted with my code.

It works well with the current setup.  My only concern is that it was
odd for us to cap the response at 64k.  It seemed a reasonable number,
but there is (of course) no such restriction on the server side.  The
server doesn't care, however, and I just catch overflow exceptions on
the COBOL side and deal with it.  We will never send more than a few
hundred bytes from COBOL.

Well, that, and my "Murach's" warned me about doing things like
"Initialize my-big-buffer."

Your comments suggest we could just make the buffer bigger if necessary
for some future customer.

The current (currently supported COBOL compiler) for z/OS has a 16M (not K)
limit on
OCCURS n TIMES
(and the size of a SINGLE 01-level size).  See:
[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr20/APPENDIX1.2[/u
rl]

IBM customers have indicated (via a SHARE requirement) that this is NOT larg
e
enough and IBM has responded fairly positively (no guarantee when it will be
implemented).

If you program is NOT running in an "online" environment (CICS or IMS -
typically - but there are others), then do NOT worry about this.  (There is 
2G
of "storage" available to a 31-bit COBOL program).

If, however, your COBOL program *will* run in an online environment
(particularly CICS), then you will need to "coordinate" with your "systems
programmers" to find out what is an acceptable Working-Storage size for your
environment.

--
Bill Klein
wmklein <at> ix.netcom.com
"clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
news:9sqne.8446$5u4.28060@nnrp1.uunet.ca...
> On 31/05/2005 11:05 PM, Joe Zitzelberger wrote: 
>
> Thanks for the perspective.  My main problem is that I have no idea what
> a typical mainframe developer (if such a thing exists) will think when
> confronted with my code.
>
> It works well with the current setup.  My only concern is that it was
> odd for us to cap the response at 64k.  It seemed a reasonable number,
> but there is (of course) no such restriction on the server side.  The
> server doesn't care, however, and I just catch overflow exceptions on
> the COBOL side and deal with it.  We will never send more than a few
> hundred bytes from COBOL.
>
> Well, that, and my "Murach's" warned me about doing things like
> "Initialize my-big-buffer."
>
> Your comments suggest we could just make the buffer bigger if necessary
> for some future customer.

On 01/06/2005 6:45 PM, William M. Klein wrote:
> The current (currently supported COBOL compiler) for z/OS has a 16M (not K
)
> limit on
>     OCCURS n TIMES
> (and the size of a SINGLE 01-level size).  See:
>   http://publibz.boulder.ibm.com/cgi-...NDIX1.
2
>
> IBM customers have indicated (via a SHARE requirement) that this is NOT la
rge
> enough and IBM has responded fairly positively (no guarantee when it will 
be
> implemented).
>
> If you program is NOT running in an "online" environment (CICS or IMS -
> typically - but there are others), then do NOT worry about this.  (There i
s 2G
> of "storage" available to a 31-bit COBOL program).
>
> If, however, your COBOL program *will* run in an online environment
> (particularly CICS), then you will need to "coordinate" with your "systems
> programmers" to find out what is an acceptable Working-Storage size for yo
ur
> environment.
>
Thanks for the reference.  I'll educate myself on what CICS or IMS means
(at least high-level -- I just keep seeing the acronym) and make a
semi-informed decision then.

It looks like there is going to be some formal mainframe
development/COBOL training in my future.

For now I feel better about my design choice -- however inspired by
ignorance it was.