[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] OC issues - number 7
From: |
John R. Culleton |
Subject: |
Re: [open-cobol-list] OC issues - number 7 |
Date: |
Wed Jan 18 13:20:17 2006 |
User-agent: |
KMail/1.7.2 |
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
- [open-cobol-list] OC issues - number 3, (continued)
- [open-cobol-list] OC issues - number 3, Sergey Kashyrin, 2006/01/17
- [open-cobol-list] OC issues - number 6, Sergey Kashyrin, 2006/01/18
- Re: [open-cobol-list] OC issues - number 6, Alain Lucari, 2006/01/18
- RE: [open-cobol-list] OC issues - number 6, Bill Klein, 2006/01/18
- Re: [open-cobol-list] OC issues - number 6, Sergey Kashyrin, 2006/01/18
- [open-cobol-list] OC issues - number 7, Sergey Kashyrin, 2006/01/18
- Re: [open-cobol-list] OC issues - number 7,
John R. Culleton <=
RE: [open-cobol-list] OC issues (more), Bill Klein, 2006/01/17
Re: [open-cobol-list] OC issues (more), John R. Culleton, 2006/01/17
- RE: [open-cobol-list] OC issues (more), Bill Klein, 2006/01/17
- Re: [open-cobol-list] OC issues (more), John R. Culleton, 2006/01/17
- Re: [open-cobol-list] OC issues (more), Alain Lucari, 2006/01/18
- Re: [open-cobol-list] OC issues (more), Sergey Kashyrin, 2006/01/18
- Re: [open-cobol-list] OC issues (more), Alain Lucari, 2006/01/18
Re: [open-cobol-list] OC issues (more), Alain Lucari, 2006/01/18
Re: [open-cobol-list] OC issues (more), Alain Lucari, 2006/01/18