DSXchange

Hi All,

Could you please help me understanding if there is any harm in replacing DS_RESENU from other project?

we are facing some issue where our job is failing because of below error and want to replace DS_RESENU from other project in PRODUCTION environemnt, because it looks like that it corrupted?

"JOB.134593497.DT.1542937105.TRANS1": Line 126, Internal data error.
File '/dstage/dsdata/EnCngProd/Msnps/Hashim//CnvCsmCom210_VsubstshXref/DATA.30':
Computed blink of 0x1048 does not match expected blink of 0x0!
Detected within group starting at address 0x800AB000!

thanks much in adv for response on this.

Akumar

I'm curious how you got from the error that you posted to "DS_RESENU"? You've got a corrupted hashed file which an exact search for "Computed blink" here would reveal. I'm also curious why the Job Type is marked as Parallel.

OK, found the reason for DS_RESENU: this older post which had an actual problem with that particular hashed file. You drew the wrong conclusion as you don't have "the same issue". Similar but not the same.

ps. I removed your post from that other topic.

Apologies for posting the issue in rush, and yes this issue is related to server job , not PX , and also I have searched similar post in the dsxchange and found info about DS_RESENU.

can anyone help me to fix this issue?, and also let me know what is causing the same.

Few more details
The job is reading data from a table and having a hashed file as lookup and using a transformer it is trying to write back to a target hashed file.

Data volume:
Look file almost 2 GB
having 23 million of rows

Thanks,
Akumar

I've already given you your starting point - perform the exact search I mentioned. You'll find plenty of posts detailing both the problem and the solution. You've got the name and full path to the actual hashed file that has the issue, now you just need to fix it... and prevent it from happening again.

Note too that DS_RESENU does not need to be replaced. This is not the hashed file that has the problem.

Thanks Ray, By the way I just want to let all know that the issue has been fixed now, also the caused because the hashed file was larger than 2 GB hence we Applied RESIZE command to change the hash file size from 32 to 64.
also we contacted IBM for the issue where they suggested below solution. but we just took step mentioned above.

Response from IBM:

You can change the following parameter in the uvconfig
file in the DSEngine directory to create --new-- hash files
as 64 bit:

# 64BIT_FILES - This sets the default mode used to
# create static hashed and dynamic files.
# A value of 0 results in the creation of 32-bit
# files. 32-bit files have a maximum file size of
# 2 gigabytes. A value of 1 results in the creation
# of 64-bit files (ONLY valid on 64-bit capable platforms).
# The maximum file size for 64-bit
# files is system dependent. The default behavior
# may be overridden by keywords on certain commands.
64BIT_FILES 0

You would need to do the following:

vi uvconfig
change 64BIT_FILES from zero to one.

Bring down DataStage as the dsadm user:

Make sure no jobs are running and no Designers
or Directors are open.

cd DSEngine
. ./dsenv
bin/uv -admin -stop
bin/uvregen
bin/uv -admin -start

After this, newly created hash files will be created
as 64 bit files and can grow larger than 2 GB.


Thanks,
Akumar1

Think CAREFULLY before you just turn that last option on, it will affect ALL washed files created afterwards... all, not just ones your jobs may use. Search here for many discussions to that effect.

chulett wrote:Think CAREFULLY before you just turn that last option on, it will affect ALL washed files created afterwards... all, not just ones your jobs may use. Search here for many discussions to that effect.

Not just washed files, but hashed files too.

I believe that this is poor advice from IBM support. You NEVER want all your hashed files to be 64-bit unless, perhaps, you're on a 64-bit operating system.

Pffftttt... stupid auto-correct. That's what I get for posting from my cell phone.