I would be inclined to solve this using a hashed file together with a little known command called WITHIN, designed specifically for this kind of nested, or recursive, traversal.
ANYTHING that has changed. For example are you now running under a different user ID? Has the user's ulimit changed? What stage types are there in your job? What other tasks are happening at the same time? (These are just examples. You need to be the detective.)
There are several ways to have one job "internally call" another, such as before-job subroutine or job control routine. That said, I would advocate keeping the execution modular, and creating a job sequence to run the one then the other. It would then be the job sequence that you execute, rather tha...
Think of it as an alert, rather than as a warning. It also serves as a convenient mechanism to detect later that one or more rows rejected; without it you would need to determine the row count from that particular link. Design either way, depending on your particular style.
DataStage server edition is singularly well-equipped for this task, since data are processed within DataStage as character strings, exactly as they are in XML, and variable-length is a given. The actual approach taken would depend on how many levels of hierarchy are needed. Even so, an arbitrary num...
A parallel job usually has one configuration file. You parameterize this by including $APT_CONFIG_FILE as a job parameter. However, there is no easy mechanism for changing configuration files once the job is running. IBM reserve unto themselves the ability to install dynamic configuration files such...
Version 7.5.2 does not have an active client, so would not need its client to be shut down. But then you confuse me by referring to dsenv, which is a file on the server. What's really happening here? If both versions are running on the server, then your shutdown script ought to shut down both. And t...