Re: Dynamic memory in standard COBOL; using large data fields

For the z/OS environment, see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/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 routines
in a called program, this would be quite easy to port to other systems. MOST
(not all) COBOL compilers (pre-'02 Standard) work in environments where there
is some method of requesting the "system" to allocate (and free) storage - and
provide a way for your COBOL application to "address" such storage.

--
Bill Klein
wmklein <at> ix.netcom.com
"clvrmnky" <clvrmnky-uunet@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:aR%me.8324$5u4.27086@xxxxxxxxxxxxxxxxx
> 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


.

Relevant Pages

  • Re: Is there a mainframe skills shortage?
    ... The Integrated Recovery and Step Control I used on Sperry/Unisys mainframes is also years ahead of anything available, even on Sun 15K and other large fail-safe environments. ... Hardware and operations are even more critical in their training requirements than programmers. ... Just because the micro that started life as an embedded controller *still* doesn't have the instruction and data protection capabilities of most mainframes, or the fact that the PCI/DMA chips which were developed for small computers cannot compete with smart block mux I/O channel modules, or I/O processors with full access to memory *and* and up to several hundreds of concurrent I/O channels! ...
    (comp.lang.cobol)
  • Re: Possibly stupid question for you IBM mainframers... :-)
    ... > I've been out of work for a while, and while I know COBOL well enough ... > both of those environments now), most of the mainframe work I see out ... JCL and the IBM mainframe "utilities". ...
    (comp.lang.cobol)
  • Re: OT Science versus religion: Is compromise impossible?
    ... > Let's suppose the Cobol Standard was the US Constitution. ... > Daemons = privateers ... > Programmers, fearing a despotic Cobol, insist on a Second Amendment ... > reading 'Unfettered memory access being essential to programming, ...
    (comp.lang.cobol)
  • Re: The New Roadmap
    ... know anything about both environments when writing portable code, ... That chewed up memory remains chewed ... especially with the differences between Generics and C++ ... Another great 'demo' technology that stores up long term trouble if you ...
    (borland.public.delphi.non-technical)
  • Re: Dynamic memory in standard COBOL; using large data fields
    ... If, however, your COBOL program *will* run in an online environment ... >>>not support the notion of dynamic memory. ... >>>large chunk of memory that it only uses a fraction of normally. ... >>>glue between a Java server and something else. ...
    (comp.lang.cobol)