DSXchange

This happened in Ds7.1 as well. I thought it was fixed.

Your first line needs to point to the shell you are using like :



Try that. There was a bug in HP-UX that Craig and others reported on this forum.

Your LOCATE statement is wrong. You are trying to locate "SURR.CNTL.":TableName in the last element in FilesOpened. First of all that is not how locate works. Second in the For ... Next before that is where you should look for this value. if "SURR.CNTL.":TableName = CurrentFileName then Po...

I agree you have a problem converting 10,000 jobs but I doubt if Informatica is going to out last DataStage. Also automating a conversion from DataStage to some other product would be difficult. I think DataStage excels in transformation. Even automating a conversion from server to PX would be diffi...

I agree but what if DTS all of a sudden was robust and as easy to use as DataStage, Maybe the next release of DS was not as easy to use or only as easy to use as PX is now. What if Oracle developed a product as easy to use and robust and included it with the price of Oracle. Maybe it could only talk...

I think all of these are excellent questions. I also think Ascential has a good answer for all of them at least as good as any player in the marketplace now. I think IBM would benefit the most from owning DataStage but they had the chance and let them go. It would take an IBM or Oracle or someone of...

I doubt if anyone can afford Ascential at over a billion. The return on investment is not there. Eventually Oracle and Microsoft will have good alternatives. Unless something drastic happens then 5 years is easy to see a good future. They have locked in SAP and PeopleSoft which makes for a very good...

Craig

The easiest way is to reformat the data to have the columns to be sorted to the first of the line. You need to format everything to sort in string or alpha order so right justify numbers. Dates should be YMD[4,2,2].

You fix the columns back after reading them after sorting them.

I have seen factless facts used mostly to report on all salesmen regardless if they have sales or some simliar concept. This way you can see the salesman has no sales for a given time period and the reports will reflect that. Otherwise the salesman does not show up at all on the report.

The key to the target table is JobName and TIMESTAMP. I do row counts this way.

I would skip multiple instance jobs unless you know the InvocationId. InvocationId is stored in field 7 of the log. Your SQL will change too.

I still do not get why people are doing all this in a routine. Write a job. Start with a UV stage. Output to a sequential file or a target table. I prefer the later. Here is the SQL for the UV stage. select EVAL "'#JobName#'" AS JOB_NAME, TIMESTAMP, SEVERITY, FULL.TEXT from RT_LOG#JobNo# w...

In field 40 the root record of DS_JOBOBJECTS hash file is stored whether or not it is a sequence job. It has a 2 in this field if it is a sequence. Field 31 is a list of dependent jobs or routines used by this sequence. Field 32 has a 0 if it is a job. In BASIC: read JobRec from DsJobs, JobName then...

Ray is correct to get it out of this file is not a good idea especially if the job has multiple instances. Just download EtlStats.zip. Much easier.

The UNIX command is tr -d '|'. You could also use Perl or sed. The tr is designed to translate one character to another. The -d option will delete these characters.

This is the second routine. It is a lot more complicated. If you save your metadata in Designer then it stores it in DS_METADATA. We were having an issue were one source column was wider than the target. The job gave a metadata mismatch warning. This routine will help debug this situation by compari...