Output Hash File Does not Modify Orginal creation Length?

[larryoceanview]

I have added on additional fields to an input file to a hash file but they are
not reflected on the output hash file.

I have the create file & clear file options checked on the Input option,
Don't see an output option.

The input to the hash file is an Aggregator.


Is it me or Datastage. Am I missing something.

How do you force a new output hash file to be created everytime.


Thanks,
Larry

[ogmios]

Hashfiles grow but they never shrink, unless you resize them.

The easiest is probably deleting the hash file after use and this depends on where you create the hash file: either in the project or in an explicit directory.

Ogmios

[larryoceanview]

Hashfiles grow but they never shrink, unless you resize them.

The easiest is probably deleting the hash file after use and this depends on where you create the hash file: either in the project or in an explicit directory.

Ogmios

I tried Renaming the hash file on the unix side so it wouldn't be found.
But when I ran the job in Datastage it still was looking for the old hash file name.

The file is in a specific directory for this job. But most of the other jobs in developement use the same hash file name but are also in their own unique directories.

I've seen a couple of posts where they delete from adminstrator, but I am reluctant because of the same hash file name.

Thanks,
Larry

[ogmios]

This is where the "fun" begins. I avoid hash files whenever I can, and if I have to use them I make sure it's recognizble to which jobs they belong (usually by using a prefix, but this would depend on how you make your ETL design).

If you moved the hash file, your job still runs correctly and no new hash file is being created in the place you expect then your job is most probably using another hashfile somewhere on your system. So your first action should be to find out where your particular job opens its hash file.

If you don't create the hash files "in your project" I don't think you can delete them via administrator: you would only need to physically delete the files of the hash file to get rid of the hash file.

Ogmios

[larryoceanview]

I deleted the links in and out and the hash file and used default names to force a new hash and did the set-up again.

I would really like to know the correct way to do this, because now the original hash file will be out there in never never land until somebody manually determines what it is and whos using it. Besides the time it took me to fix.

[ray.wurlod]

Let me see if I understand what you're doing. You have a Hashed File stage with an input link and an output file link.

On that basis let's investigate further.

A passive stage (for example sequential file, hashed file) with an output link in the job has the function to READ from that file or table. Therefore the file or table must exist.

A passive stage with an input link in the job has the function to WRITE to that file or table, whice therefore need not exist, and is why there is an option on the input link to create same.

You can force it to create a different file name each run by using a job parameter for the file name. There is a "delete file first" check box in the create file dialog. You would presumably want to use the same parameter on the output link, so you'd be reading from the same hashed file you've just written to.

Of course, your job design then has to clean up (delete) the hashed file once the job run is done. This could be effected in an after-stage or after-job subroutine. The actual subroutine and command used will depend on whether you created the hashed file in an account or directory.

• If you created the hashed file in an account, use ExecTCL and use the DELETE.FILE #HashedFile# command.
  If you created the hashed file in a directory, use ExecSH and use the rm #HashedFile# ; rm D_#HashedFile# command.

[larryoceanview]

• If you created the hashed file in an account, use ExecTCL and use the DELETE.FILE #HashedFile# command.
  If you created the hashed file in a directory, use ExecSH and use the rm #HashedFile# ; rm D_#HashedFile# command.

[/quote]

I know the directory where my hash files live but when you say account, do you mean a user account?

Thanks Ray!

[ray.wurlod]

When you use a Hashed File stage, you get the opportunity (in the Stage properties) to specify an "account" (= DataStage project) or "directory" as the location of the hashed file.

It is this "account" to which I referred.
It's location is decoded though the DataStage system table UV.ACCOUNT if you choose this mechanism.

Sounds like you have opted to choose the other mechanism (directory) in line with documented best practice.

[kduke]

Larry

I have added on additional fields to an input file to a hash file but they are
not reflected on the output hash file.

I have the create file & clear file options checked on the Input option,
Don't see an output option.

The input to the hash file is an Aggregator.


Is it me or Datastage. Am I missing something.

How do you force a new output hash file to be created everytime.


Thanks,
Larry

This sounds like a metadata issue. You need to save the metadata from the job or link where you added the new columns to and load in the new columns to the other link that reads this same hash file.

Maybe I missed something but I think the answers got off track.