Joined: 03 Jul 2007 Posts: 1287 Location: Chennai, India
Hi,
A field is declared as smallint in a table and the DCLGEN variable is S9(4) COMP.
In our cobol code we had wrongly moved an alphanumeric value (X(8)) to this dclgen variable. The move was successful and finally the value got inserted in the table.
when i checked the table it had some numeric value populated in that column. i really dont know whether to call that as junk or random no.
when EBNKG was moved to that destination field, the table got updated with 32767.
There should be some rules for these type of move's and please help me in understanding this.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
When a field is defined as S9(4) COMP (which in Mainframe terminology is a signed binary-halfword), the maximum positive value it can retain is +32767 (X'7FFF'), whereas, the maximum negative value it can retain is -32768 (X'8000'). Keep in mind that the ever popular TRUNC compile option is also a factor, unless your compiler supports COMP-5 (known as Native Binary).
When a field is defined as 9(4) COMP, which is an unsigned binary-halfword, the maximum value it can retain is 65535 (X'FFFF').
If you attempt to check whether a binary-field is NUMERIC, you'll get a compile error, because (in this example) an unsigned halfword can retain a value of X'0000' through X'FFFF' and therefore, a NUMERIC check would be illogical.
A halfword is two-bytes and a fullword is four-bytes.
But, you can't move a PIC X value to a binary halfword or fullword, unless you redefine them as PIC X(02) or PIC X(04), respectively.
I'm still scratching my head wondering how (after moving EBNKG to it), the halfword resulted in +32767.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello Aaru,
Well, 32767 is the highest positive value that can be stored in a 2-byte comp field (x'7FFF'). If you were to "dump" that column, i suspect you would find that hex value.
In a comp field, every value is "some number". There can be nothing else as every hex value equates to some number in binary.
Your code fell into one of the compiler "black hole"s. It saw the move and said to itself "Self, i can do that". And so it did - as well as it could.
You may want to look at this topic from a while back (you even participated).
http://ibmmainframes.com/viewtopic.php?t=25463&highlight=valid+cobol+move
Near the bottom of the topic is the matrix of moves the compiler believes to be valid. That they are "valid" does not mean that the result will be what one expects.
To learn more particulars, i'd suggest you create some test output by trying combinations of field definitions and values. If you write this into a little file, you can view the results in hex and see what happens for the various moves tested.
What i've done for a long time is to go "overboard" validating that i will not move a field defined as pic x to a numeric field. If i need to get a picx value to numeric, i write code to specifically validate/reformat the content then to do the move.
