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

As recently as last year, I worked with someone who insisted that PD had to
be used as it was faster. (In fact she dropped me from the project when I
didn't agree).   On the Univac machines we both worked on (DECADES ago),
it
was true - well in the IBM 360 architecture-dominated world it certainly
was - but that of course ceased to be s o many years ago.  But there are
still people who haven't kept up to date, even on something as simple as
this, and such-like may insist on keeping things static.

People get such odd obsessions.  Some manufacturer - Honeywell, I think -
came up with  a proprietory silicon on sapphire memory structure.  It
worked - it had to!  But for a time there was a group of consultants who
put
in their RPQ's the requirement that the proposed machine must have silicon
on sapphire memory.  How that would have affected processing their
payrolls
or other mission-critical systems was never made out!

PL


Howard Brazee <howard@[EMAIL PROTECTED]
> wrote in message
news:takat3hnac8rubopu84tofpqvq4j0vi8h5@[EMAIL PROTECTED]
> On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@[EMAIL PROTECTED]
> wrote:
>
> >COBOL is not a good candidate for running on JVMs and .NET due to
> >technical problems ie use of redefine and pointers (which are in effect
> >arbitrary redefines), also packed decimal which is not well sup****ted
off
> >the mainframe. You can make it work, but it will run slowly.
>
> Why does being able to use packed decimal make CoBOL a poor candidate?
> If it doesn't fit in your environment, there's no requirement that it
> has to be used.