[GNU-COBOL] New to COBOL

["David L. Nicol" <david@kasey.umkc.edu>]

Davyd Ondrejko wrote:

> The internal storage of PIC 9() fields is weird, as well.  Normally, a
> PIC 9()) is stored in the same way as a PIC X(); that is, one byte per
> digit.  You can attach qualifiers to numerics, though; COMP stores it in
> native binary format and COMP-3 stores it in what's known as packed
> decimal format.  (I'll explain that if you really want me to.)  Also,
> with COMP storage, you can (and in most cases should) specify the SYNC
> qualifier as well, which causes the storage to be optimized along word
> boundaries.

But internal storage is an implementation detail.  Would not any 
arbitrary-precision arithmatic package be able to APPEAR AS these data
types?

Perhaps by using C++ and designing a few cobolesque base classes?

Or by using perl5 and defining a few methods?

Packed decimal means storing one digit in each nybble or your data,
right?  Perl can unpack arbitrary data into hex nybbles using
the h or H "pack templates" and then evaluate the results as numbers
(into the native perl number type, which is double-precision floating
point,
which can cause inaccuracies, so a big integer package would be called
for, or perhaps adjusted as needed)

It just seems to me that if COBOL functionality is, as is widely
claimed,
a proper subset of the functionality of so many other languages,
throwing
together a rough translator, instead of a compiler, would not be
difficult,
especially since I know (it was an aside in a lecture in AI class) that
someone once wrote a full Common Lisp interpreter in dBase.

 
> You need to take into consideration such techniques as REDEFINES clauses
> (and the related though seldom-used RENAMES clauses), which use a
> different mapping to access the same region of storage, and OCCURS,
> which is the COBOL version of an array.  (There's also the OCCURS
> DEPENDING ON, where the length of the array is not determined until
> runtime, and the related topic of variable-length records.)  In COBOL
> '85, of course, you get into other data possibilities such as pointers,
> which introduces the possibility of linked lists and similar things.

Perl arrays are all variable length.  Since COBOL gives access to
hardware-oriented abstractions like "regions of storage" why not set up
a COBOL VM that has them?  Create the "ideal COBOL machine" as an
abstraction
that exists only within the model, and is supported by the GNUBOL
RUN-TIME
ENVIRONMENT or something, instead of trying to keep up with (or even
worse,
duplicate) the egcs back-end?


 
> Numeric-edited fields and alphanumeric-edited fields would be
> particularly enjoyable.  Floating or fixed insertion symbols (+, - or
> $), zero suppression with blank or asterisk replacement, CR and/or DB
> symbols, BLANK WHEN ZERO, and so forth.

These would be a property of the instance of the display method, rather 
than the data, I think (coming to this with no experience of COBOL
whatsoever.)

What kinds of file systems or other persistence abstractions exist in
the general COBOL environment?  Does COBOL give low-level calls to
things
like "read a block of records from tape drive 2" or what?  Do you have
to mount the tape with a name and then read the records from the device
with the name?

 
> This is, of course, only for straight COBOL.  Adding such packages as
> CICS and/or DB2 -- to mention the two most commonly used extensions --
> could introduce other factors.
> 
> > I have this idea that writing a COBOL to Perl translator would be a
> > straightforward ten hours of iterating over pages of the spec and
> > implementing them one by one.
> 
> When I was younger, I met someone who had the idea that they could write
> a program to beat the Turing test on their 80386 (with 640K and a 40 Meg
> hard drive).  No offense, but I don't think that you're quite grasping
> the complexity of such an undertaking.  I would be interested to see
> what you produce, in any case.
> 
> -- Davyd


You're comparing re-implementing a programming language written in 1952
with convincing a disinterested observer that a machine has
consciousness?
Whew -- I was using as my role-modeling anecdote the existence of a
full implementation of Common Lisp done with dBase III. :)



How do people get into COBOL programming?  It's never offered in schools

--
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.