DSXchange

Any chance of telling us what results you did get?

The only conversion command on UNIX that I know of is "dd", which can perform ASCII to EBCDIC and vice-versa. If declare your source file as 8859 and output to UTF-8 and a "diff" command shows no difference then you have done something wrong at your settings since Datastage wil have done some conver...

If you just create a default lookup the way you would have frmo a server job, the lookup will be loaded into the DataStage job and be run from memory, you have to explicitly code a "sparse" lookup so that it does singleton queries the way server jobs used to.

Have you tried setting $APT_ORAUPSERT_COMMIT_ROW_INTERVAL to a value higher than your number of rows?

There are (almost) more variations of Julian type dates & times than there are character sets! You need to specify which ones you are using before anyone here can help you.

This type of problem usually occurs when there is a disjoint somewhere between the real data and the NLS mapping used. I would start simple, craete a text file and check with a hex editor that the characters are present as you expect, then read that from datastage with the correct NLS settings, but ...

You need to differentiate between the time required to select the data and the time required to transfer it to DataStage. I suspect your limiting factor is the transfer, not the database selection.

If you call up orchadmin with no options you will see a "describe" section and I think one of the options there is to disable the pretty-printing of numbers so that you get actual record counts.

I'm not at a place where I can check now, but there are a couple of lines of output in "orchadmin ll {dataset}" that will give you this information. Once you have the exact line, you can select a less comprehensive orchadmin describe option.

What is your source NLS data mapping declared as? What does 0x9e map to in that character set? What mapping are you creating as output?

I forgot to add those lines, thanks for reminding me, Craig. TestDate = ICONV(Ans,'D4YMD') Result = @STATUS BEGIN CASE CASE Result = 3 CALL DSLogWarn('Oh No, Mr. Bill! The computed date "':Ans:'" has been converted to "':OCONV(Ans,'D4/YMD'):'".,'MyProgram') CASE Result = 1 CALL DSLogWarn('The comput...

Yes, you need to call up the man pages for the compiler to find the appropriate compiler switch.

No, that probably won't work too well. One can "tweak" the version numbers in the exported .dsx file but any new functionality used at V8 will certainly cause the V7 import to hiccup, most likely fatally.

We have a big job that takes over 45 minutes to compile. The PC is a quad-core machine, the network is a fast gigabyte switched one and the server is a 8CPU AIX box. During the compile almost everything is 100% idle most of the time. We have a call open to support, but there is little chance of them...

Lets assume your date is in the format YYYYMMDD and is passed into your routine as "InDate" and your second parameter is "AddMonths" which is a value between -12 and 12. OutYear = InDate[1,4] OutMonth = InDate[5,2] OutDay = InDate[7,2] OutMonth += AddMonths IF (OutMonth>12) THEN OutYear += 1...