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: Judson McClendon on 5 Jan 2008 11:08 "C Goodman" <foxgrove(a)shaw.ca> wrote: > 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. Hopefully, a TRUNC or equivalent compiler option will do it for you. If not, for that size task, you might want to write a program that scans for such moves. Since you're looking for COMP fields, you don't need to parse the picture clauses completely. You just need to check for a COMP sending field, and an alpha field, or vice versa. If you do, beware of MOVE CORRESPONDING. Writing the code to process those could be as much work as decoding the picture clauses. -- Judson McClendon judmc(a)sunvaley0.com (remove zero) Sun Valley Systems http://sunvaley.com "For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
From: C Goodman on 5 Jan 2008 11:56 Luckily, no MOVE CORR I like your idea of a program to scan for COMP and DISPLAY, I shouldn't have any problem modifying some old code I have that looks for GO TO branching outside PERFORM ranges. Judson McClendon wrote: > "C Goodman" <foxgrove(a)shaw.ca> wrote: >> 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. > > Hopefully, a TRUNC or equivalent compiler option will do it for you. If > not, for that size task, you might want to write a program that scans for > such moves. Since you're looking for COMP fields, you don't need to parse > the picture clauses completely. You just need to check for a COMP sending > field, and an alpha field, or vice versa. If you do, beware of MOVE > CORRESPONDING. Writing the code to process those could be as much work as > decoding the picture clauses.
From: William M. Klein on 5 Jan 2008 14:29 Replying to this note and some others in the thread: 1) A move of a "non-integer" COMP field to a USAGE display fields *IS* legal according to the Standard (and it is legal whether the COMP field is signed or non-signed). 2) Having any value GREATER than "99" in a field with PIC 99 (or PIC S99) is NON_conforming and this is what will cause you problems (and does cause problems for even the cases less than "99"). The Standard *only* defines the behavior for when the numeric field (ALL usages) contains data that conforms to the PICTURE - even if the "storage" would allow a greater value, e.g. PIC 99 with X"64" or greater (dec 100 or greater). In fact the '02 Standard says that given: 01 Group-1. 05 Num Pic 99 Binary 01 Num2 Pic 9999.999. ... Move X"94" to Group-1 Move Num to Num2 will cause an EC-DATA-INCOMPATIBLE condition to exit. In other words (contrary to most "common sense"). In STANDARD CONFORMING ('02 Standard), you CAN get "incompatible data" for a binary (or COMP) data item. If you are converting from AcuCOBOL to Micro Focus (and the opposite way), then the thing you should try is using NOTRUNC with MF - in order to allow for to a numeric binary (COMP) field with potentially 3 decimal digits. Alternatively, (and I haven't tried this) you might try changing the sending fields from COMP to COMP-X (an MF extension). COMP-5 *might* also do it, but I think there is a better chance that COMP-X would. You need to know, however, that whenever you have a PIC 99 COMP field that you expect to be able to handle values greater than decimal 99, that you are in the world of non-Standard and non-Portable behavior. The same is true for BINARY (for implementations where USAGEs Binary and COMP are equivalent). In other words, I would say that MF is working "as required by the Standard" for values between 0 and 99, but that AcuCOBOL is working "in a desirable way" for values between 100 and 255 - but this is non-portable and non-Standard. -- Bill Klein wmklein <at> ix.netcom.com "C Goodman" <foxgrove(a)shaw.ca> wrote in message news:477F9D74.1070707(a)shaw.ca... > 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. >>
From: Judson McClendon on 5 Jan 2008 15:22 "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: > Replying to this note and some others in the thread: > > 1) A move of a "non-integer" COMP field to a USAGE display fields *IS* legal according to the Standard (and it is legal whether > the COMP field is signed or non-signed). > > 2) Having any value GREATER than "99" in a field with PIC 99 (or PIC S99) is NON_conforming and this is what will cause you > problems (and does cause problems for even the cases less than "99"). The Standard *only* defines the behavior for when the > numeric field (ALL usages) contains data that conforms to the PICTURE - even if the "storage" would allow a greater value, e.g. > PIC 99 with X"64" or greater (dec 100 or greater). > > In fact the '02 Standard says that given: > > 01 Group-1. > 05 Num Pic 99 Binary > 01 Num2 Pic 9999.999. > ... > Move X"94" to Group-1 > Move Num to Num2 > > will cause an EC-DATA-INCOMPATIBLE condition to exit. In other words (contrary to most "common sense"). In STANDARD CONFORMING > ('02 Standard), you CAN get "incompatible data" for a binary (or COMP) data item. > > If you are converting from AcuCOBOL to Micro Focus (and the opposite way), then the thing you should try is using NOTRUNC with > MF - in order to allow for to a numeric binary (COMP) field with potentially 3 decimal digits. Alternatively, (and I haven't > tried this) you might try changing the sending fields from COMP to COMP-X (an MF extension). COMP-5 *might* also do it, but I > think there is a better chance that COMP-X would. > > You need to know, however, that whenever you have a > PIC 99 COMP > field that you expect to be able to handle values greater than decimal 99, that you are in the world of non-Standard and > non-Portable behavior. The same is true for BINARY (for implementations where USAGEs Binary and COMP are equivalent). > > In other words, I would say that MF is working "as required by the Standard" for values between 0 and 99, but that AcuCOBOL is > working "in a desirable way" for values between 100 and 255 - but this is non-portable and non-Standard. Bill, you're making the assumption here that the problem *is* the TRUNC issue. You're probably right, I agree, but until it's tested or documentation is found to describe the behavior, that isn't certain. It could simply be a bug or other anomaly in AcuCOBOL. Also, in your "If you are converting from AcuCOBOL to Micro Focus" paragraph, you seem to forget that he's working with a functioning system. If he changed to NOTRUNC, the current MF system would exhibit similar bugs to those he is trying to resolve now. :-) I agree that, if the AcuCOBOL problem is TRUNC, it would allow you to develop a new system to work with both compilers. -- Judson McClendon judmc(a)sunvaley0.com (remove zero) Sun Valley Systems http://sunvaley.com "For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
From: C Goodman on 5 Jan 2008 17:38
Hey Peter, It's been a few years. What have you bee up to? Ever play bridge? Send me an email. ---Charlie foxgrove(a)shaw.ca |