DSXchange

Yes, at least according to IBM. The version 7 installation must, however, be an -itag installation using a non-default memory key.

All the differences are described by comparing the pertinent two Chapters in the Parallel Job Developer's Guide. There are too many to try to reproduce here.

What did you discrn from consulting either Help or the Parallel Job Developers Guide manual? Please post your specific questions here after undertaking that research.

You misinterpreted what I suggested. These SDK routines can equally be called from a Routine activity. Try it.

An additional job somewhere in the sequence can look after updating your audit table, once the actual job has finished.

Just as easy to subtract 1 from MONTH.FIRST.

Your "fact table" can be the file NUL (which will eat, and discard, all the rows you append to it). However, be really, really certain that what you say is true. Factless dimensions are extremely rare things, and suggest that something has been overlooked in the design phase - what are they dimensio...

Surely clients make a connection only to the head node?

In a server job they are one and the same. In a parallel job they are not.

Usage Analysis does not pick up job control routines, nor does it pick up routines invoked by other routines unless their Dependencies tab has had the dependent routines inserted in its grid. Nor - I believe without checking - does Usage Analysis reveal routines that are invoked by Transforms. (I mi...

basu.ds wrote:sorry ray ,
i want to know previous month lastdate.
thanks

Look at a calendar.

Not on this forum, which is for suggesting topics for the FAQ forum. Please post your question on the appropriate forum - the one for server jobs or the one for parallel jobs or the one for TX jobs, whichever it may be.

To find that out, you'll have to wait until next time U logs in.

In the interim, a Search would probably prove productive.

MONTH.LAST Transform

The easiest way is to invoke either of the SDK key management routines from a Routine activity in the job sequence you are using to control the job, and to pass the result to the job as a job parameter value.

Ordinarily, in the case of a hang, I'd suggest looking at server name resolution, but the fact that telnet is OK pre-empts that suggestion. Can you try leaving one of the hung connection attempts for, say, at least ten minutes to see whether a timeout error occurs? That may contain a useful diagnost...