Registering a provider with the CIM server

When the provider dynamic load library has been made physically accessible to the CIM server, it needs to be registered via a special MOF file using the cimmof command. A provider registration MOF file contains instances of the CIM classes from the provider registration schema, namely of classes PG_ProviderModule, PG_Provider and PG_ProviderCapabilities as shown in Figure 17.

Figure 17. CIM classes from the provider registration schema

The instances of these classes contain all the information that the CIM server needs to know about a provider, for example its physical packaging structure, supported CIM classes and namespaces, as well as the set of supported provider operations.

Once the provider registration MOF file has been created with the instances of classes PG_Provider, PG_ProviderModule and PG_ProviderCapabilities, the content of this MOF file can be loaded into the CIM server’s root/PG_InterOp namespace using the cimmof command.

The cimmof command stores this information in the CIM server run-time repository.

Example:

cimmof -n root/PG_InterOp TestProviderRegistration.mof

The CIM server automatically migrates the repository from one z/OS version to the next. This means, that once the additional provider MOFs have been installed, there is no need to install them again after a z/OS release upgrade.

If the run-time repository including your definitions has been deleted and the CIM server master repository has to be restored, your CIM Schema extensions and provider registration are lost and you have to register them again.

Therefore these MOF files should be part of your delivery and stored in your hierarchical file system directory, such as for example:

/usr/lpp/myProd/schemas

stores the schema descriptions and registration information

MYPROD_ClassName.mof

contains the CIM Schema description

MYPROD_ClassNameRegistration.mof

contains the provider registration

More information:

• cimmof
• PG_Provider
• PG_ProviderModule
• PG_ProviderCapabilities