DSXchange

Just to confirm:

The DataStage Operations Console was a new, great feature added in version 8.7.

Starting in version 9.1 it is referred to as the DataStage and QualityStage Operations Console.

Ray, I had the same idea on the "uv -admin -info" command. I checked and found it gives the install date and time but not the last engine start time. Another way is available as well, and tells you so much more, at a glance! Log into the DataStage Operations Console . The home page display...

Contact Support.

Or you can upgrade to 9.x or higher and use the built in ereplace function.

That may work. Just keep in mind the LOB settings in Connector stages. Sometimes you have to name or choose which columns are the LOB columns. It means having separate jobs unless you can parameterize that setting too (haven't tried it).

Are you using the ODBC Connector stage or the old ODBC stage?

Have you thought about gathering an angry mob to get your tnsnames.ora file updated?

Is your stage running sequentially or in parallel? If in parallel, on how many nodes?

It sounds like Oracle is causing the problem. Try calling Oracle Support.

My bad. There is also a job report that actually includes column details. From Designer, go to the File menu and Generate a Report. There is a dsdesign.exe command line option for generating a job report as well, which you can run from the Client tier. It is documented in the Designer Client Guide.

Keep the generic job as is. Create a separate job for the table with the LOB column(s).

Put the umask command into a job in that after-job routine as a shell command, then run the job and look in the job log to see what the umask output reports.

Yes, that should "fix" the fixed-length. If not, please post any new and different errors.

The dsjob command has a -report option. You may want to try it using the DETAIL report type.

Just as a side note too, the current release is 11.3.1, which has "umpteen" fixes included, as well as some new features, that you may want to consider instead of beginning with an older release.

The cleanest and easiest way would be to enter your custom admin ID, whatever you choose to name it, into the installation program when prompted. It sounds like you accepted the default "dsadm" user instead? If so, you may be making more work for yourself that the installer could have done...

The best way to avoid it is to run DataStage on UNIX.

Seriously though, I do not know.