Joined: 14 Jan 2008 Posts: 2504 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.
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.