DSXchange

Can anyone plz let me know if there is a checklist to make sure that:
1. DS-server and PX-server works
2. all the environment is in GOOD working condition
3. We are using DS, PX, QS, MS...so is there a way to make sure that they can interact with each other without a problem

Eg: To make sure Px is workiing fine..we can put a job in PX which reads a DB/file and write to a .DS file
=> PX server is installed fine and it can read from DB

Any help to get this check list will be of great help.

PS: SHORTEST WAY TO DETERMINE THAT THE ENVIRONMENT IS SETUP WELL FOR THE TOOLS MENTIONED ABOVE.
I GUESS LONGWAY IS TO TRY WITH SOME JOBS WHICH WILL TEST ALL THE ABOVE.

vdr123 wrote:SHORTEST WAY TO DETERMINE THAT THE ENVIRONMENT IS SETUP WELL FOR THE TOOLS MENTIONED ABOVE.
I GUESS LONGWAY IS TO TRY WITH SOME JOBS WHICH WILL TEST ALL THE ABOVE.

This is my opinion:

The ideal way to ensure that your environment is set up properly and interact well with your UNIX environment is to run a set of test beds that will exercise all type of typical stages you would use during normal development. I chose the word typical, because I do not believe it is entirely necessary to test EVERY single stage.

In addition, for PX environment, you would test all of your buildops and custom stages. You also will need to test all of your configuration files (APT_CONFIG_FILE tests).

For the Server environment, sufficiently testing your BASIC routines are also necessary to ensure that upgrading/migration does not produce surprises either.

Exercising the Client software is also necessary -- do things a normal developer and tester would do. You should also exercise your QA/UAT/Production process (dependent on the goal of this server). We use a number of third party tools, and self-developed tools for our processes. All needs to be tested at least once.

Most important of the entire process is to record AND archive your tests. Evaluate the tests you have done after the fact, and after watching everyone else use it. Does your tests capture all of the surprises? Are there redundant tests?

Never, ever release a production box without ensuring that the same setup are evaluated under Development, QA, and UAT general use.

I have my own methods that would work specifically for Tru64, and the list of test cases grow every time I help set up a new server, especially after getting some surprises along the way.

We have experienced differences between 6.0r3 and 6.0.1; Tru64 5.1a PK #4 and #5; and I even caught a couple minor bugs with 6.0.2 through this testing process.

Doing this as completely as we can would minimize paranoid management from sabotaging our efforts to provide a viable solution using DataStage (and other tools).

-T.J.

I believe that there are some sample 'osh' scripts that come with PX. You could run them to make sure that the PX server is set up correctly. Also, always test a simple buildop with PX to make sure that your C compiler is compatible with your PX env.

-BP

Thank You for your feedback...
Presently I am putting some doc together to make sure the ENV is set GOOD for the Dev/Test/Prod machines.

There are test utilities supplied with UNIX-based ODBC drivers, that you might want to ensure are included in your checklist.
Don't forget to share the results of your deliberations!

Ray, Can you please elaborate on the what kind of UNIX based scripts are you talking about?

Thank You Vincent for your feedback...