Cost-efficiency – how?

The main idea behind the conversion tools is cost-efficiency. For each proposed conversion, we calculate a fixed price, based on various factors such as size and complexity of the conversion task. There is no need for anyone to learn how to customise and use the tools, as this is all handled by us. In brief terms, this is how it works:

The client (or the service company dealing on behalf of a client) provides us with the necessary information such as initial customisation criteria (based on one or more questionnaires), and input data to the conversion (for ACF2, a logonid listing and DECOMPed rulesets; for Top Secret, a TSSCFILE listing, plus other material). We set up and run the conversion process and deliver the result in the form of RACF commands. These commands are then used by the customer to build an initial RACF database for testing. After evaluation, the result is fed back to us, we tweak the tool to make any corrections or to meet any further requirements, and the conversion process is repeated. This iteration is performed a number of times, depending on the size and complexity of the conversion, until the desired output is produced. Optionally, the customised version of the tool is then shipped to the client for further iterations of the process locally, but experience tells us that this is normally not required.

The important aspect of this approach is that the client doesn't have to get acquainted with the tool and get bogged down with details that are of no importance once the conversion is completed. Thus valuable local manpower resources is saved and can be used to address other important tasks related to the conversion. One should remember that the physical conversion of an ACF2 or Top Secret database normally constitutes a relatively small portion of the total efforts required to migrate to RACF.

It should also be noted that we don't get involved in the migration of sensitive information such as passwords, but we can provide tools to handle such tasks locally.

Hopefully this has shown that the tools as such cannot be purchased. One of the reasons for this is that local requirements sometimes force us to produce solutions in the form of 'exits' to handle very specific situations. Even source code changes may be needed from time to time. It would not be cost-efficient for someone not familiar with the internal structure of the tools to undertake such modifications (especially as the tools are written in assembler). The tools have been designed to be as generic as possible, and are controlled by a large number of parameters, which provide efficient means for controlling the output. However, the tools are not static, but keep evolving over time based on experiences gained from each conversion (in fact, all conversions are unique). Such evolvement would be impossible to achieve if the tools were sold and modified outside of our control.

We can also mention that there are several service companies around the globe that use a conversion process based on our conversion tools. It's a proven process.