Re: [open-cobol-list] OC issues - number 7

[John R. Culleton]

On Wednesday 18 January 2006 03:58 pm, Sergey Kashyrin wrote:
> the next one looks like bug.
>
>        IDENTIFICATION DIVISION.
>        PROGRAM-ID. ztest INITIAL.
>        ENVIRONMENT DIVISION.
>        DATA DIVISION.
>        WORKING-STORAGE SECTION.
>        01  T     COMP.
>            05 MENU-AREA-LEN         PIC S9(04)  VALUE   +5.
>            05 COMMAREA-LEN          PIC S9(04)  VALUE  +58.
>            05 LCTABL-RECLEN         PIC S9(4)   VALUE +255.
>            05 LCTABL-KEYLEN         PIC S9(4)   VALUE  +16.
>            05 CA-DATE-AREA-LENGTH   PIC S9(4)   VALUE  +65.
>        01  L PIC S9(4) COMP.
>        PROCEDURE DIVISION.
>            MOVE LENGTH OF T TO L.
>            DISPLAY 'LEN=' L.
>            GOBACK.
>
> G:\bank64\src\obj>cobc -x -std=ibm ztest7.cbl
> ztest7.cbl:6: Error: 'T' binary field cannot be larger than 18 digits

It looks like very bad code to me. You define the group item "T"
as computational. Then you define subfields under it.
Each of these fields are signed, which means
that the fields have to have room for a sign byte or nibble.
Also, a COMP field soes not measure out the same length as its
count in decimal digits. An S9(4) field, depending on the
hardware, may require  various lengths in bytes. On a word
oriented machine it could be a half word or full word. 

There is no need to define the group item as COMP. That
definition is best left to the elementary items, those with PIC
clauses. Indeed there is no real need to group the above data
fields at all.  They can all be defined as 01 or 77. Just because
the standard says you can do someting doesn't mean that you
should do something. I cannot ever recall having assigned COMP,
COMP-3 etc. to a group item. And I have been writing COBOL since
1968.

We waste time trying to write nonsense code code designed to break
compilers. The answer in every case is to write sensible code.
Given the fact that major features like the SCREEN SECTION are
still missing, playing around with silly scenarios is not useful. 
-- 
John Culleton