Windows XP as DataStage Server
Moderators: chulett, rschirm, roy
Windows XP as DataStage Server
I am trying to work with DataStage Server Edition on my laptop which has Windows XP as the operating system. It seems to have installed correctly, but I am seeing strange things when I am trying to run jobs.
I went on IBM's sight and it says that XP is not supported as the server platform for DataStage.
Does XP work as a server? Are there any known issues, patches, etc. to 7.5.1.A to handle the issues?
I went on IBM's sight and it says that XP is not supported as the server platform for DataStage.
Does XP work as a server? Are there any known issues, patches, etc. to 7.5.1.A to handle the issues?
When I run a simple job:
Source---> IPC ---> Transformer ---> IPC ---> Target
There are no rows being read from the source, yet the row count after the IPC rises very quickly into hundreds of thousands of rows. When I finally abort the job, the job log shows the read SQL statement and the has hundreds of thousands of entries like:
J_Stage_PS_S_F0006_E1..IPC_in.IDENT3: %s.
At the end of the job log is an entry:
J_Stage_PS_S_F0006_E1..IPC_in.source_in: ds_ipcput() - timeout waiting for mutex
I have verified all of the parameter values being passed in, including the user and password for the read. The IPC stage has a timeout of 120 and a buffer size of 512. The source table has 534 rows in it.
This simple job, exactly as is, has always run successfully on my Windows 2000 server and at all customer installations.
Source---> IPC ---> Transformer ---> IPC ---> Target
There are no rows being read from the source, yet the row count after the IPC rises very quickly into hundreds of thousands of rows. When I finally abort the job, the job log shows the read SQL statement and the has hundreds of thousands of entries like:
J_Stage_PS_S_F0006_E1..IPC_in.IDENT3: %s.
At the end of the job log is an entry:
J_Stage_PS_S_F0006_E1..IPC_in.source_in: ds_ipcput() - timeout waiting for mutex
I have verified all of the parameter values being passed in, including the user and password for the read. The IPC stage has a timeout of 120 and a buffer size of 512. The source table has 534 rows in it.
This simple job, exactly as is, has always run successfully on my Windows 2000 server and at all customer installations.
-
- Charter Member
- Posts: 822
- Joined: Sat Sep 17, 2005 5:25 pm
- Location: USA
Hi Paule,
I tried search engine and found this:
viewtopic.php?t=98246&highlight=jstagep ... cin+ident3
Thanks
Sam
I tried search engine and found this:
viewtopic.php?t=98246&highlight=jstagep ... cin+ident3
Thanks
Sam
Paule,
Increase the timeout session period in the IPC stage. But before that, the design that youve shown, that doesn not require an IPC stage. As in, there is no advantage of an IPC stage over there then may i ask why are you sticking in an IPC stage before and after the transformer, or there is more to the design?
Increase the timeout session period in the IPC stage. But before that, the design that youve shown, that doesn not require an IPC stage. As in, there is no advantage of an IPC stage over there then may i ask why are you sticking in an IPC stage before and after the transformer, or there is more to the design?
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
I increased the timeout on the IPC to 240 and it still acted the same way. A note here is that when I start the job, it immediately starts the record count after the IPC - there is no delay or waiting.
As far as why use an IPC - these are jobs (hundreds) that are shipped with the product and Development's methodology was to use IPC stages on all jobs to attempt to achieve a minor level of performance improvement. If the only solution to this issue is to remove the IPC stage from all jobs, I will be working on this for the next month or two.
Again, these jobs run perfectly on a Windows 2000 server and Unix boxes.
As far as why use an IPC - these are jobs (hundreds) that are shipped with the product and Development's methodology was to use IPC stages on all jobs to attempt to achieve a minor level of performance improvement. If the only solution to this issue is to remove the IPC stage from all jobs, I will be working on this for the next month or two.
Again, these jobs run perfectly on a Windows 2000 server and Unix boxes.
Yeesh. Obviously, that's not the only solution. You could also not use WinXP as your Server platform. In spite of the fact that others may be using it 'without issues', one would think it is not an officially supported platform for a reason. And then there's the fact that, if you ever do need official technical support for some of these 'issues' you'll basically be out of luck.paule wrote:If the only solution to this issue is to remove the IPC stage from all jobs, I will be working on this for the next month or two.
Why not stick with one of the supported server platforms?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Further testing:
Replaced IPC stages with transformers and it still reacted the same way - record counts after the transformer and no record counts before it.
Copied the map, removed everything except a read from source directly to a hash table - worked fine, read all source rows, and wrote them successfully to the hash.
Added an IPC stage to the job and it failed with the same symptom - rows after the IPC and none from the source.
Replaced IPC stages with transformers and it still reacted the same way - record counts after the transformer and no record counts before it.
Copied the map, removed everything except a read from source directly to a hash table - worked fine, read all source rows, and wrote them successfully to the hash.
Added an IPC stage to the job and it failed with the same symptom - rows after the IPC and none from the source.
Regarding using a different platform - I am a consultant implementing the product and was issue a new laptop with XP.
I have downloaded gigs of software- other tools, etc., configured everything, and had hoped to not have to re-image it with Windows 2000. Plus, I have gotten used to a one minute reboot instead of the Windows 2000 drudgery.
I have downloaded gigs of software- other tools, etc., configured everything, and had hoped to not have to re-image it with Windows 2000. Plus, I have gotten used to a one minute reboot instead of the Windows 2000 drudgery.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
They are expecting you to implement it completely on a laptop?paule wrote:Regarding using a different platform - I am a consultant implementing the product and was issue a new laptop with XP.
If that's not the actual end target platform for this implementation, you sure you want to be spending 'the next month or two' ripping out delivered functionality?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This is a final follow-up to my original post. After extensive testing, I found that it is the DRS stage that is the issue with XP as the server platform.
The DRS stage was created to enable a flexible source and target configuration using an environment variable for the database type.
I did tests adding/removing the various types of stages and all worked on the XP server except when I used the DRS stage for either the source of the target connection.
Unfortunately, the many hundreds of maps that we use in our packaged Oracle/PeopleSoft/JDE EPM solution all use the DRS stage.
The DRS stage was created to enable a flexible source and target configuration using an environment variable for the database type.
I did tests adding/removing the various types of stages and all worked on the XP server except when I used the DRS stage for either the source of the target connection.
Unfortunately, the many hundreds of maps that we use in our packaged Oracle/PeopleSoft/JDE EPM solution all use the DRS stage.