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

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

.

Relevant Pages

  • Re: Mix of "functional" and "procedurial" programming
    ... Passing a raw machine address to a subroutine, ... You can have the *convention* that a specific amount of memory ... or the CAR is the software-understadable error code and the CDR is ...
    (comp.programming)
  • Re: question about negative indices in fortran 77
    ... > Intel compilers for linux), but now I'm doing some modifications and I ... > subroutine where it isn't touched. ... out memory in the order arrays are declared. ...
    (comp.lang.fortran)
  • Re: Re (2): nibz/wiki/InstructionSet ?
    ... In the context of stack-machine-architecture, ... memory indexed by S and 'and' it with A. ... So, '16 basic instructions' and the BO instruction, ... Adding a offset plus carry to a subroutine ...
    (comp.lang.forth)
  • Re: Fortran memory management, error handling, and efficiency
    ... I still have the old edition of your book, the f95 ... My subroutine should allocate all memory by calling their memory ... deallocate them yourself but using memory address pointers won't help ...
    (comp.lang.fortran)
  • Re: memory leak using system.windows.forms.timer
    ... the tick event fire a function that returns the number of workstation ... subroutine, memory leaks. ... subroutine with a static number I still leak memory. ...
    (microsoft.public.vb.general.discussion)