DSXchange

Hi All,

We have an SAT environment in that the hashed files are already created in 32 BIT dynamic files. Today we changed the 32-bit into 64-BIT hashed files by changing the values in uvconfig file parameter: 64BIT_FILES 1. We have enough system space. we didn't do any other than this. But today while building the hashed files, the job(only 2 jobs) took 10 hours to complete. Normally this job took 2 hours to complete..Can you please suggest me what are the prerequisite while changing the 32-bit To 64-bit hashed file and also improving the performance. The rest of the hash building jobs ran normally.



Thanks & Regards,
Satheesh

Bad Idea. If that's something a search here turned up, it should have also revealed many caveats for enabling that option.

You have now made every hashed file 64bit. All of them - in your Projects, in the DSEngine, everywhere. You should change individual hashed files and only the ones that need it.

Hi,

But the hashed job that designed by using the create option delete file before create can be converted into 64 BIT , but the above option doesn't used job are not converted into 64BIT....is this result that the jobs(using above option) took much longer time than normal....any other things can be taken care.....please advice..


Thanks & Regards,
Satheesh

Reset 64BIT_FILES to zero and restart DataStage. As Craig said, to set this to 1 is a Bad Idea. Prefer to issue your own CREATE.FILE or mkdbfile commands to create 64-bit hashed files, but only when necessary. You can get the syntax from the Hashed File Calculator (on your DataStage CD).

64-bit hashed files have a 24 byte overhead (three eight-byte pointers) per record stored, or 40 bytes (five eight-byte pointers) if the record size is bigger than LARGE.RECORD. 32-bit hashed files have only half of this overhead.

You can use RESIZE to convert existing hashed files to 64-bit operation. You may need first to create a VOC entry for the hashed file, using SETFILE. Discussion of both these commands will be revealed by searching the forum.

Before doing any of this, however, consider whether you are not wasting space in the hashed file. Do you load any rows that you never look up? Do you load any columns that are never used in any job? Eliminating these might bring the overall size of the hashed file below the size at which internal 64-bit addressing is needed.

Thanks for your valuable guidance.



Thanks & Regards,
Satheesh