DSXchange

Welcome aboard! :D You really have not given us enough information to help. Please post the exact error message(s) from the log, or from the compilation phase if this is where it is occurring. It may even be that none of your Lookup stages is responsible; without seeing the actual error message(s) w...

We do unattended exports at a known time of day (21:00-21:10 approx). All of the developers know that, if they've left anything locked at this time, it doesn't get "backed up". Tough. The log file can tell them about it in the morning.

Because uvcs processes bypass UV.LOGIN afaik. Plus, you don't really want to have to get into the UV environment only to be kicked out; far better to prevent getting in at all. You could, of course, simply stop or pause the RPC daemon; it would have a similar effect, but prevent your using the Admin...

The original post did specify 13 digits - I also thought of this kind of encoding, but felt constrained by that original requirement. Experience teaches that you should avoid the letters I and O if you do go for this solution.

Of course you can copy them. But will they work? Probably not. What will be missing are "system table" entries on the second machine. The easiest way to get these in place is to do it properly; create the projects on the second machine using Administrator client. Then export from machine 1 and impor...

That admitted, I think what 1stpoint is seeking is something like Prime INFORMATION's MAXUSERS command, where an administrator can limit the maximum number of logins to a particular number, including zero. This was never implemented in UniVerse (for reasons never satisfactorily explained). Some UniV...

The maximum precision that DataStage can handle is configured using the EXACTNUMERIC tuneable. Its default value is 15; you can take it as high as 57. The largest four-byte signed integer is 2,147,483,647 (ten digits); this has nothing to do with DataStage and everything to do with the largest integ...

Generate a value into the 13 digit field.

Ignore the incoming 21-digit field, or store it in a non-key column in the target table if that's allowed for.

Require your customer to justify this illogical decision.

Let me rephrase your question. There is a field that can contain potentially 10^21 different values; you want to store these in a field that can contain a maximum of 10^13 distinct values. Unless there is other information about the original values that you have not revealed, then the answer is no.

Welcome aboard! :D You could have used the Administrator client to create the new project, then exported the old and imported into the new using the Manager client (Export/Import DataStage components). To connect the VC client to a changed project, the trick is to enter an invalid password, which op...

Usually that error stems from having an incorrectly specified Unicode map when running DataStage with NLS enabled.

Another possibility is that the SQL Server data type is NVARCHAR or NCHAR and you're feeding it a character that it can't map using Microsoft's idea of a Unicode map.

The commands themselves are in $DSHOME/bin.

There is very little documentation available.

For those that correspond with UniVerse utilities of the same name, some documentation is available from IBM's website

What you've asked for is not possible. The DataStage clients are true clients; everything you do is actually recorded and stored on the DataStage server to which the client tool is connected.

NLS_LANG is an environment variable.

I'm with Ken. Alternatively, re-educate your customer. Surrogate keys (assuming that's what you're doing) are SOLELY about uniqueness; it doesn't matter if there are gaps. At the very least have them justify their requirement. Be prepared to tell them that the requirement is nonsensical. Or stupid, ...