Re: J4 - presentation/discussion on "Future of the COBOL Standard"

On Mar 15, 3:16 pm, Robert <n...@xxxxxx> wrote:
On Fri, 14 Mar 2008 12:44:05 -0600, "tlmfru" <la...@xxxxxxx> wrote:
Referring strictly to the question of "occurs depending on" and allocation
of memory for it: seems to me it's a non-issue. With the availability of
virtual memory, there is obviously no problem with allocating the maximum
array size: all that's actually needed in the compiled program is a pointer
of some sort to the virtual memory segment that it's stored in.

You talk like a Computer Scientist.

That's an ad hominem where I come from ;-)

Dynamically
expanding or contracting an array with vm is a pretty problem in
under-the-cover programming but nothing more.

There is MUCH more involved when the address of the array can change.

Cobol ODOs are not dynamically re-allocatable. The standard says their address is static.

The virtual storage manager
looks after all the messy details and the "depending on" dataname specifies
the "actually used" number of entries. I dare say the number of pointers to
vm segments is unlimited since they also can be stored in a vm segment.

Of course there are performance issues here but on the other hand truly
gigantic physical memory spaces are no longer news.

There are HUGE performance issues with the kind of abstractions you're talking about.
Today I opened a Java page that took TWO MINUTES to load. When it tried to use its Send
Email function, it crapped out and provided a stack trace that was at least 100 entries
deep.

I'm a techie and I couldn't figure out what the problem was. A typical dumb user wouldn't
stand a chance.

Unless I've missed something crucial in the discussion - only those
compilers that actually allocate space as part of the compiled unit will run
into problems with this.

No compiler does that today. Its output program could become a shared dll/so thing with a
copy of working-storage for each user process.

But ODOs *are* statically allocated within that data space. They are not dynamic.

.

Relevant Pages

  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... there is obviously no problem with allocating the maximum ... array size: all that's actually needed in the compiled program is a pointer ... of some sort to the virtual memory segment that it's stored in. ... compilers that actually allocate space as part of the compiled unit will run ...
    (comp.lang.cobol)
  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... there is obviously no problem with allocating the maximum ... array size: all that's actually needed in the compiled program is a ... compilers that actually allocate space as part of the compiled unit will ... The compiled program does not have to know anything about where the array is ...
    (comp.lang.cobol)
  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... there is obviously no problem with allocating the maximum ... array size: all that's actually needed in the compiled program is a ... gigantic physical memory spaces are no longer news. ... compilers that actually allocate space as part of the compiled unit will ...
    (comp.lang.cobol)
  • Re: Windows array allocation problem
    ... If the required size exceeds the possible size, the program has internal virtual memory management to solve the problem in pieces, storing intermediate pieces on the disk. ... much is available for an actual allocation. ... since the array dimension and the determination of whether to use the virtual memory manager are presently being determined by the calling program and passed in. ...
    (comp.lang.fortran)
  • Re: Memory Limit
    ... DLLs are intentionally grouped towards the end of the 2GB ... Bo said that "I am not allocating physical memory, ... If I am using virtual memory and 3GB virtual memory dedicated to my single ...
    (microsoft.public.vc.language)