Re: gnubol: The many different types of numbering systems used in Cobol.

[Charlie Ebert <kd5ob@mmcable.com>]

Boris wrote:

> Charlie,
>
> Nice to see you.
>
> Why Burrows instead of Burroughs?

Yes.  I'm always doing that.


>
>
> I've worked on pretty much every piece of hardware Burroughs ever made, TC500, L's,
> B700 through B6800.  I had completely forgotten about that digit math extension to
> the Burroughs COBOL.  Since this isn't really a part of the standard, I would
> suspect your best bet to get it, would be to wait until the standard version is
> finished and then write your extension for it.  I think the digit math would be a
> real problem.  Storage should be fairly easy as long as you records end on a
> word/byte boundary as appropriate.  That reminds me; doesn't the Burroughs COBOL
> require that group items fit within a word boundary and that all 01's end on a word
> boundary.  Wouldn't it also add slack bytes to 77's?  Basically converting all the
> 77's to 03 as part of an implicit 01?
>

We have a bunch of V's.
The real problem we had was Micro Focus expected every COMP number to by BYTE BOUND.
Therefore the number 973 would take 2 bytes. If we had a record containing two
variables
88745 and 973 it would look like this 0887450973 in hex on the Micro Focus PC.
Whilst the same example in the V would represent 88745973  with no wasted digits.
The PC COBOL forces you to be BYTE aware.


The didn't require byte aligned numbers therefore no V record with massive comp in it
would have
much hope of being read in by a Micro Focus Cobol program.  And this doesn't even
include the
issue of signs in COMP fields.  We've had a growth in our file sizes of up to 20% just
because of
this one issue.

The Central and North Eastern Part of America is just clustered with very old
Burroughs which
have to be replaced out.  Many are in the hands of Banks and many are in the hand of
the Insurance
industry despite the AS400 teams'  best efforts and 4 GL languages.

In the V you could have a record containing 11.5 bytes.  This would be a 23 digit
record.
What they did with the extra digit is unknown.  Perhaps it was nulled behind the
scenes?  I don't
know.

At any rate I hope I've answered your question so that I might get an answer to my
original question.
What basic numbering systems will be offered.   I know everybody shoots for a
standard.
I'm here to tell you that a STANDARD is meaningless in the business community anymore.

There is no effortless conversion in the COBOL world from one machine to another.  The
former
unstandardized C has more shared elements than today's COBOL's.

What I hope for is a haven in the GNU project, such that we don't have to worry about
STANDARDS
anymore.  STANDARDS were a failure!  What we need is availability of a supported
version of COBOL
which never removes sytax/verbage but rather add's to it.  Extends it..

I remember when people used to turn their nose up at C and later C++ as it was not a
STANDARDIZED
LANGUAGE.  IN C or C++ there must be at least 21 different ways to skin a cat!  Why
can't you have
21 different ways in COBOL.  What is wrong with 21 different ways?  It just means less
RE-WRITE time.

Look at the stupidity in the EXAMINE INSPECT argument I posed in the last E-mail.
There was
no reason to remove EXAMINE from all the machine once INSPECT became the new standard.

Re-write COBOL code for what?  For the sake of a committe.  Company's felt dirty if
they left their
guess work in with the Standardized version.

So if all the forms of COMP are not added to the original system, they will be
eventually.
What will be released under the first version?

The GNU version of COBOL will be the worlds standard for COBOL.  The purpose of
international
committee's to set standards will be null and void once this thing takes off.  Just
remember to never
destroy the verbage and everyone will love you...

STANDARDIZED meant that if you wrote useing only what was considered STANDARDIZED you
would have an easier time of porting your code to other machines.

With GNU cobol in 10 years time, it means code I wrote in GNU COBOL Version 1.0 will
still RUN
under GNU COBOL Version 7.5, the compiler will still be there and available on a
machine which is
popular, and I don't have to worry about bankrupcy's, maintenance fees, and
non-STANDARDIZED
dribble ruining my code again!


Thank again.
Charlie






--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.