DSXchange

Hmmm... doesn't sound like it thinks 'dsadm' is your 'Administration' user any more. Unfortunately, I don't recall where/how it stores that information. Hopefully someone does. In the meantime, in case it makes a difference - what flavor of UNIX you got?

You also face the problem of having posted in the wrong forum. This is for discussion of possible FAQ topics, not help with problems. Please repost your problem in the appropriate forum - which looks like it should be the Enterprise Edition forum if this is a PX job.

Depends on your definition of 'month'. Typically, you either add a number of days to the date or break it up into component pieces and bump the month (and perhaps year and day) individually. Both Ray and Ken have routines to do this available for download, from what I recall.

No, seeing as you haven't really given us much to go on. How, exactly, do these file values get read and passed as parameters to your jobs?

Yah, already said I was afraid that would be the case.

chulett wrote:For documentation there is an XML PACK pdf file in your 'Docs' directory. And an XML Best Practices writeup on Kim Duke's website.

There ya go.

Shotgun.

I've used "blat" in the past (UNIX, not Windows) and didn't have any issues with it. Some nice features there.

Yes, you do.

You include them as "name value pairs", one set per parameter to be passed:


Assuming we're talking about dsjob here.

Just the number and column names themselves are needed:


Assuming CHANGE_DATE is actually a datatype of DATE, otherwise you'll need to add a StringToDate() function into the mix.

Yes, that's the function and it happens to be the first one documented in Appendix B of the Parallel Job Developer's Guide. Pass it a date and a # of days offset.

Hmmm... perhaps opening a case with your official support provider is in order, if all of the usual tricks to stop the quote stripping no longer work in this new version. How similar are your various queries? Worst case, can you break things up into separate parameters, something like... Select to_c...

Odd. Still suggest you take this to a SysAdmin and see if they can track down what crontab these are actually in.

Unless... any chance something else is running them, some other enterprise scheduling tool like Control-M or Tivoli?

That means there is nothing scheduled for that user. However, if the jobs are actually still running from cron, that means some user has them in their schedule, just not this one. You may need to get some help from the SysAdmins on that box for this, but you need to "query" all of the crontabs out t...