« Post-migration validation - is there an industry standard? | Main | Data Migration Planning - What are the natural sequence of events to follow? »
Tuesday
09Dec2008

Experiencing rounding errors when migrating from EBCDIC to ASCII via VSAM to Solaris

Hi, I'm currently working in a data migration project which involves migrating data from mainframe to solaris. The components that I'm currently working with is VSAM. VSAM datasets which are created by PL/1 programs, so they have data which correspond to PL/1 data types in them.

There are cetain data types which when converted from EBCDIC to ASCII cannot be used, because the way it is interpreted in Mainframe and Solaris are different.

We are using a tool called MTK from Clerity to convert the data from EBCDIC to ASCII.

The problem that I'm facing is, while validating the conversion process.

We have planned to follow a process in which the data in the files are converted in whatever format it is into text and written to a output file.

This process is followed both on mainframe and solaris. The output we get out of this process will be compared.

But there are some cases in which FLOAT DEC fields do not match because of rounding off in mainframe and solaris, they round off the data in different formats, which show as mismatch while comparing.

Can you please let me know how I can over come this.

For e.g. 2.99999E+02 on mf is 3.00000E+02 on solaris.

References (8)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (2)

EBCDIC to ASCII translation is relatively straight-forward, and really shouldn't be causing the problem you describe. You don't state that these are packed binary values on the VSAM side, but if they are, the problem is most likely to be occurring during the 'unpack' process.

I'm not familiar with the tool that you're using, but most I've used allow some adjustment to the accuracy of packed binaries. My best recommendation given the information provided is to try increasing the tolerance within the tool itself.

If this doesn't help, a little more detail may help us to provide better insight.

Mon, January 12 | Registered CommenterJay Varner

Thanks for the response..

Mon, January 26 | Registered CommenterNagendra Prasad
Member Account Required
You must have a member account on this website in order to post comments. Log in to your account to enable posting.