DSXchange

Anything you post in the Enhancement Requests forum is forwarded to IBM. However, nothing is promised.

If you validate the job this will bring the hashed file into existence. You may need temporarily to change the hashed file name in the stage that reads from it.

Or you can execute the CREATE.FILE or CREATE TABLE or mkdbfile command in a before-job or before-stage subroutine.

Not "can". "Must".

The clients do not run on UNIX. They must, however, be able to connect to the UNIX machine on which DataStage server is running via TCP/IP. By default port number 31538 is used, so this must not be firewalled.

This is a SQL Server process. You have to fix the problem in SQL Server. DataStage is simply informing you that the problem exists, and is preventing DataStage from doing its task.

There's an even better way. Run ACCOUNT.FILE.STATS ALL LOCAL in your project. This collects all sorts of file tuning statistics, but also records the device number and inode. So you can then construct a query such as: SELECT DISTINCT FILEINODE FMT '10R', FILENAME FMT '56T' FROM STAT.FILE ORDER BY 1;...

Wherever you like.

You then write your subroutine to collect it from there.

None of the messages seems to relate to the routine, but rather they appear to relate to unexpected tokens in the data. Remove the routine from the job and see if they persist. If so, fix that issue before reinstating the routine in the job.

Have you checked your multi-node configuration file?

How?
REGION changes value in different rows of the data set. Job parameter values can not be changed once the job is running.

We have two requirements.

1. Posters do not "hijack" threads. This is a different question (even though related) so warrants a separate thread.

2. "Urgent" has no meaning here, for reasons already posted ad nauseam.

Create a new job and/or add a new CFF stage. Until you change them properties are set to project default.

Thanks for that feedback. ODBC is supposedly a "standard" so, if ProfileStage can not use drivers that comply with the standard we have a bug. Have you reported this to your support provider and, if so, with what result?

plz help me out asap. I'd love to help you out. Which way did you come in? And asap is not the name by which I'm usually known! Scroll right in the Columns grid in a Sequential File stage, where you will encounter rules for handling missing columns and other abnormalities. Many DataStage processes ...

You already did.

Vertical pivot.

Search is your friend.

Did none of them have the wit to go back to the previous full backup? D'oh! Yes, I agree, UV_SCHEMA and UV.ACCOUNT are the worst to lose, closely followed by the VOC file of the UV account. Tales from the Trenches Step N in an installation or upgrade, after configuring tunables and connectivity, sho...