DSXchange

Here's one from when I had the same problem. Hope it helps.

Are you the only one in yuour group having this issue? Sometimes something like that can be platform specific, so it might help to know what you are running the client software on. It could also mean that some of the dependant components have been stomped on by other software, so the first thing I'd...

So just go back and edit your first post, Arnd. You do know you can do that, right? This is not Usenet, ya know.

Well, then that typically means the port is in use from what I recall. Can you guess what advice is coming next? Search the forum. Look for posts on the same subject, specifically with the keyword 'debug' in it. Something about adding a 'd9' flag? That will cause the process to log the reason for it...

I think the answer to that would be pretty obvious - until you regenerate things, you are still using the 'old' values, default or not. It won't start using the changes that you've made until you do two things: regenerate and then stop/restart the server.

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. That would have been good informa...

I would like to obtain rationale why looking from hashed created use Use Account Name is much faster than use Directory Path option. Where did you get this little nugget? AFAIK, the only difference is the physical location of the hash (even though you could 'path' one into your project if you reall...

I've done things like this both ways over the years and haven't had problems with either methodology. Places without external / Enterprise schedulers require creative use of job control to run those 'x times a day' jobs. That or schedule it in via DataStage multiple times. Now, without Job Control o...

Sorry, didn't mean to confuse. During discussion of the problems of trying to get a routine to connect to Oracle, the use of an ODBC stage came up. And then an 'or' - or use an OCI stage. My only point was to encourage the use of a native stage, like an OCI stage, over the generic ODBC stage. Unless...

I don't know anything about this specific product, but your message sounds like a typical 'path' problem. Meaning, the path / library that the component it is looking for lives in is not in your PATH. If you can find siebelbc.dll and then add where it lives to your path, you may be fine. You may hav...

Ugh. Once you've solved your packaging problem, you may want to reconsider the whole 'release - package - move package - install package' cycle you are using now and consider simply using Version Control.

Be happy to go over that, talk pros and cons if you like. Packaging is so... 90s.

I'm afraid those are your two choices... either delete individual entries or do an entire VC 'mulligan' by dropping and rebuilding the project. The latter is not as bad as it sounds. If you are at a point where you can safely say that you "don't need" the various older versions of the jobs you have ...

ray.wurlod wrote:Or you can use an Oracle OCI stage, and thereby employ the OCI software directly.

What he said.

Don't use the ODBC stage unless you've really really got no other choice.

You may need to post the definition of the file you are receiving to make sure we are all on the same page. If your file truly has packed decimal fields and if they simply converted the entire record from EBCDIC to ASCII - then they have destroyed the packed fields in the process. Packed is packed, ...

Talk to your SA - find out if you are a ulimit victim and, if so, get them to up it (or make it unlimited) for you.