Reverse Engineer

aya_r · Post by **aya_r** » Wed Jun 13, 2007 11:22 pm

I'm having a problem to find which mdb file that match what has been deployed in the unix server, so I'm thinking to run a reverse engineering from the server to regenerate the project.

Can any one please help me how can I start doing this or if there is any document or article I can read about this.

Your help is highly appreciated

ray.wurlod · Post by **ray.wurlod** » Thu Jun 14, 2007 12:58 am

The MDB file is not deployed to the UNIX server - there's no such thing as Access on UNIX.

The most relevant document to read is your licensing agreement, which expressly forbids reverse engineering.

Since deployments are not logged on the server you are pretty much restricted to checking each client in turn. Check the "project folders", particularly their date/time modified, to try to match what's on the server.

aya_r · Post by **aya_r** » Thu Jun 14, 2007 1:49 am

Thanks Ray for your reply, and sorry if my description wasn't clear enough..I didn't mean the mdb file was deployed in the server .. what I meant exactly is that I can't find the mdb file that got the repository which has the project that was deployed in unix server.
If I deploy and run the project that comes from the copy of mdb file that got, I don't get the same output that I get in when I run the project in Unix.

the job ran successfuly and produce an output file .. but the output is slightly diffrent than the output from the deployed jobs in the Unix server.

I hope this description is clearer .. do you still think the licensing agreement will expressly forbids reverse engineering??

ray.wurlod · Post by **ray.wurlod** » Thu Jun 14, 2007 5:37 am

I'm not a lawyer and therefore hesitate to comment on the licensing agreement.

Nor can I suggest any strategy for determining, from what's on the server, which QualityStage Designer deployed it, other than to check them one at a time.

ray.wurlod · Post by **ray.wurlod** » Tue Jun 19, 2007 2:21 pm

It's primarily a matter of understanding what gets deployed to the server. There's nothing hidden - everything is in the form of scripts, file dictionaries and rule set tables (text files all). There are six directories on the server, within the project directory itself. Inspect the contents of these as below to find out what actually got deployed.

Controls - rule set files (.CLS, .TBL, etc.) and files containing scripts to execute stages - you can readily figure out the naming convention - for example a file name ending in I is for an Investigate stage.

Data - your actual data files, or links to them.

Dic - the datafile dictionaries that you edited in Designer, now transferred unchanged to the server

Ipicfg - Configuration files for running the jobs - specify server, project, host name, ARD name, etc.

Logs - Nothing is transferred to here from Designer, but you can troubleshoot here so may be some aid in reverse engineering.

Scripts - generated scripts for setting environment variables (.env), running the jobs (.scr and .stp for steps), and for executing these (.bat or .sh, depending on server operating system) - the "vsh" comes from "Vality".

Temp - nothing is transferred here from Designer - it contains mainly binary versions of files found in text form elsewhere

ipi.env.sh is a script for setting up environment variables executed by every QualityStage job.

aya_r · Post by **aya_r** » Wed Jun 20, 2007 1:44 am

Hi Ray, Thanks for responding to my emails,
it's relief to know it's doable and I don't need to be an expert to do it.
Could you please post an example so I can try iy.

Thanks,

ray.wurlod · Post by **ray.wurlod** » Wed Jun 20, 2007 6:52 am

Imagine you have a Word investigation job called IAHNAME containing an Investigate stage also called IAHNAME.

In the Controls directory there will be a file called IAHNAMEI (the final I means it's an Investigate job) with overall properties - seplist, striplist, the field to be investigated, how the frequency is to be generated, the sample size, the rule set name. Also in this directory are the classification tables, dictionary files, etc. for the indicated rule set (and for any other rule sets used in the project).

In the Dic directory are the file definitions. In this case the source file is AUTOHOME, so there is AUTOHOME.dic as its file dictionary.

The stage processing for the IAHNAME stage is in the Scripts directory, as a file called IAHNAME.scr. It's in here that I determined that AUTOHOME was the file used as source for this stage.

IAHNAME.env is a script for setting any specific environment variables needed by the IAHNAME job, over and above those set in ipi_env.sh.

Also in the IAHNAME.stp script are variables set for the Start and End stages in the job run, plus commands for cleaning up old versions of log files. The job is actually run by run_app.sh (as you can see in IAHNAME.stp).

Finally, IAHNAME.sh (or IAHNAME.bat if you're on Windows) ties it all together.

For STAN, MATCH and SURVIVE jobs there may be one or two extra files in the Scripts directory - for example the frequency report from a STAN job is here because it can be used as input to MATCH. I leave you to explore these and ask specific questions.

The frequency and pattern report files that you view in QS Designer all are to be found in the Data directory. Your actual data files, or links to them, for file mode or batch mode operation are also stored in Data.

Don't worry about the files in the Temp directory, as these are not deployed from the client - they are mainly binary files created by QS server to perform its particular tasks. Sort of like compiled code.

Similarly the Logs directory contains log files produced by running jobs. The information in these may help you in your reverse engineering effort, but you will need to sift out a few nuggets of useful information from among a lot of "purely log" information.

aya_r · Post by **aya_r** » Sun Jul 01, 2007 11:57 pm

Hi Ray,
I had a close look to the scripts files that have been deployed in the production Unix server and compared them with the files that have been deployed from the Quality Stage designer on my PC .. and I found major diffrence in 2 of the control files for 2 STANDARDIZE stages ..

this is what's in the Unix server
------------------------------------------
RECORD 550
STANDARDIZE ${APPCLIB}/AUNAME (484 36)
OUTPUT (40 36) (76 18) (94 18) (264 1) (265 1) (313 4) (1 7)
INFILE ${OMDCC150}
OUTFILE ${OMDCC15S}

and this is what I got from deplyoing the project copy I got in QS
---------------------------------------------------------------------------
;;QualityStage v7.0
RECORD 550
CASE UPPERALL
STANDARDIZE ${APPCLIB}/AUNAME (484 36)
OUTPUT (1 7)
INFILE ${OMDCC150}
OUTFILE ${OMDCC15S}

as you can see there is a diffrence in the output, so I modified the stage to get the same control file when I deployed, after I modified it, deployed
and rerun the job I managed to get the same output I got in the server but to be honest I'm not 100% sure that what I did is correct, so I thought to describe to you what I did and it would be highly appreciated it if you condifrm to me if what I did is wrong or right!!!!

what I did when I modified the Stage is:

In the section of append field selection I added the six fields that I believe they were missing

Would you please advise me if modifying the stage in this way is correct or not!!

Thanks a lot
Ayah

ray.wurlod · Post by **ray.wurlod** » Mon Jul 02, 2007 8:54 am

Hopefully what you did worked. It appears to be correct; I've no way of knowing for sure! The pairs of numbers, you probably worked out, are the column locations in the record (start length).

Tip: check "Disable Smilies in this post" when posting anything with 8) in it - otherwise it's translated to the Cool smiley.

aya_r · Post by **aya_r** » Mon Jul 02, 2007 7:52 pm

Thanks Ray for your response. I believe what I did worked, as the output file from running the job on my PC match exactly the output file from running the job in the production server.

Thanks also for the tip .