Data is getting truncated while moving 9(10) to S(9) COMP

skarthik · New User Joined: 25 Feb 2008 Posts: 4 Location: chennai

Hi All,

Could any one please help me resolve the below query.

I am trying to Move 9(10) to S9(9) COMP. But value is getting truncated.

Code is as below -

MOVE 1234567890 TO WS-VAR2
MOVE WS-VAR2 TO WS-VAR3
DISPLAY 'VAR2 = 'WS-VAR2
DISPLAY 'VAR3 = 'WS-VAR3

Where the variables are declared as -

01 WS-VAR2 PIC 9(10) .
01 WS-VAR3 PIC S9(9) COMP.

The output is coming as -

VAR2 = 1234567890
VAR3 = 234567890

Thanks In Advance!!

Bill Woodger · Posted: Tue Oct 30, 2012 2:01 pm

If you move something with 10 digits into something with 9 digits, wouldn't you expect some truncation?

enrico-sorichetti · Posted: Tue Oct 30, 2012 2:02 pm

why not look at the manuals to understand
the different PIC clauses
how they relate to the number of significant digits that can be represented
how truncation occurs

manuals links at the top of the page

enrico-sorichetti · Posted: Tue Oct 30, 2012 2:05 pm

Robert Sample · Posted: Tue Oct 30, 2012 2:27 pm

Since WS-VAR3 is COMP, this is one of those not-so-rare cases where the compiler options can affect the results. With TRUNC(STD), the results are as expected (and observed) -- COBOL ensures the value in WS-VAR3 matches the PICTURE size. If you recompile with TRUNC(BIN), COBOL will use the storage area maximum instead of the PICTURE size, and that would allow the value to be stored without truncation.

However, note that it is NEVER a good idea to cause truncation (whether actual or potential) without understanding the potential impact.

Bill Woodger · Posted: Tue Oct 30, 2012 2:41 pm

If you go the TRUNC(BIN) route, or have a USAGE of COMP-5, be aware that you will still not be able to store "any" 10-digit value - try something this, for instance, 3000000000.

Also be aware that TRUNC(BIN) and COMP-5 cause more compiler code to be generated.

If you can come up with the slightest hint of what you are trying to actually do, there might be some suggestions. The more you tell, the better the suggestions.

skarthik · New User Joined: 25 Feb 2008 Posts: 4 Location: chennai

Sorry for the confusion guys. The requirment is -

I need to fetch customer details from DB2-Table based on Customer_id. This Customer _id field is INTEGER in the table, which is found as S9(9) COMP in DCLGEN. The Value of this CUSTOMER-ID coming from the file is X(10), which will be used to fetch the data. The code is -

01 WS-INFLE-CUST-ID PIC X(10)

MOVE WS-INFLE-CUST-ID TO CUSTOMER-IDENT

SELECT *
FROM CUSTOMER_DETAILS A
WHERE
A.CUSTOMER_IDENT = :CUSTOMER-IDENT

Now could you please let me know if there is any way to execute this query without data truncation.

Bill Woodger · Posted: Tue Oct 30, 2012 3:18 pm

What does your DB2 documentation say about the maximum value of INTEGER?

What is the maximum value that actually exists now for the Customer ID? For instance, if there is always at least one leading zero, you have no problem currently.

If the Customer ID can extend beyond the maximum value for INTEGER then you have a problem, as the ensuing truncation may cause data for one Customer ID to be assigned to another, or you may create data which cannot be retrieved.

Without knowing the actual data which is possible, no-one can GUARANTEE that this will work, nor that it will always work. If you have Customer ID starting with 3 or higher, then it will not work. The magic value at which it will theoretically stop working is your DB2 limit for INTEGER. It will stop working earlier depending on how you define CUSTOMER-IDENT (COMP-5 or not) or the compiler option previously mentioned by Robert.

In general, you have a potential mess, depending on actual existing/projected values for Customer ID.

skarthik · New User Joined: 25 Feb 2008 Posts: 4 Location: chennai

Hi Bill,

The customer_id has 10 digits in file and as well as in Table. some of the examples are below-

1130516048
1130516156
1130516219

For the above customers, I need to query the table to get the details. This customers are found in table also.

Bill Woodger · Posted: Tue Oct 30, 2012 4:08 pm

OK, try defining CUSTOMER-IDENT with COMP-5 instead of COMP.

I'd not move an X field to a numeric, I'd redefine it as 9(10). Not part of your problem, just "good practice" to me :-)

Note that this will not work "forever" and raise appropriate documentation.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

Hi Sarthik,

Look at JPVRoff's thread below in this forum. It might help.

Bill O'Boyle · Posted: Fri Nov 02, 2012 10:12 am

After redefining the sending-field as unsigned display-numeric and recompiling the program using TRUNC(BIN) or defining the receiving-field as COMP-5, change the picture of the receiving binary-fullword field to unsigned. It makes no sense to make it signed as the sending-field isn't.

This will increase the maximum value for the receiving-field from decimal 2147483647 (X'7FFFFFFF') to 4294967295 (X'FFFFFFFF'), which will give you more wiggle room.

Keep in mind that if you use a signed-fullword to view this data (such as in FileAid) and the value exceeds 2147483647, then it will be considered negative. If you use the unsigned approach, someone may raise the issue that this value is negative. With that, thorough documentation must be considered and the users must be made aware.

Bill Woodger · Posted: Fri Nov 02, 2012 9:33 pm

If you are unlucky, you get this scenario: your company takes over another company; they have a computer system, and their data is going to be subsumed into yours; they only have a nine-digit account number; someone comes up with the idea of "our numbers are 10 digits, but we'll never get towards the maximum, so we'll add the new data by prefixing their account number with an '8', that'll keep the systems guys happy as they won't have to do much".

Then someone from systems says, "yes, that should be OK" because they don't know that somewhere along the way someone thought that saving six-bytes per entry would be a "good thing".

I'd not suggest TRUNC(BIN), as that will affect any other COMP fields in your program, and some of the stuff generated for TRUNC(BIN) and COMP-5 is very ugly, so I like to keep it down to the minimum. Then you have other programs which may use COMP data from your program, and they'd have to be recompiled as well or risk pickling something.

Bill Woodger · Posted: Fri Nov 16, 2012 3:20 am

Just thought I'd try this. This is the sort of code you'll get generated each time you MOVE X(10) or 9(10) to a COMP-5 field: