CHECK LIST TO MAKE SURE DS SERVER /PX SERVER & env WORKS

vdr123 · Post by **vdr123** » Sat Jan 10, 2004 11:32 pm

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.

Teej · Post by **Teej** » Sun Jan 11, 2004 11:06 am

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.

bigpoppa · Post by **bigpoppa** » Mon Jan 12, 2004 1:44 pm

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

vdr123 · Post by **vdr123** » Mon Jan 12, 2004 2:34 pm

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.

ray.wurlod · Post by **ray.wurlod** » Mon Jan 12, 2004 9:15 pm

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!

vdr123 · Post by **vdr123** » Tue Jan 13, 2004 10:36 am

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

vdr123 · Post by **vdr123** » Tue Jan 13, 2004 5:30 pm

Thank You Vincent for your feedback...

DSXchange