This command generates Legion stub files for CORBA input IDL files. Optional flags allow you to include information about the preprocessor and the back end and to specify whether or not trans code, client stubs, and head files should be created. If you run the command with no flags, Legion will generate client-side and server-side stubs. For example:

$ legion_generate_idl your_file_in.idl

On the other hand, the example below will generate client-side stubs, a trans file, and header files.

$ legion_generate_idl -trans -client_stubs -header \
your_file_in.idl

The following options are supported:

-A...

Provide an implementation-specific escape.

-D<name>

Define a name for the preprocessor.

-E

Run the input file on the preprocessor only, print results to stdout.

-Idir<directory name>

Specify a directory to included in the search path for the preprocessor.

-U<name>

Undefine a name for the preprocessor.

-v

Run the command in a verbose setting. This will show the compilation stages.

Compiles programs on a remote host. The command tars your current directory, copies it to a remote host, untars it, and executes a make command. The resulting compiled binaries can be registered with Legion via the directory's makefile or can be copied back to your current directory with one or more -OUT options. Be aware that legion_make will tar everything in and below your current directory, so be sure that you are in the correct directory before running it.

If no remote host or architecture is specified (with the -h or -A flags) the command will run on a random host. For example, the following command would build the tar file on a random Alpha Linux host:

$ legion_make -a alpha_linux

To be more specific, use the -h flag:

$ legion_make -h /hosts/HostFoo

The following options are supported:

-v

Run in verbose mode (up to four of these flags may be used).

-a<architecture>

Specify what kind of platform should be used to execute the command.

-h<host context path>

Specify which host should execute the program.

-e<make command>

Specify an executable command (other than make) to be run on the remote host.

-OUT<result file>

Specifies the local path name of a file that should be copied out of the remote program's current working directory after the program terminates. The default setting does not copy anything back to your current directory.

<arg1> <arg2> ... <argn>

Optional arguments passed to the make commands: they can specify make targets or other build parameters.

This command compiles Legion stubs and implementation code of CORBA client and server classes. The resulting binary executable files can be run in Legion systems. You can use the -run option to compile and execute your code in one step. Unless specified, Legion will compile client-side and class code and will register the resulting binary executable files with Legion (with the legion_mplc_reg_impl command).

The following options are supported:

-notrans

Make client-side code only.

-noclient

Make class code only.

-v

Run command in verbose mode.

-noreg

Specify that the resulting binary executable should not be registered with Legion.

-s<suffix string>

Attach a suffix to the client and/or class names (i.e., a date, run number, etc.).

-run

Run the application in Legion. Note that this will override the -noreg option.

Compile a program on multiple platforms. Like the legion_make command, this tars the current directory, copies it to a remote host, untars it, and executes a make command on it. The resulting compiled binaries can be registered with Legion via the directory's makefile. Optional flags let you specify different architectures and make commands.

The following options are supported:

-v

Verbose mode. Print actions as command executes.

-a<architecture>

Specify an architecture on which to run make. This option can be specified multiple times to request concurrent builds on multiple platforms. If no architectures are specified, a remote make for the current architecture ($LEGION_ARCH) is performed.

-e<make command>

Specify the make-command for the remote build (default is "make").

<arg1> <arg2> ... <argn>

These optional arguments are passed to the remote "make" command. They can specify make targets or other build parameters.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_mplc
[-help]

Compiles MPL (Mentat Programming Language) programs. There are several possible parameters to this command: please see the MPL Manual for more information (the MPL Manual is available from the Legion web site at <http://legion.virginia.edu/documentation.html>).

Registers the given binary, named in <binary path>, as a stateful, stateless, or sequential Mentat object for the architecture named in <arch> and under the class object named in <class name>. This command is automatically run when you use the legion_mplc command (without the -nolegion option) to compile an MPL program.

In the example below, MentatObject is a stateful Mentat object in the local path /home/legion/bin on a linux or alpha_linux machine. To register it as belonging to a class with the context path name /ClassObject/MentatObject in linux or alpha_linux architectures, you would enter:

This command uses a special output device for debugging and information reporting. When output is sent using this mechanism, the object(s) will decide whether that type of information is to be displayed and where to display it. Users will be given a series of options to selectively filter what output is displayed to the screen. The output levels include:

Warnings

Information

Low Level Debug

High Level Debug

Errors

Fatal Errors

There are two ways to use this command. You can dynamically change which of a specified object's output types are filtered out and which are displayed. This option also allows the user to change the location of the output (from stderr, stdout, and any Unix file they want).

Or, you can use the StartupState option, in which case the command will print instructions for bringing up a new system with the desired output state.

Please note: if you use StartupState, legion_output_state does not contact Legion and therefore does not run as a Legion program. I.e., you can execute it outside of a running Legion system. Otherwise, it runs as a normal Legion command-line tool.

Executes the application named in <client application> in record mode so that it can later be played back with the legion_replay tool. All objects started by the application will record all relevant event activity in a local file, named in <local storage file name>, or in a previously started Legion recorder object, named in <recorder context path> (see below). The utility also monitors the application and reports if it dies. Any application can be started with legion_record, but the command is most useful for Legion applications.

Only one execution of the application will be recorded in the storage file at a time. If you record again to the same storage file you will overwrite previous data.

If you wish to use a Legion recorder object to record your application's activity, you must start the recorder object separately (i.e., legion_create_object -c /class/RecorderObject).

If you wish to record a server object (i.e., one that is not created by the client application, but instead exists on its own), you must start the server object in record mode independently of the client application.

The following options are supported:

-name<debug session name>

Specify a name for the debug session. If this option is not used, a random name will be chosen.

-t<interval>

Specifies how long (in seconds) the legion_record utility should wait between health checks. These health checks are used to poll the recorder object to learn about object death. The default setting is 30 seconds.

Begins a replay or playback session for a recorded object. This command is used in tandem with the legion_record tool to debug a particular application. The legion_replay tool starts a debugging session for an object started in the application. If used with the -list option, the command returns a list of the sessions stored in the storage file, the session number for each object that was started, and the final states of the objects. These session numbers can then be used to debug the objects one at a time, by rerunning the command with the correct session number.

You must use one of the following sets of parameters to specify which session you wish to start. Sessions are named in legion_record (see above). If you used a Legion recorder object, you'll need to provide the debug session name as well.

The following options are supported:

-uf<local storage file name>

The local file that was used to record your session.

-c<recorder context path>

The Legion recorder object that was used to record your session (must be accompanied by debug session name).

-name<debug session name>

The desired debug session name.

-list

Display the sessions in the storage file.

-cmd<debugger>

Specify a debugging program (i.e. gdb, xdb, etc.) to run on the storage file. Default is gdb.

-local

Indicates that the debugging session should be replayed on your local machine. The default will start a remote session on the machine which executed the original object.

Creates additional MPL stateless object workers. By default, when a stateless class is created or registered in context space it instantiates a single worker. That worker is used by all other objects wishing to call a remote method invocation on that class. Adding more workers allows message calls to be handled more efficiently.

The <class name> parameter should be the stateless class object's context name. The <worker name> parameters should be the desired context name of the new worker objects. Note that you can use full or relative path names.

This command configures stateless Legion classes so that requests sent to a stateless class are first routed to a proxy object, which selects a worker to service the requests. You can use flags to control the number of replica workers, their placement, and the number of work requests that a worker may service at a given time.

The current version of the proxy object uses a self-scheduling algorithm. When N
work requests have been farmed out, the proxy will store any pending requests in an internal queue: when a worker is available, the proxy assigns it a request from the queue.

N
here is given by the following formula:

N = <number of replicas> * <max number of workers>

The following options are supported:

-n<number of replicas>

Specify the number of workers to be used. Default is 1.

-Ch<context containing list of hosts>

Name a host where the work requests should be executed.

-w<max number of work requests>

Specify the maximum number of work requests that each worker should service at a time. Default is 5.

-FlUsH

Remove all work requests for this class. You must spell this flag as written with proper capitalization.

Removes MPL stateless object workers. The <class name> parameter should be the stateless class object's context name. The <worker name> parameters should be the context name of the unwanted worker objects. Note that you can use full or relative path names.