Troubleshooting
Problem
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 originated on mainframes, non-IBM systems, and the IBM System/36. Program-described files are normally used on these systems and can result in non-numeric hexadecimal values in numeric fields. It is also possible for a program on the IBM i 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 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 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:
Important Note: Detailed explanations of this document are best handled under a consulting contract with IBM.
The following example takes advantage 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 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 copy of the file so you can examine the resulting changes. To avoid accidentally updating the production copy, use a different name for the copy. For example, if the original name is ORDDET, the copy could be ORDDETX. Note: Ensure you are not using an existing file name in this case. It is also suggested to create a work library and place the copy there. QTEMP can also be used because no other user can access a copy in QTEMP, and it is automatically cleared when your job ends. This reduces wasted disk space used by temporary files no longer needed. |
| 2. | Add the work library to your library list. It is also recommended that you remove your production library or libraries from your library list. As an alternative to removing the production library from the library list, you can display the library list to ensure that the work library is before the production library. The OVRDBF command can also be used to point the program to the correct file. |
| 3. | Create a RPG source member based on the following: FFILENM UP E DISK C UPDATRCDFMT Use the file name in the F spec and the record format name in the C spec. If they have been defined to be the same for your file, use the OVRDBF command, which allows you to use a different file name in the RPG program but overrides the program name to your actual physical file name. This is also required if your actual file name is longer than 8 characters when using OPM RPG. You can also rename the record format name in the RPG program. |
| 4. | The RPG program cycle takes care of reading each record and writing it back out in a valid format. It is the RPG program cycle that makes this two-line program possible. Create the program using the CRTRPGPGM command. Use F10 to display additional parameters and change the Ignore decimal data error parameter to *YES. Ignore decimal data error . . . IGNDECERR *YES |
| 5. | Call the program and examine the results. |
| 6. | If the results are satisfactory, change your library list and/or the overrides to the production copy and run the program again to update the production copy. If no other changes have been made to production during your testing, use the CPYF command to replace the production copy with the work copy. |
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000001i3CAAQ","label":"IBM i Db2-\u003EDDS - Data Definition Specifications"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
10953306
Was this topic helpful?
Document Information
More support for:
IBM i
Component:
IBM i Db2->DDS - Data Definition Specifications
Software version:
All Versions
Operating system(s):
IBM i
Document number:
642807
Modified date:
05 December 2024
UID
nas8N1018444
Manage My Notification Subscriptions