ADASTRIP Customer Reviews

"My company is implementing a data warehouse. The project requires over 25 ADABAS file extracts in fixed format to be delivered in a relatively short time. We also need to minimize the additional CPU usage that will be involved in this effort. We have been told that Adastrip is the best way to go. It is fast and uses very little CPU compared to a Natural program.

Is anyone using Adastrip by Treehouse? If so, could you give me your overall opinion on this tool?What type of learning curve is involved? Is it short or long ? We have a 3090, how long will it take to install?How would you rate their support?

Adastrip has the capability of reading several sources; ADABAS directly, backup, or plogs. Which method would you recommend?"

Answers that quickly followed on the list:

"I have used ADASTRIP for several years. At my current sight I was the driving force that brought it in so I am definitely a fan of the product. It is flexible in that you can do checks against multiple fields and extract only specific fields thus reducing your output dramatically.

As for using PLOG's for extracting from, this is only used when stripping from online saves. You can not strip from just the plogs themselves. This functionality is from Plue (sp?).

As for not using much CPU, you must put that comment into perspective. We use ADASTRIP here to make report extract files. The strips can easily us 34% of our 3 way processor. The bad part is that it can drive your machine to 100% real fast, but at the same time it will accomplish tasks much faster than any other tool I have seen.

When running ADASTRIP against a live database, you must be aware that any updates currently in the buffer will be bypassed. ADASTRIP reads the container datasets directly and has no method of obtaining info from the buffer pool. As long as this is acceptable you are fine.

As for the install and learning curve, it is a breeze. The install takes all of 5 minutes, unload a load lib and put together some JCL and you are set. The JCL has a parm that is created for you CPU. When I brought this into this site last year it was rapidly adopted by our support team as a quick easy method to sweep the database for test data or while investigating problems."

"At my current site, we use ADASTRIP in a Production Environment for our large Monthly Batch Runs. My overall opinion is such: This is an excellent tool for quickly stripping ADABAS Data as long as you do not use too much Selection Logic. The analysis that ADASTRIP is fast and uses very little CPU is correct as long as there are not a lot of Rules being implemented in the Selection Criteria. I performed some analysis of CPU Time used and found that the CPU Time grew exponentially the more Rules that were used. Also complexity of the Rules affected the CPU time as well. At the time, 3-4 years ago, we found that there was indeed a point of diminishing returns; a point where the CPU Time used was actually less with a NATURAL Program."

> What type of learning curve is involved? Is it short or long ?

I would rate the learning curve as short to medium. The syntax to learn is very minimal. However, there are a few quirks to the output and the syntax that need to be thoroughly understood to be comfortable with the tool. For example, when specifying fields to be extracted, the order you specify the fields does not matter, as ADASTRIP will return the data in the order the Fields are specified in the DDM definition; EXCEPT that within a PE, the order DOES matter. This, along with some other things (Normalization, substrings, etc.) can make for a longer learning curve, but your average joe
programmer should be able to pick it up quickly. Getting started with the basics can be picked up very quickly. One indication should be that the manual for ADASTRIP is very small. Brief, concise and to the point. No ring-around-the-rosies."

>How would you rate their support?

"Have not had need for support yet. Maybe that says something in itself."

>Adastrip has the capability of reading several sources; ADABAS
>directly, backup, or plogs. Which method would you recommend?

Quite frankly, I haven't seen an outstanding reason to go with any one method. But I have found some negatives with both the direct access and the backup access. With Direct Access, you need to either wait out the next buffer flush, or make sure that you manually committ one yourself. There have been times when we have updated the database and run ADASTRIP immediately after and NOT gotten the Update in the extract File. After waiting about 2-3 minutes, then it would show up. This can catch you off guard sometimes, but if you are aware of it, it is usually not a problem. We have also run into problems when using an Online Backup for access. It seemed that ADASTRIP could not always handle the dynamic capabilities of an Online Backup. We would sometimes lose entire blocks of data during the ADASTRIP and this would cause us problems. Our solution was to drop the database, take an Offline Backup, then re-up the Database and continue. Again, this was 2-3 years ago, but the process still runs this way today. Not sure if it is still a problem in ADASTRIP or not, but we continue to process this way."

"We use ADASTRIP, and we like it very much. It is very fast - it takes about 40 minutes to read a 20-million-record ADABAS file (900-byte LRECL), select and write about one-tenth of the records out to a DSN. (I can't remember how long a NATURAL pgm took, but I think I gave up and canceled the job after four hours....)

The learning curve isn't too bad. The basic syntax is for the "input" = cards is:

//STPARM DD *
ASFILE FILE 151 /* 151: A physical ADABAS file number
ASFILE LIMIT 50000 /* Limit to 50,000 the total recs written to DSN
ASFILE FIELD AA FC HC /* Fields to return; use the 2-byte names
ASFILE TEST A HC(1-4).EQ.C'MISC' /* Test that bytes 1-4 of field HC is "MISC"
ASFILE TEST B FC(1-2).NE.C'09' /* Test that bytes 1-2 of field FC is not "09"
ASFILE RULE A+B /* Only select recs that return TRUE for
/* Test A and Test B

Each RULE card functions as a logical OR, i.e., if any of the RULE cards are TRUE, the record will be selected for writing to the DSN.

I would earn against trying to do too-complicated selection criteria; the way ADASTRIP processes PE/MU values in TEST/RULE criteria is (to me, anyway) confusing. If the selection criteria involves PEs/MUs, we use ADASTRIP to do the basic slection, then process the resulting DSN through a NATURAL program to do the more-complicated record culling.

One thing about felds being retrieved: They are returned in 2-byte-field name order; e.g., if you ask for ields DF DA AC EF, they will be returned in AC DA DF EF order - just something to remember when setting up LDAs to be used later to read the data.

Don't know how long it takes to install, or what the support is like - I've never had any problems with it, so I've never had to call tech support.

There is some sort of "delay factor" ADASTRIP "finding" ADABAS records; e.g., if we change a record so that it no longer meets the ADASRIP criteria, it may still get selected. Our standard caveat here is, if updating ADABAS, don't run ADASTRIP for 15 minutes if you want to be sure to get all records correctly. (When we use it for pulling test data, this =
isn't a problem. We turn off online file access for our nightly production batch jobs, an we control the job-networking and file access very carefull there."

>"One thing about fields being retrieved: They are returned in 2-byte-field
>name order; e.g., if you ask for fields DF DA AC EF, they will be returned
>in AC DA DF EF order - just something to remember when setting up LDAs to be
>used later to read the data."

"The order of the fields can be controlled by using the Normalize statement. This will cause the order of the fields to be identical to the order you list them. The caveat to this is the effects of MU's and PE's If you don't use normalize you will have a variable length record with each occurrence of the MU/PE listed beside each other. If you normalize the data you will get a fixed length record and all the none MU/PE fields will be repeated multiple times, one for each occurrence. This is actually easier to work with."

"The order in which fields are returned by ADASTRIP is, I believe, based on the sequence in the FDT. One of the philosophies of ADASTRIP is optimum performance, so CPU is not wasted on cosmetics such as user-defined field sequencing. As most sites have ADABAS field names starting from AA, AB etc, the sequence may seem to be alphabetic."

"I've installed several versions of ADASTRIP for the state of Washington over the past 3+ years. Installation is pretty simple. I had it installed and tested within 30 minutes of getting the tape on my desk. I have several customers who use it daily in their production worlds and have received nary a complaint about the product. A couple questions, but no complaints. As a system programmer, it's probably my favorite product, because I can just install it and forget it. I've had to apply one fix for it in the past 3 years, plus 4 new versions of the product itself (they were all maintenance upgrades if I'm not mistaken).

I've never had problems with their support, other than the fact that since we're on the west coast, sometimes if a problem crops up after 3 PM, we have to wait until the following day for support, since they close at 3:00 PM (PDT). They do have an after-hours answering service for urgent problems, but I can not vouch for how effective it is, as I've never had to use it (that speaks well for ADASTRIP, I guess).

I have numerous customers who use ADASTRIP, and I believe that they all use ADASTRIP against backups almost exclusively. I'd say that'd be the safest route anyway. I don't know that it would be the best option in every shop though.

Learning curve is probably fairly simple, as long as you keep the selection criteria simple. The way ADASTRIP processes PE/MU values has always given me headaches. I'm sure others could probably help you better than I in that realm, I just haven't had the time to thoroughly try it out.

In general, I'd say that ADASTRIP is an effective, easy-to-use product, with relatively few, if any, problems, with the software itself, and installation is nearly idiot-proof (I installed it several times, so it can't be too hard!)."

"I would like to itterate others' positive comments regarding ADASTRIP. I have used the product for many years, and yes, believe it or not, it is an Australian invention!!

Note that the speed of ADASTRIP is even greater when applied directly against an ADABAS database, rather than an ADASAV backup. This is because there is no need to read through tapes to locate the required file(s). ADASTRIP does not use the ADABAS nucleus, but directly reads the ASSO and DATA blocks. Coupled with its buffering techniques , the speed and efficiency is outstanding.

If you are, however, after a static copy of your data to ensure integrity of the data passed to the warehouse, then using a backup as the data source is most appropriate."