DataStage Server migration from Linux to Windows Server

[gxhpainter]

Hi,

We are planning to migrate DataStage Server migrate from Red Hat Linux to Windows Server.

I have couple of questions in this regard.

1. Did anybody had any issues after migration from Linux to Windows?
2. When we move the existing code from DataStage linux Server to DataStage Window server, did any one had any issues?
3. Anyone recommend any good reason for not doing the move from Linux DataStage Server to Windows based DataStage server?

Thanks,
Chakradhar.

[vmcburney]

1. Did anybody had any issues after migration from Linux to Windows?

You mean other than Windows providing worse parallel processing performance, worse memory management, more security flaws and more expensive license and support costs?

2. When we move the existing code from DataStage linux Server to DataStage Window server, did any one had any issues?

A lot of your file paths may be wrong. Hope you have set them up as job parameters that can easily be changed. You will need to regression test all jobs to see if you have the RAM and diskspace to run under full load and may need to tweak some settings.

3. Anyone recommend any good reason for not doing the move from Linux DataStage Server to Windows based DataStage server?

If it's not broken why change? You will face an installation window of at least 3 days, if it goes okay first time you should have the software installed in under 3 days, if anything goes wrong you could be dealing with support calls for up to 30 days.

[gxhpainter]

thanks for the thoughts..

Infact, we have AS400 applications in production, we need to trigger DS jobs from AS400 and communication link between AS400 ( iSeries) and Linux server is a challenge.

So we have decided that moving Windows is a solution.

Rgds,
Chakradhar.

[asorrell]

Hah! I'm at a client where we are moving the other way, from Windows to Red Hat Linux. So far these have been our problems (you'll have them as well):

1) Pathnames - slashes get reversed
2) Flat Files - end-of-line character changes (ie: CR-LF). This may or may not affect certain jobs depending on how the files get created. Can be overcome via properties on the flat file stage.
3) Execution of O/S commands (cp to COPY, etc.) must be re-written or redesigned.
4) Some command line executions at shell may require removal of the double back-slashes if they are present (convert \\ to \). This is because the backslash is an "quote" character in UNIX that means use the following single character literally. So two backslashes ends up with only one at execution time ("\\" translates to "insert following char, which is a backslash, literally). This won't happen in Windows, producing two slashes where you want one. This will also need to happen for other characters that are submitted to the command line (change \" to ") that have used a backslash literal.
5) File system mounts may require global pathname changes (ie: C:\x\y instead of //system/x/y.
6) Custom routines and transforms must be moved.

If you really know what you are doing (Note: THIS IS DANGEROUS IF YOU AREN'T CAREFUL) you can dump all the jobs to a dsx file and use a good editor with macro capabilities (I highly recommend UltraEdit) to make mass changes to pathnames. We were able to make numerous changes very quickly this way.

Please note that this is about as risky as making changes to your Windows registry via regedit. If you mess this up nobody (including IBM) will help you recover - so don't make any changes to your original DSX file (edit a copy). That way if all else fails you can reload the original DSX and go back to the way things were.