move of COMP to DISPLAY
in [Cobol]
|
Prev: Global Warming (yet again) (was: Vista
Next: Lack of graphics downfall of mainframe was Re: Java is becoming the new Cobol
From: C Goodman on 5 Jan 2008 08:37 While working on a conversion of programs from MicroFocus to AcuCOBOL I discovered a difference in the way they handle this unusual move. 01 comp-item pic 99 COMP. 01 disp-item pic xxxx. 01 disp2-item pic xx. move 1 to comp-item move comp-item to disp-item. move comp-item to disp2-item. results in HEX under MicroFocus comp-item 01 disp-item 30 31 20 20 disp-item2 30 31 results in HEX under AccuCOBOL comp-item 01 disp-item 30 30 31 20 disp-item2 30 30 The MOVE of an integer numeric item to a DISPLAY item is allowed. The COBOL standard does not seem to indicate which of the compilers is behaving correctly. The storage of COMP-ITEM, defined as PIC 99 COMP, is a single byte integer with vaules from 0 to 255. This is correct with both compilers. AccuCOBOL has several compiler switches to modify the way numeric fields are treated, but none seems to make it work exactly the same as MicroFocus COBOL. I am hoping to avoid manually examining every item defined as COMP to make code changes. I would like to maintain a single code base. All suggestions are welcome. Thanks, Charlie Goodman
From: William M. Klein on 5 Jan 2008 09:02 The way that I read the '02 Standard, (MOVE rules, GR(4a) starting, "When an alphanumeric, alphanumeric-edited, national, or national-edited data item is a receiving operand, ..." and including "If the usage of the sending operand is different from that of the receiving operand, conversion of the sending operand to the internal representation of the receiving operand takes place." I would have EXPECTED thr results to be idential to those that would have occurred if the COMP were removed rom the definition of the sending item. What it looks like (to me) is that AcuCOBOL is acting as if the sending item could hold "001" and not "01". This may have to do wit the "normal" problems related to "TRUNC/NOTRUNC" issues with binary data. I know MF, but don't know AcuCOBOL. If they have a "TRUNC" option, you might try it with that and see if the results are the same. Given a "hex" value of "01" for the sending item, how can you determine if the "decimal" value is "001" or "01"? It should be the latter acorrding to the Standard, but as many compilers (via a TRUNC option) allow for values over decimal "99", this would be a problem. -- Bill Klein wmklein <at> ix.netcom.com "C Goodman" <foxgrove(a)shaw.ca> wrote in message news:BKLfj.11621$uV6.6453(a)pd7urf1no... > While working on a conversion of programs from MicroFocus to AcuCOBOL I > discovered a difference in the way they handle this unusual move. > > 01 comp-item pic 99 COMP. > 01 disp-item pic xxxx. > 01 disp2-item pic xx. > > move 1 to comp-item > move comp-item to disp-item. > move comp-item to disp2-item. > > results in HEX under MicroFocus > comp-item 01 > disp-item 30 31 20 20 > disp-item2 30 31 > results in HEX under AccuCOBOL > comp-item 01 > disp-item 30 30 31 20 > disp-item2 30 30 > > The MOVE of an integer numeric item to a DISPLAY item is allowed. The COBOL > standard does not seem to indicate which of the compilers is behaving > correctly. The storage of COMP-ITEM, defined as PIC 99 COMP, is a single byte > integer with vaules from 0 to 255. This is correct with both compilers. > > AccuCOBOL has several compiler switches to modify the way numeric fields are > treated, but none seems to make it work exactly the same as MicroFocus COBOL. > I am hoping to avoid manually examining every item defined as COMP to make > code changes. I would like to maintain a single code base. > > All suggestions are welcome. > > Thanks, Charlie Goodman > >
From: Michael Mattias on 5 Jan 2008 09:08 > While working on a conversion of programs from MicroFocus to AcuCOBOL I > discovered a difference in the way they handle this unusual move. > > 01 comp-item pic 99 COMP. > 01 disp-item pic xxxx. > 01 disp2-item pic xx. > > move 1 to comp-item > move comp-item to disp-item. > move comp-item to disp2-item. > > results in HEX under MicroFocus > comp-item 01 > disp-item 30 31 20 20 > disp-item2 30 31 > results in HEX under AccuCOBOL > comp-item 01 > disp-item 30 30 31 20 > disp-item2 30 30 > > The MOVE of an integer numeric item to a DISPLAY item is allowed. ... I don't know that USAGE COMP items are considered "integer numeric." Besides, USAGE COMP storage is implementor-defined, meaning it may not be the same in another compiler. (Not that I would expect a change if you stayed within the same brand name). But why don't you end the suspense and just change the destination to a DISPLAY numeric or edited numeric; that way you will not be at the mercy of any compiler vagaries. Or, change the source to a standard USAGE such as BINARY or PACKED-DECIMAL and adjust your MOVEs (the purpose of which eludes me in the first place; surely there is another way to accomplish whatever it is you are out to accomplish) accordingly. MCM
From: rpl on 5 Jan 2008 09:42 C Goodman wrote: > While working on a conversion of programs from MicroFocus to AcuCOBOL I > discovered a difference in the way they handle this unusual move. > > 01 comp-item pic 99 COMP. > 01 disp-item pic xxxx. > 01 disp2-item pic xx. > > move 1 to comp-item > move comp-item to disp-item. > move comp-item to disp2-item. > > results in HEX under MicroFocus > comp-item 01 > disp-item 30 31 20 20 > disp-item2 30 31 > results in HEX under AccuCOBOL > comp-item 01 > disp-item 30 30 31 20 > disp-item2 30 30 > > The MOVE of an integer numeric item to a DISPLAY item is allowed. The receiving DISPLAY field should be defined with a numeric pic, ie: disp-item pic 9999 (or Z999 or whatever you want) >The > COBOL standard does not seem to indicate which of the compilers is > behaving correctly. Neither compiler is "correct" in handling of the (illegal) move; if anything, the results should have been: 01 20 (20 20) >The storage of COMP-ITEM, defined as PIC 99 COMP, > is a single byte integer with vaules from 0 to 255. really ? must be after my time; pass me the geritol, but i thought minimum was 2-bytes (then 4 then 8, though, too be sure, I'm thinking of COMP-4). Now, DISPLAY or COMP-3 you can use any number of bytes. rpl >This is correct > with both compilers. > > AccuCOBOL has several compiler switches to modify the way numeric fields > are treated, but none seems to make it work exactly the same as > MicroFocus COBOL. I am hoping to avoid manually examining every item > defined as COMP to make code changes. I would like to maintain a single > code base. > > All suggestions are welcome. > > Thanks, Charlie Goodman > >
From: C Goodman on 5 Jan 2008 10:08
WOW, three reasonable responses within an hour on Saturday morning! I will re-examine the AcuCOBOL documentation to see if there is something like TRUNC/NOTRUNC. My example showed a value of ONE, but a value of 255 works the same. The PIC 99 COMP field holds an integer value up to 255 with both compilers. The results of the move are similar, with truncation. I know that I can recode the application so that there is a common code base, with identical functionality as the original. However, there are several hundred programs, and thousands of places where COMP fields are defined. Each would need to be examined to see if truncation occurs. ---Charlie William M. Klein wrote: > The way that I read the '02 Standard, (MOVE rules, GR(4a) starting, > "When an alphanumeric, alphanumeric-edited, national, or national-edited data > item is a receiving operand, ..." > and including > "If the usage of the sending operand is different from that of the receiving > operand, conversion of the > sending operand to the internal representation of the receiving operand takes > place." > > I would have EXPECTED thr results to be idential to those that would have > occurred if the COMP were removed rom the definition of the sending item. > > What it looks like (to me) is that AcuCOBOL is acting as if the sending item > could hold "001" and not "01". This may have to do wit the "normal" problems > related to "TRUNC/NOTRUNC" issues with binary data. I know MF, but don't know > AcuCOBOL. If they have a "TRUNC" option, you might try it with that and see if > the results are the same. Given a "hex" value of "01" for the sending item, > how can you determine if the "decimal" value is "001" or "01"? It should be the > latter acorrding to the Standard, but as many compilers (via a TRUNC option) > allow for values over decimal "99", this would be a problem. > |