Joined: 19 Mar 2009 Posts: 185 Location: Globe, India
I am in a such a requirement where i have to convert a data from X(5) type to 9(2) COMP.
My source string will be always of below type with X(5):
1 character in the beginning and rest 4 are numbers.
e.g A1152, U1153, C0621 etc...
I understand that data with a character can not be converted into COMP field.
when i am passing U1153 to 9(2) COMP field, i am getting data as '41153' which is quiet obvious.
Is there any way to convert X(5) to 9(2) COMP for handling above situation?
I need to find some way as i have to write data to journal in 9(2) COMP format. Existing logic will decode it to displayable format further.
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
Whether it's 9(02) COMP or 9(04) COMP, it occupies two-bytes (halfword). Why not define it as 9(04) COMP and specify the TRUNC(BIN) compiler option or better yet, define it as COMP-5 (if supported by your compiler).
An unsigned halfword (either TRUNC(BIN) with COMP/COMP-4/BINARY or COMP-5 straightaway), has a maximum capacity of 65535 decimal (X'FFFF'). So, regardless of the definition used (and based upon your example data), you WILL have high-order truncation issues as well as other "opportunities".
Joined: 06 Jun 2008 Posts: 8449 Location: Dubuque, Iowa, USA
Unless there are rules that you haven't explained, what you want to do is not physically possible. There are 26 letters A to Z and with 4 digits there are 10,000 possible values (0000 to 9999). Hence there are 260,000 possible combinations of letters and digits. A PIC 9(02) COMP variable is a binary half-word or 16 bits. There are 65,536 unique combinations of 16 bits. You cannot squeeze 260,000 unique values into 65,536 unique values without losing something somewhere.
a-nice-name, with compile option TRUNC(OPT) or TRUNC(STD), has a maximum value of 99. The space occupied will be two bytes. With TRUNC(BIN), it behaves as does another-nice-name.
another-nice-name is as described by Mr Bill and Robert, 65,536 possibilities, or a value of zero to 65,535. As enrico has pointed out, it doesn't matter what you do, or what influence the compile options have, you are not going to be able to fully represent your input, no matter what existing code there is.