The Grid Resource Allocation and Management (GRAM) service provides a single interface for requesting and using remote system resources for the execution of "jobs". The most common use of GRAM is remote application execution and control. It is designed to provide a uniform, flexible interface to job scheduling systems.

2. Feature Summary

Features new in release 4.1.1

An alternate job polling mechanism which uses the Scheduler Event Generator from WS-GRAM in place of polling the scheduler directly.
Recording of audit records to a directory, with a tool for uploading audit records to a database.

Other Supported Features

The ability to select the account under which the remote job will be run. If a user's grid credential is mapped to multiple accounts, then the user can specify in the RSL under which account the job should be run.
Remote job execution and management
Uniform and flexible interface to batch scheduling systems
File staging before and after job execution
Data streaming of stdout/err during jobs execution

Deprecated Features

None

3. Changes Summary

The following changes have occurred for GRAM2 since the last stable release, 4.0.4:

[summarize changes]

4. Bug Fixes

Bugzilla url to bugs fixed since previous stable version
...
Bugzilla url to bugs fixed since previous stable version

5. Known Problems

Bugzilla url here
...
Bugzilla url here

6. Technology Dependencies

GRAM2 depends on the following GT components:

C Common Libraries
Pre-WS Authentication and Authorization
XIO
GridFTP

GRAM2 depends on the following 3rd party software. The dependency exists only for the batch schedulers configured, thus making job submissions possible to the batch scheduling service:

PBS
Condor
LSF
other batch schedulers... (where the GRAM scheduler interface has been implemented)

7. Tested Platforms

Tested Platforms for GRAM2

Linux

8. Backward Compatibility Summary

Protocol changes since GT version 4.0.4

GRAM job requests may append the desired local username after the @ symbol in the service path (jobmanager-fork@username). This is done automatically when the username RSL attribute is present.

API changes since GT version 4.0.4

Implementation change: the GRAM client library now parses the RSL string and checks for the username attribute. Previously, the client library did no parsing of the RSL string.

Exception/error changes since GT version 4.0.4

GLOBUS_GRAM_PROTOCOL_ERROR_RSL_USER_NAME - username attribute value is not a literal string.
GLOBUS_GRAM_PROTOCOL_ERROR_INVALID_USER_NAME - username attribute present but not running as the specified user (most likely using an old client.)

Schema changes since GT version 4.0.4

There is a new RSL attribute username. If present, the job will be submitted to run as the specified user. If the job manager is not running as that user, it will not run the job.

9. For More Information

See GRAM2 for more information about this component.

Prev	Up	Next
Part . GT 4.1.1 GRAM2	Home	GT 4.1.1 Using Scheduler Event Generator with GRAM2