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

On Mar 15, 3:16 pm, Robert <n...@[EMAIL PROTECTED]
> wrote:
> On Fri, 14 Mar 2008 12:44:05 -0600, "tlmfru" <la...@[EMAIL PROTECTED]
> 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.