DSXchange

I have query on the executable job with Transformer inside.

Suppose I have a parallel job "Test" with Transformer inside. Then
(1) Compile it in Project A.
(2) Export executable job "Test" from Project A as A.dsx
(3) Import to Project B
(4) Job "Test" can be run successfully in Project B
(5) Export executable job "Test" from Project B as B.dsx
(6) Import to Project C
(7) Job "Test" was abort when running with following error message.

Transformer_1: Failed to load the library "V0S1_Test_Transformer_1.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 "V0S1_Test_Transformer_1": 0509-026 System error: Cannot run a file that does not have a valid format.
0509-022 Cannot load module /sysp/DataStage/Projects/TEST/RT_BP53.O/V0S1_Test_Transformer_1.o.
0509-103 The module has an invalid magic number..

(8) Compare between A.dsx and B.dsx. And found that there is difference.
A.dsx will have binary code inside, but B.dsx havn't.

A.dsx

BEGIN DSBPBINARY
Identifier "V0S1_Test_Transformer_1.o"
B1 "01DF000444B5AA8C0000FE4E000008DD00483002010B00010000666C0000110400000005FFFFFFFF"
B41 "1000012820000794200014E800000001000200020004000300050003524500000000000000000000"
.
.
.
.
.
.

END DSBPBINARY

B.dsx

BEGIN DSBPBINARY
Identifier "V0S1_Test_Transformer_1.o"
COMMENT Record is empty
END DSBPBINARY

Maybe that can explain why job abort in Project C.

However, what I want to know is why the DSX file was changed after first running ? Is there any procedure on exporting executable job to avoid this discrepancy ?

When you did the export from B you did not include job executables. The "error" is between the keyboard and the chair.

No, I did include the job executable when export from B.

ray.wurlod wrote:When you did the export from B you did not include job executables. The "error" is between the keyboard and the chair. ...

If you can be totally sure of that, then the job had not been compiled on B and there was no executable code. But you say that it ran successfully on B. There is an internal contradiction here.

Is there any reason you can't import the export from A into C, to see if that makes any difference ?

Ummmmmm, that is what did puzzle me. So, when release job executables to Production server, we need to create a new project, import the job design only and compiled in the new project, then export job executable for release.

This case just take you 5 minutes to simulate, if you have spare time.

ray.wurlod wrote:If you can be totally sure of that, then the job had not been compiled on B and there was no executable code. But you say that it ran successfully on B. There is an internal contradiction here.

I ...