This one is new to me. We upgraded DS from 6.0 to 7.5.2 on Windows 2000 Server SP4, running all Server jobs. Before the upgrade, all jobs ran fine in 6.0. However, after installing 7.5.2, I'm now having an issue with one job. The source is UniData (Infolease) and the target is Oracle. This job does a select criteria on 20 million rows in a UniData file and grabs around 3 million or so. It appears that when the select is finished and ready to read the rows into DataStage, these error messages appear in the Director log:
ds_udtopen() Unable to execute file SELECT - 81002 - Connection is down
DSD.UDTOpen GCI $DS.UDTOpen error 24
Again, we have over a hundred other Unidata-source jobs and they ran fine after the upgrade. Another factor is that this job takes over an hour to do the select. I have the timeout set to 86000 seconds in Administrator. Thanks in advance.
81002 - Connection is down (UniData)
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Sounds very much like a timeout at the UniData end. Are the columns involved in the WHERE clause indexed? If they were, then maybe your SELECT would finish fast enough not to time out. Just a thought.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Anything is possible. It may be that you are now dealing with larger volumes of data than previously, and that the version of DataStage is not a factor. Or it may be. Can you execute the query "natively" in UniData without any problem?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.