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
                    |orphanSubobjects
                    |setIncrementalTransactionID 
          logDir=log-file-disk-path
          [progress=true|false]
          [instances=number-of-progress-instances-output]
          [workers=number-of-worker-processes-available] 
          [incremental=true|false]
          [setIncrementalTransactionID=transaction-id]

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, orphanSubobjects, setIncrementalTransactionID, or repair operations.

The operation can be one of:

certify

Logically certifies instances of all user classes when the _logcert.in input file is not present
certifyMeta

Logically certifies instances of RootSchema classes when the _logcert.in input file is not present
repair

Runs the repair of detected errors

It is not advisable to perform repair operations to meta data in multiuser mode.
orphanSubobjects

Checks for orphan subobjects in user data files
setIncrementalTransactionID

Manually sets the transaction ID that the JADE Logical Certifier uses during an incremental certify operation

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 HugeStringArray. The handling of strings in this HugeStringArray 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. The way in which these entries are handled is determined by your application.

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 and certifyMeta operations 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 certifyMeta 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 full certify operation (that is, all schemas and all classes), you can specify the optional incremental parameter, which defaults to true if an incremental certify has been performed previously; otherwise it defaults to false. In addition, you can specify the optional setIncrementalTransactionID parameter if you want to manually set the transaction ID that the Logical Certifier uses during an incremental certify to determine if an inverse has been changed and needs to be checked. (For details, see "Manually Determining the Incremental Transaction ID".)

To set the incremental transaction ID value, run:

jadclient path=database-path
          ini=c:\jade\system\jade.ini
          schema=RootSchema
          app=JadeLogicalCertifierNonGui
          server=SingleUser
          startAppParameters
          operation=setIncrementalTransactionID
          setIncrementalTransactionID=transaction-id
          logDir=log-file-path

When you have run this to set the transaction ID, you then run the application again, specifying the certify operation to perform a full certify (that is, all schemas and all classes). The incremental parameter will default to true, because a transaction ID has been set.

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.