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 24, and legion_print_domain_cookie, page 25), 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.7 or later )
• sgi_n32 (SGI Workstations/IRIX 6.5 n32 build or later n32 build)
• sgi_n64 (SGI Workstations/IRIX 6.5 n64 build or later n64 build)
• linux (x86/Red Hat 6.x Linux)
• alpha_linux (DEC Alpha/Red Hat Linux 6.x)
• alpha_DEC (DEC Alpha/OSF1 v4)
• rs6000 (IBM RS6000/AIX 4.3)
• hppa_hpux (HPUX 11.x)¹
• t90 (Cray T90/Unicos 10.x)²
• 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>.<#>
-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 22). 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>. 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 23).

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

$ legion_init_arch
Initializing Legion implementations for "linux"
Creating an implementation (ContextObject) for ContextClass
Continue (y=yes, Y=yes to all, n=no, N=no to all, v=verbose,
 	V=verbose all)? Y
Creating an implementation (MetaClassObject) for LegionClass
Creating an implementation (ClassObject) for VanillaMetaClass
Creating an implementation (BindingAgent) for 
	BindingAgentClass
Creating an implementation (BasicFileObject) for
	BasicFileClass
Creating an implementation (ttyObject) for ttyObjectClass
Creating an implementation (StatTreeObject) for StatTreeClass
$

The following options are supported:

-debug	Catch and 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 22) 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.

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

Table of Contents 1.0 Introduction    1.1 About this manual    1.2 Style conventions 2.0 Command-line functions    2.1 Calls on objects    2.2 Calls on class objects    2.3 Calls on LegionClass    2.4 Calls on file and context objects    2.5 Start-up and shutdown functions    2.6 Scheduling support    2.7 General functions about the state of the system    2.8 Security    2.9 Application development    2.10 Program support 3.0 Error Codes 4.0 Internal Tools 5.0 Alternative ways to start and shut down    5.1 Starting extra hosts and vaults, command line    5.2 Shutting down extra hosts and vaults, command line    5.3 Restarting extra hosts and vaults    5.4 Using two hosts to start up a system 6.0 Example translations: the simple class    6.1 Simple.h and Simple.c    6.2 Simple.trans.h and Simple.trans.c    6.3 ex1_Simple.c 7.0 Interfaces    7.1 LegionProgramGraph    7.2 LegionInvocationStore    7.3 LegionWorkUnit    7.4 LegionBuffer       7.4.1 Constructors       7.4.2 Operations on the associated LegionStorage       7.4.3 Operations on the associated LegionPacker       7.4.4 Operations on the associated LegionEncryptor       7.4.5 Operations on the associated LegionCompressor       7.4.6 LegionPackable       7.4.7 Other functions       7.4.8 Naming and binding: LegionLOID    7.5 LegionMessage       7.5.1 LegionParameter       7.5.2 LegionParameterList       7.5.3 LegionComputationTag       7.5.4 Other fields 8.0 Grid library    8.1 Legion Library interface    8.2 Exceptions    8.3 Legion context space    8.4 Legion object management    8.5 Legion attributes    8.6 Interfaces to Legion objects    8.7 Legion C++ type manipulation    8.8 Legion host object    8.9 Vault object    8.10 Class object    8.11 Legion implicit parameters    8.12 Collections 9.0 Error messages Getting help Index

Directory of Legion 1.8 Manuals [Home] [General] [Documentation] [Software] [Testbeds] [Et Cetera] [Map/Search] Free JavaScripts provided by The JavaScript Source

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