Comment on the 199X COBOL standard (long) 
Author Message
 Comment on the 199X COBOL standard (long)

The following is the final draft of my submission to ANSI X3J4 on
the 199x COBOL Draft Standard.  I would like to thank all of you
who have responded to my various postings on the standard.  Your
comments have helped me clarify some of my requests and given me
reason to drop others.

To the members of ANSI X3J4:

I am a United States citizen who has been living in Canada for
the past five years so I am directing my comments to ANSI X3J4.  
As someone who has been programming in COBOL since 1963, I find
the 199x Draft Standard the most exciting change to the language
that I have seen.  I have wanted many of the changes embodied in
this standard for many years.  While I would like to see some
changes, if having all of the changes I suggest would add only
three months to the waiting time for the standard, I would vote
for having the standard without change.  My perspective is as
someone whose areas of work have been in operating systems
support, application programming support and application
maintenance.  In the following paragraphs I will note the
features I find either of greatest use or greatest potential
followed by the other features that I would like but do not see
as critically important.  Following that are comments on some of
the functions and other changes that I would like to see in COBOL
in the future.  

I give the highest priority to the following additions to the
standard. I believe these additions are necessary for COBOL to
thrive in an environment that is mixed computer language, mixed
data type, mixed means of passing control and multi-cultural.

The new data types and constructs are welcomed because they
provide added function (some that I have wanted for 20 years or
more) and more important because they ease inter-language
communication.  No one language can do everything well.  A
language must be usable in a mixed environment or die.

I agree with the literature and postings by members of your
committee  that recursive constructs are necessary to program for
a windowed (Windows from Microsoft, X-Windows, OS2, Linux, Mac,
et al) environment.   Systems of the future must handle more than
just English and must deal with the data in the way that people
expect.  Thus I consider the addition of the ability to handle
the multilingual character sets, cultural conventions on sorting,
dates, etc. crucial to COBOL's success.  It is a tribute to the
designers and implementors of COBOL that it is used worldwide
despite its dependency on the English language.  With the growing
use of systems to serve different countries and cultures this
start on providing the capabilities is welcomed.

The screen handling capabilities are useful if long overdue first
step toward handling the interactive world of computing.  

I welcome the following changes but would recommend dropping them
if there were problems with them that would cause a delay in the
publication of the final standard.

I am glad to see that GOBACK has finally made it into the
standard.  This extension more useful and less ambiguous than
EXIT PROGRAM.

The enhancements to INITIALIZE make it more useful for
initializing data areas since we now will have a way of
initializing FILLER.  I know that I was surprised when I found
that FILLER was not initialized.

I will probably be using COPY  . . .  REPLACING LEADING and
already have several programs in mind where this would be very
useful.

The CONSTANT construct that Don Nelson will be submitting has
several advantages.  It provides a way that I can have all of my
literal usage cross referenced.  I can also see it giving
compiler designers some very interesting flexibility.  It also
allows for installations to have copy books set up that have all
of the common constants for a system or an installation to cut
down of the possibility for error.  I would convert a table of
status code values (10  ARWS02-INVALID-KEY PIC XX VALUE '23'.
etc.) to a copy book of constants.  

The addition of SELECT  ASSIGN USING data-name-1 would allow the
change of some programs at my current installation to eliminate
the use of an assembler subroutine.

I will definitely use the enhancements to the EXIT verb.  I am
using the equivalent of EXIT PERFORM with another language and
wishing I had it in COBOL.

I like the addition of the partial key construct to the START
verb and have already used similar function in another language.  
I would rather that the draft standard use language similar to
the 1985 standard in describing the START verb.  Although the new
standard uses the words AS IF in describing the function, it
makes me nervous to see the verbiage of reading from the
beginning of the file, etc..  I expect that START will set the
current record pointer to the record with the key with lowest
collating sequence that matches the criterion.  If no record
matches the criteria an INVALID KEY status would be returned.  

Many of us applaud making DELIMITED BY SIZE the default for the
STRING verb and the elimination of the need to code it.

Another nice change is the in-line comment and I hope that it is
extended to the fixed-format.  I would be using it to document
record positions among other things.  
The one change that I oppose is the addition of a >>CONSTANT
directive that can be used to both set and change values that can
be used in source code.  I.e., I find it dangerous to have

Quote:
>>CONSTANT INCREMENT-VALUE IS 1 and then have ADD INCREMENT-VALUE

TO COUNTER in the source code.  I do not have a problem with
Quote:
>>CONSTANT being used to change the 'CONSTANTS' used for

conditional compilation.  For clarity I would prefer >>COMPILE-
VALUE or another name more closely related to the function than

Quote:
>>CONSTANT.  

Making PROPERTY a reserved word for Object Orientation will
affect the property management system in at least one company.  
PROPERTY is one of the key fields.  Unfortunately I find no
acceptable alternative and object oriented capability is worth
the cost.

While I expect all of the following enhancement suggestions to be
deferred to the next standard, some of them may fit in with work
already being done.

In the area of data types it would be useful and increase both
clarity and portability to be able to refer to the various
standards such as ISO 646 International Reference Version by a
standard name such as ISO-IEC646-1 that relates to the specific
standard.  As other standards for data representation become
available, it would be useful to have a means of assigning names
to them so that there is commonality of specification and it is
easy to see what representations a particular implementation of
the compiler is supporting.  This would allow for the addition of
the ability to specify that a program supports ISO or similar
standards for floating-point and binary representation where the
default is NATIVE.  STANDARD-1, STANDARD-2, etc. don't tell me
anything without looking at the manual.    

If 128 bit floating point (or some extended precision) is
available on a large enough number of platforms or is a standard
function in several languages FLOAT-DOUBLE should be added to the
list of binary data types.

It would be handy to be able to specify SYNC at the 01 level,
especially in WORKING-STORAGE.  It is aggravating to have to code
it on every elementary item.

I would like ZEROS and ZEROES to be made synonyms for the sign
condition ZERO as well as the figurative-constant ZERO.
This would have saved me some time when converting some old
programs to COBOL 85.  While I think I understand the reasoning
behind the differentiation, the differing treatment can lead to
errors.  This is in the category of nice to have if it can be
done with little effort and controversy.

I highly recommend adding ON EXCEPTION clauses to the ALLOCATE
verb and the mechanism for expanding dynamic tables.  Along with
this would be  the ability to specify a variable to receive
either the amount of storage/number of entries actually obtained
or the amount of storage/number of entries not obtained.  If the
action by the system were to be no storage obtained, the values
would either the amount of storage/number of entries
obtainable/not obtainable.  This mechanism would allow the
program to adapt to its running environment by using as much
memory as possible and then having an overflow handling
mechanism.

I have a philosophical problem with fatal exceptions as I
understand the definition of the handling in the standard.  I
support an exception being fatal if exception checking is turned
on and there is no exception handling mechanism set up with the
verb (status codes for the I-O statements, etc.) and there is no
DECLARATIVE written for the exception.  I believe that there are
few conditions that an exception handler catches that cannot be
programmatically handled in a declarative.  If the use of the
exception statements and exception mechanisms such as status
codes override the exception checking or can be used to
completely replace it, then this should just be a subject for
review in the next standard.

I applaud the extended letters directive.  In the NEXT standard
it may be desirable to extend the concept to reserved word
replacement so that a program could be written in the primary
language of the coder.

I have had a need for a program with a file where the actual
maximum record length, method of blocking and the block size were
supplied by the external environment.  Just changing the
interpretation of the meaning of RECORD VARYING DEPENDING ON
data-name might be all that is needed to provide this function.  
Use of RECORD 0 VARYING DEPENDING ON data-name to explicitly
defer the record length specification at least for input to the
external environment could be another mechanism.

It also would be useful to have a means of registering compiler
directives that could be useful across platforms.  For example, I
would like a compiler directive that tells the compiler to list
the COBOL elementary MOVEs/ADDs/SUBTRACTs that are generated by a
MOVE/ADD/SUBTRACT CORRESPONDING (>>LIST-EXPAND-CORRESPONDING?).
Also desirable would be one that tells the compiler to list the
mismatches (if any) between two groups involved in with
MOVE/ADD/SUBTRACT CORRESPONDING.

As a reformed user of the ALTER verb (I kicked the habit in the
early 70's), I will not lament its demise.  However there is one
use for it that has not been replaced.  At least one organization
when faced with the elimination of 'ON 1  . . .  some code.' set
up the following general construct for use in called programs.
BEGIN-SWITCH.
    GO TO INITIAL-PROCESSING.
INITIAL-PROCESSING.
    ALTER BEGIN-SWITCH TO PROCEED TO MAIN-LINE-PROCESSING.
    some code.
MAINLINE-PROCESSING.

Note that neither ON 1 nor the ALTER verb require any working
storage items.  This allowed common copy books to be set up that
required no corresponding working storage copy book or data item.  
To provide this function I propose a new DECLARATIVE USE ON FIRST
CALL that would act as if the declarative were the first
procedural code after the procedure division header and that it
was bounded by IF BEGIN-FLAG = "Y" MOVE "N" TO END-FLAG at the
beginning and an END-IF at the end where BEGIN-FLAG is a 1
character field in WORKING-STORAGE with a value of "Y".          

I noted two minor typographical errors.  On page 532, paragraph
15.24.2 I think it should be 'implementor does not name' instead
of 'implementor does not same'.  On page 816, the ANSI standard
is named rather than the ISO standard for STANDARD-1 in contrast
to the statement on page 812.  

In closing, I appreciate the amount of enhancement that this
standard represents.  I will probably be making noticeable use of
many changes not mentioned here.  Some additions are ones that I
think I understand but will need to see some examples before I
use them.  Others may have been overlooked.  My strongest
reaction is that I want a compiler with at least the most
important functions yesterday.  I want the rest of the
improvements by two months from now.  I know that the standards
process and the amount of effort needed just to respond to the
comments and tie up loose ends makes that impossible.  Thank you
for your time.

Clark F. Morris, Jr.
CFM Technical Programming Services
Bridgetown, Nova Scotia, Canada

on assignment at morrisc.nbnet.nb.ca



Sun, 16 May 1999 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Final comment on draft (probably soon to be official) COBOL Standard

2. ABSOLUTELY last chance to comment on next COBOL ANSI/ISO Standard

3. Comments on COBOL 2002 draft Standard

4. Comments on draft COBOL 2002 Standard

5. One week left - for comments on draft COBOL Standard (in US)

6. Fujitsu COBOL - A Restatement of Our Long-term Commitment to COBOL

7. Fujitsu COBOL - A Restatement of Our Long-term Commitment to COBOL

8. COBOL is Dead! Long Live COBOL

9. What's new *and* interesting for IBM mainframe COBOL programmers - in the next COBOL Standard

10. Comments on "1x Forth" Interview (long)

 

 
Powered by phpBB® Forum Software