Windows: tsort file is not registered

Ed Purcell · Post by **Ed Purcell** » Wed Apr 02, 2014 3:11 pm

We are running v9.1 on Windows server 2008. 4 node config file
Warning message:
node_node3: APT_PMCleanUp::deleteFileRegistration: file E:/IBM/InformationServer/Server/Scratch3/tsortGwcflQsy is not registered.

Any idea what is the cause of this?

ray.wurlod · Post by **ray.wurlod** » Wed Apr 02, 2014 3:43 pm

DataStage has lost track of one of the temporary files created by a tsort operator and has discovered that that is so when trying to clean up.

You should regularly delete these orphans from the scratchdisk.

Ed Purcell · Post by **Ed Purcell** » Tue Apr 15, 2014 4:51 pm

This keeps happening regularly. The client is running DS v9.1 on Windows 8 under VMWare. Is this possibly a sign that their environment is messed up, or perhaps that the problem is running DS under Windows and VMWare?

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Tue Apr 15, 2014 5:56 pm

A good time to do cleanup is right before or after a re-boot, or at any other time when you can guarantee that there are no active jobs on the system. All "tsort" files are supposed to be temporary, so anything left hanging around can be deleted.

ray.wurlod · Post by **ray.wurlod** » Tue Apr 15, 2014 6:44 pm

Orphaned scratchdisk files are most typically left by aborted jobs. This is one of the reasons I create job designs that do not abort.

When a player process aborts, its controlling section leader (or even the conductor process) may attempt to clean up temporary/scratch files. I believe that this is happening in your case, but somehow it is losing track of which scratchdisk files are associated with each tsort player.

This might also happen where operator combination is occurring.

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Wed Apr 16, 2014 7:58 am

VMWare is supported as a DataStage platform, so supposedly you could call support to see if they could assist you. However, with these random type problems and two vendors involved it could be a long haul with lots of finger pointing between IBM and VMWare...