Clear the contents of a Hash file.
Moderators: chulett, rschirm, roy
Clear the contents of a Hash file.
What is the command that i can use to clear the contents of a Hashfile in DataStage Administrator Command Line Interface.
Note: I already know how to clear the contents of the file using the Clear file check box option in the job.
Note: I already know how to clear the contents of the file using the Clear file check box option in the job.
Mayer,
as you have noticed, the CLEAR.FILE command does not accept file paths, it expects to have the filename you use declared as some type of a file in the local VOC and is not meant for remote files. Instead of using a UNIX command I think it advisable to use a DataStage job to clear the file using the checkbox in the Hashed file stage to clear the file before writing to it.
as you have noticed, the CLEAR.FILE command does not accept file paths, it expects to have the filename you use declared as some type of a file in the local VOC and is not meant for remote files. Instead of using a UNIX command I think it advisable to use a DataStage job to clear the file using the checkbox in the Hashed file stage to clear the file before writing to it.
You might use the following in a routine:
Are you sure that you are on UNIX and not windows? If on unix, the path separator should be / and not \
Code: Select all
OPENPATH '\imsv14\SAILDEV\hashfiles\Hash_BEngTaxonomyTermGroupKey' TO FileToClearPtr ELSE CALL DSLogFatal('Unable to open file','')
CLEARFILE FileToClearPtr ON ERROR CALL DSLogFatal('Uanble to clear file, status is "':STATUS():'".','')
CLOSE FileToClearPtr ;** this time Ray won't complain about my sloppy programming :)
Externally pathed hash files do not work with most TCL commands unless you've used the SETFILE command with them.
Why clear it when you can just delete it? Is it because you're not wanting to incur creation overhead because you have a minimum modulos? One of the best reasons to use externally pathed hash files is the ability to easily delete them using operating system commands.
Why clear it when you can just delete it? Is it because you're not wanting to incur creation overhead because you have a minimum modulos? One of the best reasons to use externally pathed hash files is the ability to easily delete them using operating system commands.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
There's no ON ERROR clause for the OPENPATH statement in Arnd's code, yet this is where a system error is most likely to occur.
And I consider any use of DSLogFatal (or STOP or ABORT) (...or CHAIN) to be sloppy programming.
clearfile (in the DataStage bin folder) can be run from the operating system shell and does accept pathnames.
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
clearfile (in the DataStage bin folder) can be run from the operating system shell and does accept pathnames.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Preferable is to use a small job (staying in the graphical paradigm). The job sends zero rows to the hashed file via a Hashed File stage, and the "clear file before writing" box is checked. Job runs in under one second.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.