DSXchange

Take a look at your UVCONFIG file, particularly the values for UVTEMP

I think the documentation goes into far better detail than I can do here. DataStage allows you to be able to create your own stages and add them to normal jobs. Thus, if you felt a need to write a complex stage that does something that cannot be easily done in a transform or stage you could write yo...

SDK's are for something different. Start your job from the command line using dsjob and the appropriate parameters.

In both server and px jobs your job design would have two independant streams kicked off. If you've found that one gets executed before another it could only be by milliseconds (on a fast machine); for all intents and purposes the OraStage1 and OraStage2 will get started in parallel. In an EE job yo...

The dsjob command line utility on Windows and UNIX will allow you to start (stop,monitor) DataStage jobs.

Hello John, quite often you will see re-indexing as a possible fix to some of the problems you have mentioned. When DataStage accesses records in hashed files it will automatically utilize indices as criteria when selecting records and if those indices are corrupt then the record will not be found a...

Hello Divs, a quick look at the types of posts in this forum will show that there are many helpful people around who will help on specific problems, questions or issues. This forum is a great place for information exchange between people who do work with the product. This forum is used as a suppleme...

hehe - I just made the same mistake, this is a PX job so OCONV/ICONV won't work.

I didn't answer the first time around since a quick search here or a search in the Parallel Job Developer's Guide would have given the answer. Use the StringToDate function.

Remove my post - I wasn't paying attention to the PX/Server forum flag. The code would be quite similar in C++ should you wish to put in your own code.

In that case I wouldn't worry about the length of your parameter as you are using DataStage (server) strings which are limited by your available user virtual memory (if malloc() can allocate space, it can be added to the string)

I think you should limit it to the maximum length that your implementation allows for command line length, as that will effectively limit what length strings can be passed using the dsjob command.

DB/2 has a given amount of space tablespace wide for these transactions, so the number of rows is less important than the size of that data in each row.

How about approaching your problem one issue at a time. Start with the DB error(s) and see if you still have your job problem. You still haven't shown us an actual error that is locking or stopping the database, just that swap space is full (which isn't a DB/2 issue but a UNIX issue).

Can you see the possible link between your commit size in the job and the error? If you change your commit frequency down to 50,000 does the error go away (or happen at another point)?

If you use the DataStage FTP stage and filter your unzip command into your sequential file stage you do not need to write any scripts.