DSXchange

On Windows Server, the AT command is used to schedule jobs on the server. In the process of creating the command, any string parameter containing spaces gets passed with quotes (") around it. This does not happen when running a job manually.

For example, if the value of the parameter is when run manually, it gets passed as When run as a scheduled job the value is passed as Then, if the value is used in a SQL statement, those quotes get treated as part of the value.

Has anyone else run into this and come up with a way to resolve the parameter or strip off the quotes? Obviously some routine that would grab the parameter, check for and strip off the quotes before it gets to the database stage but I haven't come up with a way to intercept the parameter yet.

Microsoft knows far better than you do what your requirements are, and therefore you clearly need these quote characters.

(No, I don't know any way to strip them.)

Yeah, they do know best.
I actually understand the need for the quotes since AT is a command line program and so the quotes are required for it to treat it as a single value rather than breaking at the space. However, knowing that and that the quotes are put there by Director when the job is scheduled, then DataStage should filter them out when it runs the job. Based on that, I opened a case with IBM so we'll see what comes of it.

ray.wurlod wrote:Microsoft knows far better than you do what your requirements are, and therefore you clearly need these quote characters.

(No, I don't know any way to strip them.)

Pretty sure someone has already posted on this issue, but I don't recall if there was anything in the way of a resolution. Curious what IBM Support comes up with.

Finally reached a resolution with IBM. It seems this only occurs in 7.5 and prior. It is apparently fixed in 7.5.1 and beyond.

Now, as to why we are still running 7.5, that is a different story.

Finally reached a resolution with IBM. It seems this only occurs in 7.5 and prior. It is apparently fixed in 7.5.1 and beyond.

Now, as to why we are still running 7.5, that is a different story.