|
From: | Bruce Zupek |
Subject: | [Bug-GnuCOBOL] Binary allocations - -fbinary-size=2-4-8 |
Date: | Sun, 13 May 2018 14:08:02 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
Having a wee bit of an issue with binary data field size allocation. \GNUCOBOL\BIN\cobc %1 %2 %3 -fbinary-size=2-4-8 -fbinary-byteorder=big-endian -fsource-location -Xref --tsymbols -fsign=ebcdic -fcomplex-odo -fimplicit-init -fsticky-linkage -fperform-osvs -fmove-ibm -fhostsign -fnotrunc -fno-recursive-check -fdefaultbyte=00 PD-CURSOR-ROW PIC 9(02) COMP-5. PD-CURSOR-ROW SIZE :=1 # Binary byte size - defines the allocated bytes according to PIC # Value: signed unsigned bytes # ------ -------- ----- # '2-4-8' 1 - 4 same 2 # 5 - 9 same 4 # 10 - 18 same 8 # # '1-2-4-8' 1 - 2 same 1 # 3 - 4 same 2 # 5 - 9 same 4 # 10 - 18 same 8 With the -fbinary-size=2-4-8 set I am getting a result as if 1-2-4-8. I would have expected the size to be 2 bytes yet execution indicates a length of 1. The behavior of 2-4-8 not being recognized is significant. Offsets and data field lengths are inconsistent with MF, Fujitsu, and zOS when a binary data field has a PIC(nn) where nn is 2 or less. Please advise. Thank You. Bruce Zupek c:\>CALLEDIT 318 PD-CURSOR-ROW PIC 9(02) COMP-5. PD-CURSOR-ROW SIZE :=1 10 PD-SET-CURSRPOS PIC X(01). 10 PD-CURSOR-ROW PIC 9(02) COMP-5. 10 PD-CURSOR-COL PIC 9(02) COMP-5. 10 XX-BEEP PIC X(01). 10 XX-EATTR PIC X(01). 10 XX-SL4 PIC X(01). 10 PD-CAPS-OFF PIC X(01). 10 PD-OLD-CURSOR-POS. 15 PD-OLD-ROW PIC 9(02) COMP. 15 PD-OLD-COL PIC 9(02) COMP. PROCEDURE DIVISION USING EDITSVC-PCDSN EDITSVC-NEW-FILE EDITSVC-EXIT-CODE EDITSVC-EXIT-KEY EDITSVC-EXIT-COMMAND. DISPLAY LENGTH OF PD-FIXED UPON CONSOLE DISPLAY 'PD-CURSOR-ROW PIC 9(02) COMP-5.' UPON CONSOLE DISPLAY 'PD-CURSOR-ROW SIZE :=' LENGTH OF PD-CURSOR-ROW UPON CONSOLE ACCEPT ERROR-PAUSE |
[Prev in Thread] | Current Thread | [Next in Thread] |