Job compilation

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
elavenil
Premium Member
Premium Member
Posts: 467
Joined: Thu Jan 31, 2002 10:20 pm
Location: Singapore

Job compilation

Post by elavenil »

Hi DS Gurus,

We are in the process of experimenting an automated solution to deploy code from one environment to another. And the below is what we are trying to achieve.

Source env ---> RTC ---> Middle Env --> Target Env

1. Code is developed in Source env and compiled in the source env.
2. Only source code is pushed into RTC.
3. Souce code is extracted from RTC and pushed this into Middle env.
4. Jobs are compiled in Middle env.
5. They get deployed into Target Env.

on the above scenario, Source Env and Target Env are running on AIX OS, while Middle env is running on Windows.

Expertise advice is needed on the below.

1. When job is compiled in AIX and deployed into Windows, what are the possible issues while executing the job?

2. When different configuration file is used other than configuration file used while compiling job? What are the other differences other than no of processes created for each job?

3. A job, which has transformer stage in it, will work in AIX when the same job is compiled in Windows env?

4. What are the other considerations to be taken care?

Appreciate it if you could provide expertise inputs on the above questions.

Thanks
Elavenil
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

AIX is big-endian, Windows is little-endian. While DataStage jobs are portable, that refers to the source code, not the object code. DataStage server jobs going to a same-endian target "ought" to run without issues, and PX jobs using only stages that do not generate runtime libraries (the transform stage does generate runtime libraries) will port between platforms.

Your proposed solution will not work, since the platform you are compiling your jobs on is different to that of the target.
elavenil
Premium Member
Premium Member
Posts: 467
Joined: Thu Jan 31, 2002 10:20 pm
Location: Singapore

Post by elavenil »

Hi ArndW,

Thanks for your response.

When job is getting executed in the target, it refers object code rather than source code in our case and it is due to no compiler installed in the target.

That is the reason one of the questions that i asked the below question.

When job is compiled in AIX and deployed into Windows, what are the possible issues while executing the job?

But it is reverse case, which is when the job is compiled in Windows and deployed into AIX, what are the possible issues while executing the job in the target environment?

Thanks & Regards
Elavenil
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

While there are exceptions, the rule is simple:

Jobs compiled on Windows won't run on AIX.
Jobs compiled on AIX won't run on Windows.

As stated earlier, the basic machine architectures are different, look up "big-endian" and "little-endian" on google for details. Secondly, actual linked object code is seldom portable across operating system (I can think of portability across different LINUX implementation, but even that isn't guaranteed).

You will need to compile your jobs on the same OS, preferably the exact same release, as you intend to run it. Thus in your example you will need at least one installation on AIX with a valid compiler.
kduke
Charter Member
Charter Member
Posts: 5227
Joined: Thu May 29, 2003 9:47 am
Location: Dallas, TX
Contact:

Post by kduke »

I have scripts which will export jobs from one environment. One job at a time. All you need to do is edit a file and create a list of jobs. It would then import to next environment and compile the jobs. It would log each job into a SQL Server database.

We used it to migrate jobs from DEV to TEST or TEST to PROD. He had a lot of developers in this company. We had a team of admins to migrate jobs. They would send us a list of jobs to migrate. They would also document from to environments and projects. The projects were all the same names but we could easily make it from one project to a different one. You could easily add check in and out to source code control.

All these scripts were based on the ones I give away to back up nightly.
Mamu Kim
Post Reply