DSXchange

Ambuj743 - that sounded like a statement, not a question. Also, you should define "special" characters.

I'm sorry if I don't quite understand. Your DataStage server is Windows and your remote system is UNIX. Your remote TELNET port should be the default of 23 on UNIX.

Is this right?

It looks like you have declared and called "countcheck" as a before/after subroutine. According to the docs, any non-zero return value is construed as a failed call and triggers an error. You will need to call this as a normal routine in order to work as you've designed the process flow.

Parvati - no, I can't do that, because there is no built-in routine name and no means of calling it in just one line, unless your UNIX has "crypt" and "decrypt" executables from the command line. You haven't mentioned how secure this needs to be. A very simple BASIC routine using a the builtin rando...

Hello Yogesh, and welcome to DSXchange! If you use the search facility, you will find many results for "39202", one or more of which might help you further. Did DS work before this error? What happened between the time it worked and the time it didn't? Do you get any errors when stopping and startin...

What OS does the remote system have - the one you are attempting to delete the file from? If unix, the command to execute would be "rm".

The issue is that the DSGetLinkInfo() call won't work from a PX transform, hence the BASIC transform stage. But since you are mapping this value to a column for each row, it is much faster and better to use @OUTROWNUM as Ray has suggested.

Kumar - I am staying out of this one. The poster has gotten several viable options presented to him/her so far.

Turn on tracing in FTP and see what the error message is from your after-ftp-command.

The DSDetach() call should solve the problem, it is just more efficient to not have to re-open a job handle. But I didn't suggest the route Ray did because I assumed it would be too complex in this case.

Are you installing the NLS version, and if so, which codesets? What is a "software dump" to install? I haven't heard that term before.

You should add DSDetachJob(JobHandle) to the end of both your internal subroutines to ensure clean closure.

In your example, how do you know that job J2 wasn't called?

John, I now understand the EventHorizon() routine a bit better. If I call it with the parameter DSJ.CloseToHorizon I get very slow performance due to the dilatory effect of time; when I use DSJ.AlmostAtHorizon I get sporadic errors due to decomposition of bits and bytes into bitlets and bytlets. And...

Can you post your call to DSGetLinkInfo() in your BASIC transform stage?

Byron - take away the trailing ";" semicolon.