Service Group Application Reference

10.1
- 10.5 HotFix 2
- 10.5 HotFix 1
- 10.5
- 10.2 HotFix 1
- 10.2
- 10.0 HotFix 1
- 10.0

Back Next

SSA-NAME3 Version Control

There are three aspects to version control in relation to using SSA-NAME3. These pertain to:

ensuring that, in any one system environment, the Algorithm used to build the keys is the same as the Algorithm used to build the search ranges;

the migration of SSA-NAME3 across system environments (e.g. development test production); installing a new SSA-NAME3 release.

Within One Environment

It is very important that the SSA-NAME3 Algorithm used by the application to build the keys on your database is the same version that is used to build the search key ranges for the search application accessing that database. If these become out of step, unpredictable search results may occur.

After an Algorithm is customized, it is generated into a Callable module called the ’Service Group’.

This will either be statically linked to your application(s) or dynamically invoked at run-time, or both for example, it may be statically linked to your key-building program and dynamically loaded by the on-line search program. Because the key-building and search applications are usually different entities, there is a potential for error.

Apart from implementing good procedures for managing this version control, it is a also recommended that each application which Calls SSA-NAME3 be designed to include a call to the SSA-NAME3

INFO

Service to obtain and print or display the Service Group Signature,

USGSIG

currently in use. Among other things, this contains the date/time of the last compilation or assembly of the Service Group. Then, if any doubt exists over the version in use by different programs, each program, in response to some run-time parameter, can dump the SSA-NAME3 Service Group signature and the signatures compared.

For more information on the INFO Service, see the

INFO

section.

Across Different Environments

The Callable Service Group: The minimum required by an application at run-time is for it to have access to the Callable SSANAME3 Service Group. Therefore, when migrating an application from one environment to another, this Callable Service Group must be migrated with it. If the Service Group is statically linked to the application, it will naturally migrate with it. If the Service Group is dynamically loaded, the Service Group module or library will need to be migrated separately.
As with the previous topic, care must be taken to ensure that if a Service Group has changed in a way that effects the SSA-NAME3 Name-keys, then both the application which builds the keys and the application which performs the searches must be migrated at the same time as the Service Group that they use.
The Definition Files: Because SSA-NAME3 can be customized and tuned by changing settings in its Definition files, and these changes may effect key design, it is important that when migrating an application from one system environment to another, that the Definition files used by that version of the application and Service Group are saved. This may mean migrating them to the same environment as the application, or creating a backup of them in the development environment.
The minimum which would need to be saved is:
For C Platforms (MS Windows, Unix, AS400, Tandem, etc.):
From the working directory on Windows where the customization work is carried out:
all
*.def
files
the name and/or address file(s) which were used to build the Frequency table(s), or, if this is not possible, the Frequency table source files (normally of the form
n3tb??.c
)
any modified Character-set tables (normally of the form
n3cs??.c
)
any modified Word Stabilization routines (normally of the form
n3st??.c
)
any modified Formatting routine exits (normally of the form
n3ft??.c
)
the Test-bed (a program called
testbed.exe
)
In most situations, the last three will not be present.
For 370/ASM Platforms (MVS, DOS/VSE):
the library containing the user modified definition files: eg. &SSA..&USER..MYUSA
the name and/or address file(s) which were used to build the Frequency table(s), or, if this is not possible, the Frequency table source files (normally in a library such as &SSA..&USER..SOURCE and of the form
n3tb
)
any modified Character-set table source (normally of the form
n3cs
)
any modified Word Stabilization routine source (normally of the form
n3st
)
any modified Formatting routine exit source (normally of the form
n3ft
)