DSXchange

There is a Migration Assistant tool that, among other things, looks after merging modified DSParams files.

Look at the entire error message. Which stage is throwing it?

Welcome aboard.

A search of DSXchange would have revealed that this behaviour is usually the result of insufficient memory being available on the client machine. Try closing a few windows/applications, re-open Designer and try again.

In general no. I believe the Sort stage may use a multi-threaded approach.

The easiest question to ask is whether Solaris is running on SPARC or x86 chipset.

Another way is to look at the first four bytes of a hashed file with a hex viewer such as od.

Once you get to version 8, such tools are directly available in DataStage.

I am not aware of any such command. And does it make any sense to provision components that you're never going to use?

Two alternatives, off the top of my head.

1. Just do nothing. There are no data types in server jobs anyway.

2. Add zero to it (or perform any other arithmetic operation such as multiplying or dividing by 1). That will also remove leading and trailing non-significant zeroes.

If you have a mysql client on your DataStage server, you can execute a mysql command as a before-job subroutine (or from an Execute Command activity in a sequence) that specifies the remote mysql database using command line options, and issue a TRUNCATE statement through that means.

Waiting to hear about byte-order before advising on transferring files. The repository files are export/import, as earlier advised.

That could be an infinite loop. Please re-think the logic, or at least assure us that there will always be a reference date less than any date on the stream input, as a "catch all" case.

That IS the answer.

And Q retired when they stopped making James Bond movies.

Just ignore it. You will get a VarChar of the correct length.

You have to do a lot more than that. Mainframe jobs use an almost totally different set of stages than parallel jobs. You are going to need to analyze what each mainframe job does and implement that logic afresh using parallel jobs.

What chipset is being used in the Solaris machine. If it's x86, you'll have byte order issues. In any case, the recommended method is to export projects from the old system, create projects on the new system and import into those newly-created projects. Cut-and-paste is definitely NOT the correct way.