NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/alt/cobol/678

Text File | 1993-01-21 | 7.8 KB | 195 lines

Newsgroups: alt.cobol
Path: sparky!uunet!spool.mu.edu!sgiblab!pacbell.com!tandem!news
From: Don Nelson <[e-mail]>
Subject: Re: Hello, anybody out there ?
Message-ID: <[e-mail]>
X-Xxdate: Thu, 21 Jan 93 20:44:02 GMT
Sender: [e-mail]
Nntp-Posting-Host: 130.252.172.59
Organization: Tandem Computers
X-Useragent: Nuntius v1.1.1d16
References: <[e-mail]>
Date: Thu, 21 Jan 1993 19:30:47 GMT
Lines: 180

In article <[e-mail]> Mike Kenny,
[e-mail] writes lots of stuff, excerpts follow:

>2. for ANSI - read ANSI/CODASYL or whoever controls the ANSI standard
>   these days

The ANSI Standard is controlled by ANSI X3J4, the COBOL Committee.  The
worldwide standard is the ISO (International Standards Organization)
Standard,
which is currently based on the ANSI Standard.  The next Standard (1996
perhaps) will be an ISO standard first, and then adopted as a US standard
by
ANSI.  This work is being driven by ISO/IEC JTC1/SC22/WG4 COBOL (don't
ask
what all those initials mean), with most of the work being done by X3J4.
I am
project editor of that standard.

>1. don't real COBOL programmers have access to news ? (or do the
>   sysadms not tell 'em about it ?)

This is quite true.  I am moderator of the COBOL conference in Bix and we
have
almost no COBOL activity.  I've been involved in COBOL development for 28
years, and in all those years I haven't seen much interest in outside
stuff by
COBOL programmers.

>4. why isn't the serious COBOL community raising hell over not
>   having comp.lang status ? (maybe that explains why this group
>   is so quiet, all the interested people are looking for
>   comp.lang.cobol)

I don't because I don't have the faintest idea of how Internet works, who
owns
conferences, and so on.  Where does one raise hell?

>Lots of stuff about why aren't more people involved.

Very few manufacturers have access to Internet.  We didn't until last
summer.
It is not supposed to be a commercial network.  Many that do have access
can
only send and receive messages.

>1. pointers : ...
>
>   Anyways, my understanding of things is that ANSI has not defined
>   the use of pointers in COBOL, so implementors are free to go their
>   own way. But I believe the next standard is possibly going to
>   address this void in the language. If so, which way are they going
>   to go ? Probably the first, since I believe this is IBM's, which is
>   fine except that it does not support the syntax 'with pointer'. I
>   like this feature because every time the pointer is updated the area
>   being described by the data declaration 'moves' as well. With the
>   firrst method it is necessary to keep track of changes to the pointer
>   and execute 'set' statements prior to referencing the item.
>
Pointers will be in the next standard and they will not be like either
existing implementation (or the dozen or so other ways).  They are
currently
being defined by the Object-Oriented COBOL task group and the definition
is
not set at this point.

>
>2. intrinsic functions :
>
>   This COBOL had many functions for string manipulation - concatenation,
>   substring, right/left string, etc. Many of these are achievable thru
>   the use of reference modification, string and unstring and many of
>   them relate to a specific type of string termed 'display-2' (see
>   below), but the cost of conversion, particularly when the semantics
>   vary, can cause companies to consider switching to a more 'portable'
>   language rather than 'upgrading' their COBOL (though how C acquired
>   it's reputation for portability escapes me, I guess it must relate to
>   the fact that if a feeature is missing in one environment it is
missing
>   in all environments).

I don't understand the cost of conversion issue.  You should not use
extensions of you want portable COBOL.  As you said, STRING, UNSTRING,
and
reference modification do what you want.  Use the implementor-specific
bells
and whistles and you pay in the long run.

>   Whether or not you agree with my priorities is not at issue here,
>   the point is that if a body of code exists that makes use of some
>   useful extensions then ANSI should make every effort to incorporate
>   these extensions int other standard. Up to the point where they are
>   going to break a larger body of code by doing so.  Since one of the
>   strongest arguments in favor of COBOL is it's existing user base,
>   shouldn't a better effort be made to protect that base ? Or does 'user
>   base' translate into 'big blue user base' ?

We do adapt implementor extensions if they are reasonable.  Nobody has
ever
mentioned the functions you talk about above.

>   The above limitations would be removed if the ability was provided
>   for the user to define their own functions. Does anybody know whether
>   this is going to happen ? as a part of the standard ?

User-defined functions will be part of the next Standard.  In addition,
you
will have object-oriented stuff, which is even more powerful.

>3. DISPLAY-2 items :
>
>   This COBOL had the concept of DISPLAY-2 in addition to DISPLAY. The
>   difference is semantical rather than syntactical. In the following
>   example the first call statement passes 10 characters while the
>   second only passes 4.
>   01  str-1 pic x(10).
>   01  str-2 pic x(10) display-2.
>   ......
>      move "test" to str-1 str-2
>      call "string_routine" using str-1
>      call "string_routine" using str-2
>
>   This data type is also supported in PL/1 and, I think, matches the
>   Pascal concept of a string. I have found this data type to be mildly
>   useful and am really only including it here to further belabor the
>   point concerning protecting the investment in existing COBOL code.

There has been some talk about variable-size strings, but nobody has
proposed
anything.  Whoever wrote this COBOL you talk about has yet to mention
this to
us.

>4. mixed language environments : (lots of stuff)

The next standard will deal with this.  An ISO working group is currently
trying to make all of the languages work together.  I was convenor of it
for a
while.

>5. bits :

There are plans to incorporate boolean (bit) definitions and so on.  To
define
a boolean string that is a string of bits you use "01  a-bit-string PIC
1(n)
USAGE IS BIT.".  You can define boolean literals like B"0101010".  The
operations supported are B-EXOR, B-LESS, B-OR, B-AND, and B-NOT.
Relational
operators are the usual plus CONTAINS and IS CONTAINED IN.
>
>7. EXTERNAL data :
>
>   In a dynamic environment the compiler has no way of knowing ahead
>   of time that it needs to allocate memory for EXTERNAL items, so it
>   leaves it up to the run time to malloc() the memory. Unfortunately,
>   this causes subtle differences in the treatment of these areas from
>   what would have been the case had the compiler exported them for
>   resolution by the linker. But on the other hand I have heard the
>   argument that in a dynamic environment, where memory is short, it
>   is desirable to be able to deallocate the memory in question when
>   no active program references it. So which way is correct ? or should
>   it be a compile time option ? ANSI don't say a great deal about this.

In standard COBOL, there is no dynamic allocation for external data items
and
there should not be.  I assume you are talking about an awful o/s like
UNIX.
Nearly everyone else has no problems with implementing external items.
In
object-oriented COBOL there will be dynamic allocation and deallocation.

Anyhow, lots of good points were brought up.  Actually, I hope this
doesn't stimulate too much discussion or I'll have to spend too much time
responding.

Don Nelson
COBOL Development, Tandem Computers, Inc
ex-Chariman, CODASYL COBOL Committee & member ANSI X3J4 COBOL Comm.
[e-mail]
No clever quotes here