Datastage system help gives the following error desription: SYS.HELP. 081021 MESSAGE.. dsrpc: Error writing to Pipe.

The problem appears when a job sequence is used and it contains many stages (usually more than 10) and very often when a network connection is slow. Basically the cause of a problem is a failure between DataStage client and the server communication. The solution to the issue is: Do not log in to Datastage Designer using 'Omit' option on a login screen. Type in explicitly username and password and a job should compile successfully. execute the DS.REINDEX ALL command from the Datastage shell - if the above does not help 2.20. How to check Datastage internal error descriptions To check the description of a number go to the datastage shell (from administrator or telnet to the server machine) and invoke the following command: SELECT * FROM SYS.MESSAGE WHERE @ID='081021'; - where in that case the number 081021 is an error number The command will produce a brief error description which probably will not be helpful in resolving an issue but can be a good starting point for further analysis. 2.21. Error timeout waiting for mutex The error message usually looks like follows: ... ds_ipcgetnext() - timeout waiting for mutex There may be several reasons for the error and thus solutions to get rid of it. The error usually appears when using Link Collector, Link Partitioner and Interprocess (IPC) stages. It may also appear when doing a lookup with the use of a hash file or if a job is very complex, with the use of many transformers. There are a few things to consider to work around the problem: - increase the buffer size (up to to 1024K) and theTimeout value in the Job properties (on the Performance tab). - ensure that the key columns in active stages or hashed files are composed of allowed characters get rid of nulls and try to avoid language specific chars which may cause the problem. - try to simplify the job as much as possible (especially if its very complex).

Consider splitting it into two or three smaller jobs, review fetches and lookups and try to optimize them (especially have a look at the SQL statements). 2.22. ERROR 30107 Subroutine failed to complete successfully Error message: Error calling subroutine: DSR_RECORD (Action=2); or *DataStage*DSR_SELECT (Action=7); check DataStage is set up correctly in project Development (Subroutine failed to complete successfully(30107))

Datastage system help gives the following error desription: SYS.HELP. 930107 MESSAGE.. DataStage/SQL: Illegal placement of parameter markers The problem appears when a project is moved from one project to another (for example when deploying a project from a development environment to production). The solution to the issue is: Rebuild the repository index by executing the DS.REINDEX ALL command from the Datastage shell 2.23. Datastage Designer hangs when editing job activity properties The appears when running Datastage Designer under Windows XP after installing patches or the Service Pack 2 for Windows. After opening a job sequence and navigating to the job activity properties window the application freezes and the only way to close it is from the Windows Task Manager. The solution of the problem is very simple. Just Download and install the XP SP2 patch for the Datastage client. It can be found on the IBM client support site (need to log in): https://www.ascential.com/eservice/public/welcome.do Go to the software updates section and select an appropriate patch from the Recommended DataStage patches section. Sometimes users face problems when trying to log in (for example when the license doesnt cover the IBM Active Support), then it may be necessary to contact the IBM support which can be reached at WDISupport@us.ibm.com Oracle PL/SQL versus a commercial ETL tool When implementing a data warehousing environment in a company, a question needs to be asked: whether to use already owned tools and technologies or buy a new, commercial ETL product. Having in mind the fact, that most big companies use an Oracle database, the question becomes: use PL/SQL to do the processing or buy an ETL tool?. Before making a decision on that, the managers need to compare pros and cons of buying a commercial ETL solution. Strengths and weaknesses of using Oracle PL/SQL as an ETL tool: costs PL/SQL comes along with the standard Oracle licence and if an oracle database is installed, PL/SQL can be used straight away with no additional costs. No additional hardware is needed. However, implementing ETL process in PL/SQL is a lot more time and human resources consuming process. It applies both to the implementation phase and later production support and enhancements. The designers need an in-depth knowledge about oracle and it may take months to become an expert in PL/SQL. The ETL tool like D atastage or Informatica can be learned during a few days training and in fact the designers dont need to know much about programming, scripting and can do their job without a low-level IT knowledge. From the other hand, a Datastage or Informatica expert m ay be far more expensive and less accessible than a PL/SQL consultant. workload and time its a factor directly related to costs. An ETL tool comes with the whole framework to simplify the design of the process which is usually an administration panel, GUI frontend, global options, documentation module, day -to-day operation management, failover capabilities, logging and reporting module, user management, connectors to different data sources, plugins, etc. In PL/SQL most of that modules must be pr ogrammed manually and it may significantly increase the time of implementation.

flexibility an ETL tools comes along with the set of mostly used components and it is rather difficult to expand its capabilities. For example, when we need to extract data to a non-typical format (for example EDI files, EPIC files) or process them in a non standard way, then PL/SQL should be a lot more helpful. efficiency if the company uses Oracle databases, then the ETL processing using the native database language which is PL/SQL will be a lot more efficient. There is no better way to process data than well optimized queries issued on the database internal engine and apart from that very often an ETL tools operates on different server than the database which causes the need to transfer the data across network. integration - The commercial ETL tools provide functionality to integrate with different systems, including connections to multiple data sources, operating systems integration, FTP support, plugins to ERP systems, etc. PL/SQL doesn't have that features and it has to be implemented externally. The conclusion is that there is no easy answer to the question which approach is better. The most important thing is to review the companys needs, calculate costs, estimate results and then make a choice between buying an ETL tool or using a PL/SQL processing.