Handle Decimal Data Error Rpgle
Contents |
This document provides information about finding and correcting decimal data errors. Resolving the problem It is not uncommon for programs to have problems with decimal data errors when working with files that
Decimal-data Error Occurred In As400
originated on mainframes, non-IBM systems, and the IBM System/36. Program-described files are normally used mch1202 error in as400 on these systems and can result in non-numeric hexadecimal values in numeric fields. It is also possible for a program on decimal data error in as400 the IBM OS/400 or IBM i5/OS system to do this because program-described files are still available, especially for programs that have been migrated and are running in the System/36 environment. The following example takes advantage
Decimal Data Error In Cobol 400
of the field descriptions in externally-described files to correct the problem. The program reads in each record and writes it out making assumptions on what the correct value should be. You are responsible for evaluating the results of using this program. Because it is necessary to make assumptions, the results might not be what you require. However, there is a very good chance the results will be satisfactory. Always
Rpgle Monitor Decimal Data Error
keep a back-up copy of the file until you evaluate the results and are comfortable with the end result. In the case of zoned numeric fields, hexadecimal values such as blanks, control characters, and unassigned hexadecimal values are normally converted to zeroes. When letters or special characters (for example, the ampersand) are encountered, the first hexadecimal character is converted to an F. For example, the letter A is C1 in hex, while the letter a is 81 in hex. Both are converted to F1, which is the number one. In testing, 8aA69 is converted to 81169. However, when certain values are encountered in certain positions in the field, the entire field can be converted to a zero value. For packed numeric fields, an incorrect value in any position normally causes the entire field to be converted to a zero value. One exception was noted in testing. A 10-digit packed field requires a 6-byte field, and the first position of the first byte is not used. An incorrect value in that first position still produced a correct converted value. All other testing resulted in a zero value being produced. To create and run the program to correct your data, you should do the following: 1. Make a cop
download here. We have all encountered decimal data errors at some time or another. The biggest difficulty they present is that, by the time they have been detected, no recovery is possible. Or to be more precise, no practical recovery is possible. In my previous tip, I mentioned that one of the benefits of data structure I/O is that you can avoid decimal data errors. In this tip I'm going to show you how and why that works. The code package associated with this tip contains three test programs that demonstrate the different scenarios. The first is a straightforward RPG program with no defenses. It reads a file in a loop and will http://www-01.ibm.com/support/docview.wss?uid=nas8N1018444 encounter decimal data errors. The second is intended to show the basic use of DS I/O. It still has errors but they are subtly different. The third program demonstrates how to extend the program to fully defend against such errors. See the Readme.txt file for instructions on how to install the source code on your system. One factor that adds to the difficulty of handling data decimal errors is that that they may occur on http://www.itjungle.com/fhg/fhg031715-story01.html a READ or CHAIN operation, making it difficult to determine exactly which field is in error. This happens because the system detects the error while moving the data from the buffer to the internal variable. When we use DS I/O, the entire record is moved as if it were a large character field. In other words the numeric data is not differentiated. Since numeric fields are not differentiated they can't cause errors! Let's walk through the process of running each of the three programs so that you can see the differences between them. First, here are relevant portions of program DATAERRS1. FBadData IF E DISK DoU %EOF(BadData); Read BadData; If %EOF(BadData); Leave; EndIf; records += 1; total += amount; date = %Date(numDate: *YMD); EndDo; If you run this program, you will receive an error when reading the second record. Using F1 to look at the actual details of the error reveals that it occurred on one of the compiler-generated lines associated with the READ. This is even more obvious when you run the program in debug. If you tell the program to go (option G) you will find a similar error occurs on the reading of the third record. In both cases, determining which field is in error is problematic and the only valid option is to cancel the program. Now run p
available for download here, and it has been updated since it originally ran [Updated 06/13/07] I have seen requests many times in the forums from programmers asking how best http://www.itjungle.com/fhg/fhg061307-story01.html to handle data with invalid decimal data. Typically this type of error is first discovered when a program ends abnormally. I have found this problem occurs most often with data received from outside sources: customers and vendors. Many times this data comes from systems other than a System i. I've developed a command to identify and (optionally) "fix" errant data. What's in a Number? data error First, what is invalid decimal data? This is non-numeric data in a numeric field. For example, a field defined as "5s 0" should contain a number in the range of -99999 to +99999. The data is invalid if it contains values such as ABCDE or 123A6. Of course in the case of a zoned-decimal field such as this one, it is acceptable for the last decimal data error (and only the last) position to contain a value that appears to be alphabetic. This is because the last position of the field identifies the sign. To consider numeric values properly you must think in terms of the hexadecimal (hex) representation of the field. The first four bits of each byte are called the "zone" and the last four bits the "digit". Values for each zone and digit can range from 0 to 9 and A to F for the values 0 to 15 in the base-16 (hexadecimal). The base-10 (decimal) numbers 0 to 9 are defined for zoned-decimal fields in hex as F0-F9, respectively. The last byte identifies the sign of the value. For this byte only, the zone portion can be either a C or F for positive values and a D for negative. The hex representation of the zoned-decimal value 123 stored in a "5s 0" field is: F0F0F1F2F3 or F0F0F1F2C3. Packed fields are stored differently. Normally packed fields have an odd length, such as "7p 0" or "9p 2". The physical length of the stored data is: (scale of field + 1) / 2. For example, a "7p