Why use ADD 0 GIVING instead of MOVE? 3

[dbleyl]

What would be the reason to fill a numeric variable by ADD'ing 0 instead of MOVE?

05 CLS-A PIC 9(5) COMP.
05 CLS-B PIC X(2).
05 DSP-A PIC 9(5).
05 DSP-B PIC X(2).

ADD CLS-A, 0 GIVING DSP-A.
MOVE CLS-B TO DSP-B.

Where the DSP-A & B variables are members of a type passed to the COBOL DLL from a VB app by Ref (the VB types are all fixed length strings) and the CLS variables are FD'd for file access.

Sorry if this is extremely simple. The COBOL programmers I've asked are not sure either.

 

[k5tm]

COBOL compiler? Operating system?

Tom Morrison

http://www.liant.com

 

[Dimandja]

That code seems headed for doom. In any language, variables should be explicitly initialized.

If your compiler is overly generous, you may get with it, though.

Dimandja

 

[TonHu]

I asked more experienced Cobollers then myself the same Q, but the only answer they could come up with, was, that there must have been some stupid bug in some long forgotten cobol compiler, where the

MOVE

didn't work propperly, under certain circumstances. This is not a very satisfying answer :-(

If anybody could come up with a plausible answer, I'll toss in a star

TIA
TonHu

 

[MarcLodge]

I'm guessing here, but is it something to do with the machine instructions that 'ADD 0 GIVING' generates over MOVE when the move statement is dealing explicitly with numeric fields?

Marc

 

[webrabbit]

I'm not sure, but I found with Micro Focus COBOL, the following does not work as expected:
[tt]
$SET COMP
77 SIGNED-BINARY PIC S99 COMP-5 VALUE -1.
77 UNSIGNED-BINARY PIC 99 COMP-5.
. . .
MOVE SIGNED-BINARY TO UNSIGNED BINARY
DISPLAY UNSIGNED-BINARY
[/tt]
The result is 255! I changed the target to DISPLAY and it worked as expected. I never thought of using
[tt]
ADD ZERO TO SIGNED-BINARY GIVING UNSIGNED BINARY
[/tt]
Perhaps that would have stripped the sign off as I wanted. The problem of course is in the "$SET COMP" which causes non-standard but highly optimized binary processing.

 

[k5tm]

Well dbleyl seems not to respond to direct questions but here is one reason you might see something like this, from the history of RM/COBOL.

The old 1974 RM/COBOL was not really consistent when it came to COMP/COMP-3 negative sign representation. When we designed the 1985 RM/COBOL we adopted IBM sign conventions (i.e., 0xC, 0xD and 0xF). Our recommendation to those converting data files that had the possibility of some of the inconsistent negative sign representation was to add zero to the number. We were permissive in the sense that anything that did not have a positive sign was considered to be negative. The ADD 0 trick got the data stored in a consistent fashion.

Consistent data representation became important because several optimizations were introduced in the newer compiler that would fail if data representations were not consistent.

Tom Morrison

http://www.liant.com

 

[dbleyl]

Sorry for not responding sooner - Thanks for all the help.

I am using vim to view the files on win2k. The COBOL programmers are saying it's MicroFocus NetExpress 3.1. In the .LST files, it says:
Micro Focus Object COBOL V4.0 revision 007

A few sparse comments in the source indicate '00 and '97, but the code is said to have been ported many times over the years (from mini), its much older than that.

This is one of those situations were instinct is to leave things alone that don't seem to make sense for fear of breaking things, but things are already broken, in the sense that the DLL has been returning some bogus data.

As one of the posts alludes to, I suspect part of the problem is uninitialized variables - we are getting a lot of
2020 and 2020202 values for numeric data, which I just learned somehow means space.

Thanks for everyones' help.

 

[webrabbit]

Yes, indeed "2020202" means a PIC S9(7) COMP-3 variable had a value of spaces (X"20202020&quot. The last hex digit is treated as the sign and the others as decimal digits. Where the "2020" would come from I'm not sure. Perhaps a PIC S9(4)V9 COMP-3 variable.