Welcome aboard! :D
Start by defining precisely what you mean by "performance", the metrics you use to measure it, what values you got, what values you expected (and why you expected them).
Inspect the generated COBOL. It's not too bad, and in my experience reasonably efficient.
Have you isolated the "performance" issue to DataStage, eliminating something (everything) in Teradata as the cause?
Problems of perfomance with DataStage MVS 7.5.1
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54595
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
ray.wurlod
- Participant
- Posts: 54595
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Lookups are intended to be made against database (DB2) tables. In this case, the table is opened once and a cursor established based on the query - in non-mainframe environments this is called "prepared SQL".
DataStage then passes the search key value and receives a row in return.
I believe the problem arises from your design in using a sequential file as the source for a "get row by key" lookup. (Though I am surprised that the file is opened and closed afresh for each row processed. If you can verify this, please report it via your support provider - it's a hopelessly inefficient implementation.)
DataStage then passes the search key value and receives a row in return.
I believe the problem arises from your design in using a sequential file as the source for a "get row by key" lookup. (Though I am surprised that the file is opened and closed afresh for each row processed. If you can verify this, please report it via your support provider - it's a hopelessly inefficient implementation.)
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.