DSXchange

I guess I am glad to know that it does take a long time, and I am not doing things in an antiquated way.

kduke wrote:I have seen it take days or weeks to do a historical rebuild.

Unfortunately as a full time employee its less of a billable time and more of a weekend slog it out :) I do see the point that if users change their requirements and expect historical data to reflect that, there is no other way out. It gets even more compelling for a complete reload when dealing wit...

Thanks Ray for those views. More often than not, users expect to fix historical data. It can be called a bug fix, as the requirements of the users at the beginning can be faulty and they realize that at a much later stage. This change in the requirement comes to the ETL team along with a request to ...

All, This is more a generic question about the best maintanence procedures, rather than a pure DataStage technical question. I have always been having a dillemma about how best to manage changes in a production environment. My question pertains to an ETL code that is in production loading data to a ...

But is there a command that I could use on a dos command line that would export the project to say Access instead of having to go to the manager and clicking on tools--> Reporting Assistant-->update You can export the report assistant output to a Acess/oracle/EXcel/Sql server/Universe. If you mean U...

Hello folks,
I was curious if there is a dos command line counter part to the Reporting Assistant tool in Manager.

Thanks.
Jay

folks, I have written a small batch script in dos, that invokes a datastage job and waits for it to complete. If it completes successfully, it FTPs some files to the Unix box and runs the same program again. If the program fails, the script stops. I am getting a Error 81002 waiting for job Status co...

You're doing something unsupported, using knowledge of the undocumented APIs. You have no control over what happens inside. There's no global solution, once inside that subroutine it can do anything it wants. Would you consider writing your own subroutine to clear the log? You're already doing thin...

Use all error trapping available on all commands. Failure to open a file should not allow processing to continue, letting a write to the file cause a failure. In fact, write failures can be trapped as well. Verify all of the DS BASIC functions/statements against the manual. There's only a handful o...

folks, I have a routine that would get aborted to certain write failures for some conditions. It works fine in all other values. This routine is used in a job taking arguments from a file. When there is a write failure for come conditions, the routine aborts and in turn aborts the job. When I run th...

Rather than counters you should use modular programing techniques. Nested subroutines and functions are essential parts of good programming practices. You could periodically call a function that checks a directory for the existence of a file. That file could be a STOP, PAUSE, ABORT, STATUS, etc set...

I am following the same approach of using counters to stop it. It just makes it lot more work to put the counters at the right places. if its a big routine with bunch of goto statements then at times some counters might not even get counted. I guess , putting as many counters as possible with an exi...

Is there a good way/good coding practice may be to stop a routine from running too long due to some kind of an infinite loop(I am using labels and goto statements a lot). I dont have unlock privileges, and I am locking my routine at times coz of infinite loop, at times coz the file is locked by anot...

Your approach does not offer any protection against the design-time objects from being deleted. These have no visibility at the operating system level, being primarily rows in the tables DS_JOBS and DS_JOBOBJECTS (plus DS_ROUTINES, DS_TRANSFORMS and so on). If, as you say, protecting the run-time t...

Sure. It's basically a 'switch' managed from the Administrator client. I was able to lock jobs from delete by changing the permissions on the internal files of the jobs. I tried this on some test jobs. Seems to work. As long as I use chmod -R 544 on the *220(220 my job num,which will include RT_LOG...