DSXchange: DataStage and IBM Websphere Data Integration Forum
View next topic
View previous topic
Add To Favorites
Author Message
challard1
Participant



Joined: 14 May 2016
Posts: 18

Points: 134

Post Posted: Thu Jul 12, 2018 7:38 am Reply with quote    Back to top    

DataStage® Release: 8x
Job Type: Parallel
OS: Unix
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.

_________________
Cyrille Hallard
eostic

Premium Poster



Group memberships:
Premium Members

Joined: 17 Oct 2005
Posts: 3780

Points: 30348

Post Posted: Thu Jul 12, 2018 9:07 am Reply with quote    Back to top    

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 ...

_________________
Ernie Ostic

blogit!
Open IGC is Here!
Rate this response:  
Not yet rated
challard1
Participant



Joined: 14 May 2016
Posts: 18

Points: 134

Post Posted: Thu Jul 12, 2018 9:27 am Reply with quote    Back to top    

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

_________________
Cyrille Hallard
Rate this response:  
Not yet rated
chulett

Premium Poster


since January 2006

Group memberships:
Premium Members, Inner Circle, Server to Parallel Transition Group

Joined: 12 Nov 2002
Posts: 42751
Location: Denver, CO
Points: 220300

Post Posted: Thu Jul 12, 2018 10:17 am Reply with quote    Back to top    

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.

_________________
-craig

Research shows that 6 out of 7 dwarves aren't happy
Rate this response:  
Not yet rated
challard1
Participant



Joined: 14 May 2016
Posts: 18

Points: 134

Post Posted: Thu Jul 12, 2018 11:02 am Reply with quote    Back to top    

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)

_________________
Cyrille Hallard
Rate this response:  
Not yet rated
ray.wurlod

Premium Poster
Participant

Group memberships:
Premium Members, Inner Circle, Australia Usergroup, Server to Parallel Transition Group

Joined: 23 Oct 2002
Posts: 54368
Location: Sydney, Australia
Points: 294905

Post Posted: Thu Jul 12, 2018 1:34 pm Reply with quote    Back to top    

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

_________________
RXP Services Ltd
Melbourne | Canberra | Sydney | Hong Kong | Hobart | Brisbane
currently hiring: Canberra, Sydney and Melbourne
Rate this response:  
Not yet rated
challard1
Participant



Joined: 14 May 2016
Posts: 18

Points: 134

Post Posted: Thu Jul 12, 2018 1:43 pm Reply with quote    Back to top    

Same version DB2 v9.7.0.10

_________________
Cyrille Hallard
Rate this response:  
Not yet rated
eostic

Premium Poster



Group memberships:
Premium Members

Joined: 17 Oct 2005
Posts: 3780

Points: 30348

Post Posted: Thu Jul 12, 2018 9:45 pm Reply with quote    Back to top    

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 ...

_________________
Ernie Ostic

blogit!
Open IGC is Here!
Rate this response:  
Not yet rated
challard1
Participant



Joined: 14 May 2016
Posts: 18

Points: 134

Post Posted: Fri Jul 13, 2018 4:43 am Reply with quote    Back to top    

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

_________________
Cyrille Hallard
Rate this response:  
Not yet rated
ray.wurlod

Premium Poster
Participant

Group memberships:
Premium Members, Inner Circle, Australia Usergroup, Server to Parallel Transition Group

Joined: 23 Oct 2002
Posts: 54368
Location: Sydney, Australia
Points: 294905

Post Posted: Wed Jul 18, 2018 7:37 pm Reply with quote    Back to top    

Is the internal data type string or ustring?

_________________
RXP Services Ltd
Melbourne | Canberra | Sydney | Hong Kong | Hobart | Brisbane
currently hiring: Canberra, Sydney and Melbourne
Rate this response:  
Not yet rated
Display posts from previous:       

Add To Favorites
View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



Powered by phpBB © 2001, 2002 phpBB Group
Theme & Graphics by Daz :: Portal by Smartor
All times are GMT - 6 Hours