Joined: 06 Jun 2008 Posts: 8280 Location: Dubuque, Iowa, USA
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.
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
FROM CUSTOMER_DETAILS A
A.CUSTOMER_IDENT = :CUSTOMER-IDENT
Now could you please let me know if there is any way to execute this query without data truncation.
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.
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
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.
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.