We have a pretty good idea that it's only numeric fields that may have issues.
I suppose possibly some date fields as well, but since this is old RPGII code those were probably numerics.
One thought process is to simply identify the potential bad records with an SQL statement and update to 0 where (bad data condition = ????)
No matter what the data will be fixed after copy form flat file to DDS structures.
And the RPGII will be in use ongoing for quite a while so we will probably have to run these fixup routines regularly for a while or fix some of the old offending programs.
First step is getting flat files to DDS and then decide whether to develop apps in new languages or convert existing Apps to ILE with internally defined DDS.
That interpret() function looks interesting.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
------------------------------
message: 4
date: Mon, 16 Mar 2026 16:12:58 +0100
from: Daniel Gross <daniel@xxxxxxxx>
subject: Re: Identifying Numeric Columns with Bad Data - S36 DDS
Conversion
Checking data afterwards is not so easy - if you build a SQL/DDL table, the data is validated on INSERT - this differs completely from a PF/DDS file, as there data is validated on READ.
So one solution could be, to create a view over the /36 file with extra columns created using the INTERPRET function:
https://www.ibm.com/docs/en/i/7.5.0?topic=functions-interpret
As an example, a packed decimal with 6 digits and 2 decimals reserves 4 bytes. A binary value of 0x0123456F would then stand for a value of 1234.56. If this 4 bytes start at position 25 of a string, you can extract and interpret it with
INTERPRET( SUBSTR(yourString, 25, 4) as DECIMAL(6, 2) )
But it can be a problem, as the /36 file has no named record format and I also don't know which name the single large field has - but you can find out with a SELECT.
HTH
Daniel
midrange.com
