DSXchange

FIX can remove or create system table entries, depending on whether the schema (project) is specified by name or pathname.


Never use FIX straight away. Always run VERIFY.SQL without FIX first, so that it reports to you what it intends to do.

How? Please share solutions, so that others can find out by searching. Makes life easier for all of us.

If you change uvconfig but do not regenerate then smat -t will report the previous values. Whether they are default values or not is moot, and depends on whether an earlier regeneration ever took place.

Could be. For example are you using QualityStage, Real Time Integration and so on?

Roy, I think that the problem at Arun's site is the sheer size of the Version Control project directory - they have already once hit the UNIX limit of number of subdirectories (= dynamic hashed files) in a directory. That's why I believe he's trying to delete some. Earlier I had suggested converting...

You need to use the DataStage Package Installer. Details are here on the QualityStage forum.

You must use DataStage Package Installer (find it via the Start menu).

Specify the pathname of the folder that contains QualityStage.dsp (it's probably called I386) when asked for the package location.

The Code tab is disabled until you give your routine a name. It needs this name to build a FUNCTION declaration.

There's another piece you need to install on the client machine, the QualityStage plug-in GUI.

I don't have one right now, but am fairly sure that GUI is part of its name. Search for it on the CD.

There's another installation needed on the client machine, the QualityStage Plug-In GUI.

I don't have one with me right now; search for it on your CD. I'm pretty sure GUI is part of the name.

When DataStage starts, the tunable values are loaded into a shared memory segment. This is where smat -t gets its values from. This can be useful in determining whether the uvconfig file has been changed but not regenerated. Also useful to know is smat -t0 which suppresses the asterisk beside any no...

What you seek to do can be done, but only "under the covers" in the Version Control project (rather than from the Version Control client). You need to figure out exactly what it is you want to delete, then where it is stored (and where the versioning information associated with it is stored), and us...

Ah, yes, but is it the 1.1 version? Open the Stage Types branch in your Repository, open the properties of the OCI stage, and check. If it's the correct version, it may not have been registered correctly.

No limit imposed by DataStage. However your ulimit setting may impose a limit at the operating system level. Check with your UNIX System Administrator. You can find out what your limit is (for example by typing ulimit -a at an operating system command prompt), but superuser privilege is required to ...

You can do either, but I'd recommend creating a new entry so that the original remains intact. In any case, as with any "system" file, make sure you've got a backup copy before changing it, and document any changes you make (so that someone else doesn't reverse them later!). Or you can use an Oracle...