Hello

You can indeed create a job on one Operating System, then deploy it and execute it on a different OS.

To achieve this task, simply follow the steps below:

   1. Export a job on current Operating System.
   2. Import the job onto the other Operating System.
   3. Make some change if you need and run it.

However, if the job contains input/output components, the input/output paths should be changed to match the different Operating System.

Let's say, you want to migrate a job from Windows XP to Linux.
We advise you to use the context parameter to store the output path so that you can easily change the path once the job is imported to the other OS.

For example, add a variable myfileoutput1 with default value: F:/tmp/myfileoutput1.txt when working on Windows XP. Perform the export/import tasks to deploy your job onto Linuw. When you have deployed the job, change the default context parameter value of myfileoutput1to:  /usr/tmp/myfileoutput1.txt  as you are now on Linux.


Best regards

         shong

I routinely develop my jobs in Windows and roll them out to AIX.

Two things:  as Shong mentions, you should use context variables for all file names and database connect information.  Then, to change a job to run in a different environment and/or server all you need do is change the context variables.

For file paths, etc. I've found that you can use the Linux/AIX/UNIX notations under Windows as well.  So, all my paths are defined with forward slashes as opposed to backslashes. That way they run fine under any environment - Windows or Linux/AIX/Unix.


As for physical deployment on the AIX boxes, I just FTP the generated files over to the AIX boxes and write a short little ksh wrapper file to run them.  The wrapper just does things like check the result code of the job and reroute any console output to a file.