DSXchange

They don't want to undeploy it, simply stop it.

You marked your post as 8.x so explaining how it all works in 7.x may not be all that helpful.

Can't speak to the 8.x side, but on earlier releases the dscmdexport exports an entire project whereas dsexport is for a single job.

In 7.x you would stop them from the 'RTI Console' client tool (the same tool you use to deploy them), no clue what the equivalent would be in the 8.x world, however.

Yes.

Define 'a while'. The (only somewhat) flippant answer is that yes indeed, the same things do take longer in 8.x than 7.x.

That's what -lognewest is there for.

Please verify if this is a problem just with parameter sets or if you have the issue with 'normal' job parameters as well.

The problem is the stage is metadata driven and is helpful pretty much only when you need to transfer a record at a time. For a 'normal' binary or ascii transfer, you're way better off using the normal command line ftp protocol... and sometimes you just have to.

Not sure what you mean... you can't reset a job after it aborts? Why not, what happens when you try?

I would wager that they can. I don't have Windows and thus no 'Command' stage but the Execute Command stage can with a small trick which I'm guessing would work in the Command stage as well.

Problem is you can't do the "RECFM=FB BLKSIZE=0 LRECL=2500" part or assign space via the stage, to the best of my knowledge.

Hmmm... so there's no jobs in the category, just connectors? Let me test that on 8.1 and see if it works there when I get a chance.

You should be checking the status before the run and then Resetting any aborted jobs, not recompiling them. Do this from a 'wrapper' script and schedule the script in Control-M.

Honestly, for that I would not use the stage and simply script your FTP transfer with all the goodies you need in the script.