DSXchange

I am noticing some interesting behavior as part of our Version Control usage. On promotion, we set the flags to compile objects and mark them read-only. If a dependent object is missing, it would seem that the job would not be able to compile and we would see that in the compilation report. Instead, however, it appears that the job is not compiled at all, and the compiled version from source project is promoted into the target project. Nice, but it causes confusion since we have something missing from the target and no notification of the fact without looking at the jobs manually. It is also confusing because I would not be comfortable assuming that the code that is running is the new code and not code associated with a previous version. I thought that maybe compiling the jobs would help identify this situation when it occurs, but we cannot recompile in DataStage (read-only), and CompileAll gives the same behavior - it compiles without argument even though the dependent object is missing.

Does anyone understand how this works? Is there a way to identify when items are promoted to a target project but are not in a usable state? Should I just relax and trust that the job that is running is the one I wanted to run, even though it has red in the derivation column when I inspect the job?

Thanks,

Stan

In version 7.x you have protected project functionality. This will get around some of the problems you are experiencing with individual compilation of jobs within the designer, in this approach you deliver all jobs as read write to the target environment, verify they are okay and then switch it to become a protected (read only) project.

As for your other problems, I always include dependant components whenever I initialise into the Version Control repository. If dependant routines are not runnable the job will still compile and you get an error when that job runs. I try and do a verification execution after a major release to production where I verify each job is working on a very small load volume.

Thanks for the response. Yes, in our process, include dependent components should always be checked as well, and it wasn't in this case. That's why I was surprised when I realized that we had made this mistake, yet the jobs ran fine anyway. Hence the reason for my confusion - whether it is a test job as you suggest, or a full-blown production run, the job will not error, so just running the job would not be a sufficient check. Basically you have to go through your entire testing script or test data set to ensure that the functionality you intended to promote matches what is actually running in the project. I would rather that the promotion process would keep you from having to do this kind of exhaustive check every time (like when you are just doing a minor release or bug fix).

Sounds like we have much more to look forward to in version 7. Some day . . .

Stan