DSXchange

The Limit property is not a date. It is a number of days since the beginning of your chosen epoch. Try (for example) using an Epoch of 1990-01-01 and a Limit of 20000.

Continuing that theme, you could also parse it into the AdditionalName field.

Welcome aboard.

It may be easier to use an Execute Command activity to read the first line of the file (head -1 filename command), extract the date, and effect whatever comparison is needed in a trigger expression in that activity.

What error/warning messages appeared in the job log?

You have failed to import your UTLGetLinkCount routine, or you have not compiled this routine.

Usually by asking the DBA nicely.

The fact that you can't find it may itself be the problem. Was the job imported from somewhere else, where that routine does exist?

Add handling of this warning to the project-level default message handler in production. Or cause this to be done. "Make it so."

Identifiers such as project names and job names are case sensitive, even though you're on a Windows platform. Check that you have spelled and cased all identifiers correctly.

Try a search for the DS RPC error 80011.

Yes, the jobs will run OK even if logging to DSODB is not working (this is handled by agent processes). Whether or not you want to set up DSODB for failover is a decision only you can make based on your particular needs. If you do, set up a cluster in the same way you did for XMETA.

You need to incorporate logic to detect whether the job needs to be reset, and only reset it if that is the case.

Probably, if you can redirect the event info (whatever it is you mean by this) onto stdout as part of the SQL.

What else is different? For example, how is APT_STRING_PADCHAR set in each environment?

Report to us all the property settings in the Hashed File stage. Beware, too, that names are case sensitive.