To run the JADE Logical Certifier as a non-GUI application, specify the following parameters in the jadclient program.
jadclient path=database-path
ini=c:\jade\system\jade.ini
schema=RootSchema
app=JadeLogicalCertifierNonGui
server=SingleUser
endJade
operation=certify|certifyMeta|repair
logDir=log-file-disk-path
[progress=true|false]
[instances=number-of-progress-instances-output]
[workers=number-of-worker-processes-available]
Running the jadclient program with these parameters initiates a certification of all schemas in the database or the meta-structure of all schemas.
To avoid possible inconsistencies and contention with running applications, the JADE Logical Certifier tool must be run in single user mode when certifying user schemas. It can be run in multiuser mode to perform meta certify or repair operations.
It is not advisable to perform repair operations to meta data in multiuser mode.
The logDir parameter specifies the directory to which the log files are output (for example, logDir=c:\jade\system\diagnostics). An exception is raised if this directory does not exist or you do not specify a value. Output is appended to the _logcert.log file and the _repair.log file.
Path names must be valid and cannot contain spaces.
The jadclient program treats processing arguments enclosed in double ("") or single ('') quotation marks after the endJade parameter as single-string entries in the huge string array. The handling of strings in this huge string array is application-specific. For example, dir= "program files" is treated as a two-string entry and "dir= program files" is treated as a one-string entry. How these entries are handled is determined by your application.
The values of the operation and logDir parameters that follow endJade are case-sensitive; that is, certify, certifyMeta, or repair.
By default, a progress output window is displayed as the classes are analyzed and instances validated. The optional progress parameter controls whether certify progress messages are output to the progress output window. Specify this parameter with a value of false if you do not want certify progress messages output.
You can control the frequency of certify progress messages by specifying the number of instances in the optional instances parameter. By default, messages are output every 10,000 instances.
For the certify operation only, and only when no _logcert.in input file is used, you can control the number of worker processes available if you want all classes to be processed in parallel by specifying the optional workers parameter. By default, a single worker process is used. When you specify that more than one worker process can be used, the elapsed time to certify a system may be reduced. (This parameter is ignored if it is not a certify or meta certify operation, or a _logcert.in input file is used.)
The number of worker processes will depend on a multitude of different factors, including things such as available I/O bandwidth, CPU cores, the number of instances, and the number of inverses in each class. As a guide, the number of workers should not exceed the number of CPU cores minus one.
When performing a certify operation, you can create a _logcert.in input file in the output directory, adding lines in the following format to specify your logical certification filter criteria, as follows.
Individual classes to be certified, by specifying the following lines.
Schema <schema-name-1> Class <class-name-1> Class <class-name-2> : : Schema <schema-name-2> Class <class-name-3> Class <class-name-4> :
When you specify the Class command with the class-name parameter value, all instances of the specified class are checked (for example, Class Customer). You can filter the instances of the class specified in the class-name parameter by specifying the instance or instances that you want to check, as listed in the following table.
| Parameter | Checks… |
|---|---|
| Class class-name first-instance | Instances of the specified class whose instance id is the value of the first-instance parameter or higher (for example, Class Customer 23467) |
| Class class-name first-instance last-instance | Instances of the specified class whose instance id is between the specified values of the first-instance and last-instance parameters (for example, Class Customer 23467 33000) |
All classes in a specific schema, by specifying the following lines.
Schema <schema-name> AllClasses
All classes in all schemas, by specifying the following line.
AllSchemas
A specific class and all of its subclasses, by specifying the following line.
Subclasses <class-name>
Exclusion of a specific class, by specifying the following lines that apply only when you have specified the AllClasses or Subclasses line.
ExcludeClass <class-name-1> ExcludeClass <class-name-2> ExcludeClass <class-name-3> :
Exclusion of a specific class and all of its subclasses, by specifying the following lines that apply only when you have specified the AllClasses or Subclasses line.
ExcludeSubclasses <class-name-1> ExcludeSubclasses <class-name-2> ExcludeSubclasses <class-name-3> :
You can specify the following commands before any AllSchemas, Schema, AllClasses, Class, Subclasses, ExcludeClass, or ExcludeSubclasses command that applies to all classes that are certified.
| Command | Checks instances of classes that are created on or after the… |
|---|---|
| DateRange start-date | Start date specified in the start-date parameter (for example, DateRange 14/12/2007) |
| DateRange start-date end-date | Start date specified in the start-date parameter and on or before the end date specified in the end-date parameter (for example, DateRange 12-Dec-2007 14-Dec-2007) |
In this table, the instances checked are those created in the specified period; not those that are updated in that period.
Lines that start with two virgules, or forward slash separators (that is, //), are treated as comments and are ignored.
When you run the logical certifier, it creates the _logcert.cls file, listing classes that have errors. (This file has the same format as the .in file.) This enables you to check those classes after repairs have been made, by copying it to the _logcert.in file and then running the certification again.
If you want to certify all schemas, remember to delete any existing _logcert.in input file.