Section 1 - Commands

Command Reference

idl(1)

Name

idl—Compiles the Object Management Group (OMG) Interface Definition Language (IDL) file and generates the files required for the interface.

Synopsis

idl [-i] [-D identifier[=value]] [-I pathname][-h] [-P] [-T]
idl-filename... [ icf-filename...]

Description

Given the provided idl-filename() file(s) and optional icf-filename() file(s), the idl command generates the following files:

idl-filename_c.cpp

Client stub (includes embedded user-defined data type functions).

idl-filename_c.h

Class definitions for interfaces.

idl-filename_s.cpp

Server skeleton containing an implementation of the POA_skeleton classes.

idl-filename_s.h

POA_skeleton class definitions.

idl-filename_i.cpp

Example version of the implementation. This file is generated only when the -i option is given.

idl-filename_i.h

Class definition of an example implementation that inherits from the POA_skeleton class. This file is generated only when the -i option is given.

Note: If any ICF files are specified, the information within the ICF files is used to provide the code generator with information about the interface/implementations that override the defaults. Typically, an activation policy and a transaction policy for an implementation may be specified in the ICF file. If no ICF files are specified, default policies are in effect for all of the interfaces specified in the OMG IDL file, and skeleton code for all of the interfaces is generated. If an icf-filename is provided as input to the idl command, only the implementation/interfaces specified in the icf-filename are generated as part of the server.

The IDL compiler places the generated client stub information in the filename_c.cpp and filename_c.h files. The generated server skeleton information is placed in the filename_s.cpp and filename_s.h files.

The IDL compiler overwrites the generated client stub files (filename_c.cpp and filename_c.h), and the generated server skeleton files (filename_s.cpp and filename_s.h). Any previous versions are destroyed.

When using the -i option, the IDL compiler overwrites the sample implementation class definition file (filename_i.h). Previous versions are destroyed. The sample implementation file (filename_i.cpp) is overwritten, however, any code contained within the code preservation blocks is preserved and restored in the newly generated file. To avoid the loss of data, it is recommended that you copy the sample implementation files (filename_i.h and filename_i.cpp) to a safe location before regenerating these files.

If an unknown option is passed to this command, the offending option and a usage message is displayed to the user, and the compile is not performed.

Parameter

idl filename

The name of one or more files that contain OMG IDL statements.

Options

-D identifier[=definition]

Performs the same function as the #define C++ preprocessor directive; that is, the -D option defines a token string or a macro to be substituted for every occurrence of a given identifier in the definition file. If a definition is not specified, the identifier is defined as 1. Multiple -D options can be specified. White space between the -D option and the name is optional.

-I pathname

Specifies directories within which to search for include files, in addition to any directories specified with the #include OMG IDL preprocessor directive. Multiple directories can be specified by using multiple -I options.

There are two types of #include OMG IDL preprocessor directives: system (for example, <a.idl>) and user (for example, "a.idl"). The path for system #include directories is the system include directory and any directories specified with the -I option. The path for user #include directives is the location of the file containing the #include directive, followed by the path specified for the system #include directive.

By default, the text in files included with an #include directive is not included in the client and server code that is generated.

-i

Results in idl-filename_i.cpp files being generated. These files contain example templates for the implementations that implement the interfaces specified in the OMG IDL file.

Note: When using the idl command -i option to update your implementation files, proceed as follows to update your implementation files:

Back up your implementation files.

If you are migrating from BEA ObjectBroker to BEA Tuxedo, edit your generated implementation files to change the code preservation block delimiters from "OBB_PRESERVE_BEGIN" and "OBB_PRESERVE_END" to "M3_PRESERVE_BEGIN" and "M3_PRESERVE_END".

If you added include files to your method implementation file (*_i.cpp), edit the file and move the includes inside the INCLUDES preservation block.

Regenerate your edited implementation files (using the idl command with the -i option).

If you previously made modifications to the implementation definition file (*_i.h), edit the newly generated definition file and add your modifications back in. Be sure to put your modifications inside the code preservation blocks so subsequent updates will automatically retain them. Pay particular attention to the implementation constructor and destructor functions; the function signatures changed in BEA Tuxedo release 7.1.

If you previously made modifications outside the preservation blocks of the method implementation file (*_i.cpp) or to the implementation constructor and destructor functions, edit the newly generated file and add those modifications. Be sure to put the modifications inside a preservation block so subsequent updates will automatically retain them.

-P

Generates server code that uses the POA instead of the TP Framework. With this option specified, the skeleton class does not inherit from the TP Framework Tobj_ServantBase class, but instead inherits directly from the PortableServer::ServantBase class. By default, the skeleton class uses the TP Framework. So you must use this switch when you are developing joint client/servers as these servers do not use the TP framework.

Not having the Tobj_ServantBase class in the inheritance tree for a servant means that the servant does not have activate_object and deactivate_object methods. In CORBA servers these methods are called by the TP Framework to dynamically initialize and save a servant's state before invoking a method on the servant. For CORBA joint client/servers, user-written code must explicitly create a servant and initialize a servant's state; therefore, the Tobj_ServantBase operations are not needed. When using the -P option, ICF files are not used because the TP Framework is not available.

-T

Generates tie-based servant code that allows the use of delegation to tie an instance of a C++ implementation class to the servant. This option allows classes that are not related to skeletons by inheritance to implement CORBA object operations. This option is set to off by default.

-h or -?

Provides help that explains the usage of the idl command. No other action results.

Examples

idl emp.idl idl emp.idl emp.icf