2.3 Calls on LegionClass

legion_add_class_mapping 
      <metaclass LOID> <class LOID> [-debug] [-help]

This command notifies LegionClass that the meta-class named by <metaclass LOID> is the class of the class named by <class LOID>. LegionClass updates its class map accordingly.

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_combine_domains 
      [-v] <list of domain cookie files> [-debug] [-help]

Joins a set of Legion domains (systems) to create a single, larger, multi-domain Legion system. Before you run this command, you must obtain a copy of the Legion domain cookie files from all of the involved domains (see legion_generate_domain_cookie, page 21, and legion_print_domain_cookie, page 22), including the current Legion domain. If you are joining domain A to domain B and domain B has already been joined to domain C, you will need cookie files from domains A, B, and C. This provides transitivity in the system join. All three domains will be joined to one another to form a single system. The command is implemented this way to avoid communication failures; if a LOID can be passed to an object (e.g., in a method continuation list), that object should be able to use the LOID for further communication.

Non-transitive or non-reflexive joins would allow communication of LOIDs for which an object could not obtain a binding. For example, object X in domain A might be able to bind to object Y in domain B and pass a method to it, but object Y might not be able to bind to object X to pass it the return value.

In addition to joining the binding trees of the involved domains, legion_combine_domains also creates context links in the current domain's context space to all of the remote domains' root contexts. These links appear in local context space in the following path: /domain/LegionDomain.<domain-id>.

If the command is run on domains that are already connected, it has no affect and is harmless.

There is currently no mechanism supporting "unjoining" of domains. However, Legion security mechanisms (e.g., ACLs) can be used to effectively forbid any use of the current domain by outside domains.

The following options are supported:

-v

Provide a verbose output as the command is running.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

The example below combines two domains. If either had previously been connected to another domain, three cookie files would be listed.

$ legion_combine_domains LegionDomainCookie.35d82a07 \
	LegionDomainCookie.c8
Created 2 new domain interconnections
$
legion_create_implementation 
      <binary path name> <architecture> 
      {[-c] <class context name> | -l <class LOID>} 
      [-c <object context path>] [-nc] [-v] [-a <attribute>] 
      [-debug] [-help]

Creates an implementation object based on the binary executable named in <binary path name>. Each class maintains a list of the implementation objects that are suitable for its instances. There are a set of implementation objects created when your system was initialized (use legion_ls -la /impl to see a list). Several different implementation objects might be maintained by a class to support the use of multiple platforms -- a class might have implementation objects for different architectures, for different operating systems, with different memory requirements, etc.

The new implementation object is associated with the class object named in <class LOID> or <class context path>, and is marked as usable for hosts of a specified type (linux, solaris, etc.). The sample below creates a new implementation object for my_class:

$ legion_create_implementation Legion/bin/linux/my_class \
  linux my_class
$

The new object is automatically assigned the context path /impls/my_class.linux.1 (if you ran the example a second time, the new object would be called /impls/my_class.linux.2). You can use the -c <object context path> flag to specify a different context path or the -nc flag to specify that no context path be assigned.

At the moment, possible <architecture> values are:

  • solaris (Sun Workstation/Solaris 5.x)
  • sgi_o32 (SGI Workstations/IRIX 5.x or 6.x o32 build)
  • sgi_n32 (SGI Workstations/IRIX 5.x or 6.x n32 build)
  • sgi_n64 (SGI Workstations/IRIX 5.x or 6.x n64 build)
  • linux (x86/Red Hat 5.x Linux)
  • x86_freebsd (x86/FreeBSD 3.0)
  • alpha_linux (DEC Alpha/Red Hat Linux 5.x)
  • alpha_DEC (DEC Alpha/OSF1 v4)
  • rs6000 (IBM RS6000/AIX 4.2.1)
  • hppa_hpux (HPUX 11.x)1
  • winnt_x86 (Windows NT 4.0)2
  • t90 (Cray T90/Unicos 10.x)3
  • t3e (Cray T3E/Unicos/mk 2.x)

The following optional parameters are supported:

-c <context path>

Specify a context path for the new object. Default is /impls/<binary_name>.<arch-itecture>.<#>

-nc

Specify that the new object have no context name.

-v

Run the command in verbose mode.

-a <attribute>

Assign the new object an extra attribute.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_generate_domain_cookie 
      [-o <cookie output filename>] [-debug] [-help]

Generates a domain cookie file for the current Legion domain, as required by legion_combine_domains (page 19). A cookie file contains binding information for the LegionClass in the current domain, security credentials for joining to the current domain, and information about the context space of the current domain (for creating interdomain context space links). The default cookie file name is LegionDomainCookie.<domain-id>, or you can use the -o flag to specify a name. In a secure environment, you must be logged in as /users/admin for the current domain. This ensures that the required credentials can be generated and saved in the cookie file.

The following optional parameters are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_init_arch [-debug] [-help]

Creates and registers implementation objects for commonly used classes in the current architecture. This command is run on a new host to create its implementation objects in the proper place. Implementation objects for specific binary executables can be created with the legion_create_implementation utility (page 20).

The sample below, run on a linux machine, creates a set of implementation objects for a linux host.

The following options are supported:

-debug

Catch an31d print Legion exceptions.

-help

Print command syntax and exit.

legion_list_domains [-debug] [-help]

List the domains currently connected to your current Legion domain. The output will list the binding for your current domain and any domains linked to your current domain. Please see legion_combine_domains (page 19) for information about connecting Legion domains.

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_print_domain_cookie
      [-i <cookie input file>] [-debug] [-help]

Displays the contents of a Legion domain cookie file (required for using legion_combine_domains). By default the command displays the contents of the file LegionDomainCookie.<current-domain-id>, but any input file name can be specified using the -i option.

The following options are supported:

-i <cookie input file>

Specify the path of the cookie file to print.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.


1. The HPUX 11 platform is available upon request. We will include an HPUX 10 platform in a future release. back

2. The 1.7 Windows NT platform is a beta release. Please see section 16.0 in the System Administrator Manual before you proceed. A binary for the Windows 2000 platform is available from Applied MetaComputing, Inc.(<http://www.appliedmeta.com>). back

3. The T90 and T3E architectures must be used with virtual hosts. Please see section 14.0 in the System Administrator Manual. back

Directory of Legion 1.7 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source

legion@Virginia.edu
http://legion.virginia.edu/