|
>Have you found a specific issue with 4B values? I never use them and >haven't for years, but I've been under the impression that they can be >used interchangably with 10i0 values provided the numeric range isn't >outside the scope of the variable. You're right on Bob. For the archives, I work with telephone switches and other non-IBM sources of data. Only IBM has a concept of defining a number by the number of digits (fixed length); everybody else uses a scheme directly tied to the hardware. Typically (but not always) it goes something like this: smallint = 2 to the 15 = 32,768 = 2 bytes int = 2 to the 31 = 2,147,483,648 = 4 bytes bigint = 2 to the 63 = 9.22 x 10 to the 18 = 8 bytes The issue is that most RPG folks automatically go for "4b 0" when they want a four byte binary number. Alas, that 4b turns into a nine digit maximum fixed number: 999,999,999. The other platform can send me numbers as large as 2,147,483,648, so clearly stuff gets lost. The problem with truncation is that it's subtle. Code that has worked for many years suddenly produces odd results; results that accumulate over time until finally at the end of the month, the profit report shows bizarre numbers which are traced back to daily imports that have been dropping the high order digit. Now I get to go back and re-import all that data and essentially re-run the whole month. This is basically the same problem with defining "work" fields the smallest possible size in order to "save memory." We've all seen that 3,0 loop counter fall apart when we bump the array to 5000 instead of 500. This is no different. 4b 0 saves one digit in memory compared to 10i. >From my particular view, it's a values issue. If the cell towers have ID numbers from 1 to 10, then 4b works great. When the cell company builds a new set of towers in another county and decides to number them 1,000,000,001 - 1,000,000,005 in order to make them stand out, then that working code is busted. My particular situation is that somebody else determines the maximum value: not me. If your code never gets data from external sources and never counts higher than the 4b limit, then sure, 4b is fine. But I automatically recommend that people use 10i, because that 4b is like a CHAIN without checking the indicator. Moving to the 10i costs nothing and the code becomes compliant with external data sources and APIs. There is only one place where you cannot use 10i, and that's when the binary variable has decimals, like 4b 2. But I have never seen that in a production database. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.