DSXchange

DataStage failed to create all the required project records in XMETA, you will not be able to create a project with this name until these are removed. If you can live with another project name, then that is a workaround. You will need help from support to remove the existing items if you require to ...

I suggest you check the WAS logs for errors, you may find something relevant to this job. I believe that the XMETA representation of the job has become corrupt, and that you will need help from your support provider to remove the job from XMETA, and restore from a backup.

There is no scheduling info in XMETA, this info is in the executable job (RT_CONFIGnn), so is in the DS Server Project.

I don't think you can drive dssh from a file, but the same logic in a UV BASIC program would be reasonably simple, or use the dsjob api to get the lists of jobs and scheduling info.

The information that is in the DSX of an executable job for scheduling is in the record "JOBSCHEDINSTS" of RT_CONFIGnnn. And the parameters are in JOBPARAMINSTS. The records are not present if the job has not been scheduled. I can see these records using "CT RT_CONFIGnnn JOBSCHEDINSTS...

You can see that information in the RT_CONFIGnnn file, or export the executable and it is visible in the DSX too.

I think a 'workaround' is what you do to get a process to work while reporting the bug to support and waiting for a fix.
Several times in the past I have had to protect calls to APIs that were not checking for bad arguments, whilst also reporting the API crashes to the vendor.

Same answer:
You can't use an environment variable 'there'.
The workaround is to use GetEnvironment("envvarname")

You can't use an environment variable 'there'.
The workaround is to use GetEnvironment("envvarname")

I believe your user needs read & execute access to /usr/spool/cron/atjobs

Search for 'dsjob', this is used to run jobs from the command-line, specifying server,project,job,parameters,...

Or they might have broken the ability to see it inadvertantly, and be fixing it for 8.1.

Delete the InstallShield folder:
C:\Program Files\Common Files\InstallShield\Universal\IBM\InformationServer

You definitely need help from Support for this, to get your repositories in a consistent state after removal of the ROOT data.

Anything that ends Input or Output is likely to be the appropriate end of a Link.

All, 4. When I changed the password for Windows login, DataStage Client does not allow me to enter into DataStage using "Omit"(I used to enter DataStage using this option before changed the password). Upto my knowledge, DataStage checks the old passeord with the new one and throws an erro...