[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-COBOL] New to list




Hi David!

> Is there a checklist of COBOL features?

None that I'm aware of outside a COBOL manual, and I think that's not
what you're looking for.

> COBOL doesn't have that many native data types, does it?

Well, no, not really.  You can have PIC 9() which is numeric or PIC X()
which is alphanumeric.  There are also 88-level variables, which are
essentially Booleans whose content is determined automatically by the
contents of its parent field.

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.

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.

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.

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

-- 
David R. Ondrejko - EDI/Referral - Safelite Glass Co.
 Mathematician by training - Programmer by trade - Philosopher by nature
 Genius by genetics - Atheist by conviction - Hedonist by desire!

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