DSXchange

Test258_Prod_Num: Failed to load the library "V0S397_Test258_Prod_Num.o". Either the directory containing the library file is not on the library search path, or the library was compiled on a system that is incompatible with this system. Could not load "V0S397_Test258_Prod_Num": 0509-022 Cannot load module /sysp/DataStage/Projects/TEST/RT_BP358.O/V0S397_Test258_Prod_Num.o.
0509-103 The module has an invalid magic number..



When try to run the job, the above fatal error occur, how to solve the problem. I have export an executable from another project, and import to this project, found that the job can't be run.

Thanks for reading.

Need your help.

Have you exported/imported the executable from/to a project on the same DataStage machine?

Benny,

the error message is really quite clear - you have imported a job compiled elsewhere and when run it tells you that it has a bad magic number. Can you recompile the job in the new project and then run it?

ArndW wrote:Benny,

the error message is really quite clear - you have imported a job compiled elsewhere and when run it tells you that it has a bad magic number. Can you recompile the job in the new project and then run it?

ArndW, I only got the executable, but not the source, so I am unable to toe recompile that job. How to do ?

Eric wrote:Have you exported/imported the executable from/to a project on the same DataStage machine?

Eric, yes, on the same machine, different project

Go to the UNIX prompt, and verify that the file exists on that directory.

T42 wrote:Go to the UNIX prompt, and verify that the file exists on that directory.

T42, I have checked, those library files exist, but with size = 0

Btw, if it doesn't exist, what should I do ? Why does the export can not capture all the elements it need ?

Hello,

you have a problem with the export, the binary file being empty in your dsx file exported (you can check this in the dsx file itself with a text editor).

Perform a 'Force compile' of the job in the source project and then the export/import procedure of the job. It will do it .

Benouche

Benouche wrote:Hello,

you have a problem with the export, the binary file being empty in your dsx file exported (you can check this in the dsx file itself with a text editor).

Perform a 'Force compile' of the job in the source project and then the export/import procedure of the job. It will do it .

Benouche

Benouche, I have tried to export more than one times, but the result is the same. The exported dsx file is not empty, but after imported, the library file is empty.

What 's worse is I haven't the source job, so that I can't recompile them.

As someone told me before, if the executable has been run, then the problem occur, otherwise, it works well. Why would this happen ???

If the executable being run, the library file will be revised ???

Please help !!!

the dsx file you have does not contain the .o file needed for the execution of the job. Look into the file and you'll find a msg explaining the .o file is missing.

That's why you MUST get back to the source project and do or ask for a "force compile" before export.

Benouche wrote:the dsx file you have does not contain the .o file needed for the execution of the job. Look into the file and you'll find a msg explaining the .o file is missing.

That's why you MUST get back to the source project and do or ask for a "force compile" before export.

Benouche, thank you for your reply. My case is I have a project only contain executable without job design. What I want to do now is to export the executable to another project for running.

But the worse case is I haven't the job design, so that I can't recompile.

Any other solution ?

Solution: Include the job design next time.

There is really no good reason. Having the job design would allow you to visually verify and diagnosis problems with your programs if it fail. Like for this situation.

Everyone seems to be bypassing your complaint that you do not have the source, and for a very good reason. This problem cannot be resolved without the source. You will need to reconstruct the job from original specification documents.

T42 wrote:Solution: Include the job design next time.

There is really no good reason. Having the job design would allow you to visually verify and diagnosis problems with your programs if it fail. Like for this situation.

ray.wurlod wrote:Everyone seems to be bypassing your complaint that you do not have the source, and for a very good reason. This problem cannot be resolved without the source. You will need to reconstruct the job from original specification documents.

T42 & ray.wurlod, thanks very much.

In our company, we will not include the job design to production system, that 's for security, someone can not change the job design in production and compile them.

But this time, some many developer have revised the job, so that we can not tell which is the existing production version, so we export the production executable to run our system test, but the problem occur.

I would like ask why this problem will occur ? Why it works well in production, but failed after export/import to a new project ?

I have performed some testing on this issue, it seems that it only occur when there is a transformer inside the job.

benny.lbs wrote:In our company, we will not include the job design to production system, that 's for security, someone can not change the job design in production and compile them.

This choice severely hampers your ability to support the production jobs and leads to situations like you have found yourself in.

Promote your jobs with Version Control. It's free and included on your Client software CDROM. You'll get the design time information and you can set the jobs to be Read Only so they cannot be touched. Do this for your 'test' environment was well and then the only place where changes can be made is in Development. And you've got change history and the ability to 'roll back' to any previous version as well.