Running a Non-GUI JADE Logical Certifier

To run the JADE Logical Certifier as a non-GUI application, specify the following arguments in the jadclient program.

jadclient path=database-path
          ini=c:\jade\system\jade.ini
          schema=RootSchema
          app=JadeLogicalCertifierNonGui
          server=SingleUser
          startAppParameters
          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 arguments 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 argument 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 startAppParameters argument 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 arguments that follow startAppParameters 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 argument controls whether certify progress messages are output to the progress output window. Specify this argument 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 argument. 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 argument. 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 argument 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 depends 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)

For a meta-certify operation, you can use the _metacert.in file to specify the RootSchema classes that are to be certified.

The format of the _metacert.in file is the same as that of the _logcert.in file except that the Schema and AllSchemas values are not valid, because the certification of meta data is performed at RootSchema level so you cannot filter the schema selection.

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.