Error with SETFILE command in a before-stage subroutine

[Alethesnake]

Hi All,
I've a strange error with a simple job.
In a before stage subroutine of a transformer I define a VOC pointer in this way:

SETFILE #$aDirHashedFiles#\HF_CIM_CD HF_CIM_CD_REF OVERWRITING

The pointer is used in an universe stage linked to that transformer.

If I run the job stand alone, it runs well: the pointer is correctly created and the job produces the results I'm looking for.

The problem is when I run the job via a sequencer that contains it. When this job is executed I get an abort with the following error (from the director):

PZMAS020IRR..Transformer_0 (ExecTCL): Error when executing command: SETFILE E:DATI\ETL\HASHFILE\TIMONE\HF_FILIALE_CD HF_FILIALE_CD_REF OVERWRITING
*** No output from UniVerse command ***



Have you got any suggestion about this?

[gateleys]

Change your command to -

SETFILE #$aDirHashedFiles#\HF_CIM_CD HF_CIM_CD OVERWRITING

I tried it and it seems to run fine in both stand-alone job and when embedded in a sequence job.

[Alethesnake]

The problem is not on the name of the pointer, sometimes it runs and sometimes no (both mine and your version)..
I've asked for a restart of the datastage server, let's see if it solves the problem

[ray.wurlod]

It won't.

Try removing the VOC pointer in an after-stage subroutine so that SETFILE is guaranteed to be clean on the next run.
DELETE VOC 'HF_CIM_CD_REF'

Delete both pointers from VOC in the Administrator client Command window.

[Alethesnake]

Hi Ray,
it seems that the restart solves the problem (sometime our test server degrade in performaces..).

Is it a good practice to delete pointers after their use?

(The pointers created will be useful only to this job and this process will run monthly.)

My doubt is that a continuous deletion/insertion of pointers will generate a sort of fragmentation of the "file" (an hashed file?) where they are saved. Is it possible?

[ray.wurlod]

Fragmentation will not be an issue. The hashing algorithm pretty much always guarantees the same location in the VOC file, because it is a static hashed file (one in which the number of groups does not change over time without manual intervention).