DSXchange

Hello,
We are migrating from DS 8.5 to 11.5.
In a parallel job, we read a flat file coming from Mainframe and load the content in a DB2 table.
The exact same Datastage code is used for 8.5 and 11.5.

When comparing results, for a field defined CHAR(10) :
in 8.5 we get the following hexa data in DB2: 434E465643440D202020
in 11.5 we get the following hexa data in DB2: 434E4656434420202020
So the 7th character has been replaced by a OD (CARRIAGE RETURN) instead of 20 (SPACE)

Any idea why ? A config parameter different between the 2 Datastage versions ?
Thanks for your help.

I would probably first run the data thru an OCONV with the MX control(if memory serves correctly...or other similar transform function...and put the result into the log or another sequential file) in both releases to see in a transformer "upstream" from the target what the hex values are...prior to loading into the database.....if only to see "where" the change occurs.

What is it "supposed" to be (ie...what is it in its origin)?

Ernie

Thank you for your feedback.
The idea was to compile as is without changing anything in the code when migrating from 8.5 to 11.5

Of course... but as we've seen here countless times, when someone is upgrading versions - especially when making such a large leap as you are - issues will be encountered. Typically you'll find that you have either been unknowingly taking advantage of a bug which has since been squashed or they've simply tightened up the code / process / driver so that something that used to "work fine" no longer does.

We'd need more details to help with this. Can you provide examples of the actual source data and also details about how / if you are transforming it before sending it to the target? Thanks.

Thanks Chulett ... it makes sense.

The data in input file is as follow :
CNFVCD followed by a carriage return

Then transformation :
Trim(From_Sf_x90txfrd.FICHIER[236,10]) goes into a CHAR (10) field that get loaded into a DB2 fied defined as CHAR (10)

In the DB2 table via DS 8.5 :
CNFVCD with carriage return and 2 spaces (hexa 434E465643440D202020)

In the DB2 table via DS 11.5 :
CNFVCD with 3 spaces (hexa 434E4656434420202020)

Is it the same version of DB2? If not, has the DB2 behaviour changed?

Same version DB2 v9.7.0.10

Perhaps Trim is doing something....but be sure it isn't the Source stage you are using. Prior to the trim, put in a Stage, as outlined prior, so that you can write out, or peek, the actual hex value BEFORE it goes into the trim and immediately after you read it from the source. By the way, what is the source ? CFF ? Sequential? MQSeries? Something else?

Ernie

This record file has a lenght of 241, last character is D (hexa 44) then a carriage return.
So ... Trim(From_Sf_x90txfrd.FICHIER[236,10]) ... get 6 characters from 236 to 241.
With 8.5, Trim add the carriage retun and 3 spaces (hexa 0D202020)
With 11.5, Trim add 4 spaces (hexa 20202020) so ignore the carriage return

Is the internal data type string or ustring?