In GRAM4 an administrator can configure a default local resource manager being used for job submission if the client did not specify any in a job submission request. Check section Defining a default local resource manager in the System Administrator's Guide for more information.

The log4j configuration for audit logging in GRAM4 in 4.2 is slightly different compared to the 4.0 series. This involves log4j and database configuration changes. For the log4j configuration check section section Configure Log4j in the System Administrator's Guide for more information. For the database related changes check Configure the Database in JNDI in the System Administrator's Guide.

An administrator can configure lifetime parameters for all jobs in GRAM4's JNDI configuration. In short these parameters restrict the maximum lifetime a client can set on a job, and the maximum time a job is kept in the container and thus in the persistence directory after the job had been fully processed. Check section Job Lifetime in the Execution key concepts and section Job lifetime configuration in the System Administrator's Guide for more information.

By default GRAM4 in the 4.0 series does Web Service invocations when calling RFT to perform staging and file cleanup. The default in GRAM4 in 4.2 is local java calls to significantly improve performance in jobs with staging and file cleanup. If GRAM4 is configured to use RFT in a separate machine local invocations are disabled. For more information check the section GRAM4 - RFT interaction in the System Administrator's Guide

An administrator can configure the number of threads in the thread-pool that is responsible for handling scheduler events. The default size should be fine for all Scheduler Event Generators (SEGs) provided by Globus. It might be interesting for custom written SEGs. Check section Configuring thread-pools in the System Administrator's Guide for more information.

Due to the WSRF, WSN and WS-Adressing specification upgrade some namespaces changed. All occurences of the following old 4.0 namespaces must be updated to the new 4.2 namespaces.

Additionally, in a job description the ReferenceProperties element must be renamed to ReferenceParameters.

The following shows a factoryEndpoint element of a 4.0 job description and a 4.2 job description:

# Endpoint in 4.0
<factoryEndpoint
  xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
  <wsa:Address>
    https://grid-w.ncsa.teragrid.org:8444/wsrf/services/ManagedJobFactoryService
  </wsa:Address>
  <wsa:ReferenceProperties>
    <gram:ResourceID>Fork</gram:ResourceID>
  </wsa:ReferenceProperties>
</factoryEndpoint>

# Endpoint in 4.2
<factoryEndpoint
  xmlns:gram="http://www.globus.org/namespaces/2008/03/gram/job"
  xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <wsa:Address>
    https://grid-w.ncsa.teragrid.org:8444/wsrf/services/ManagedJobFactoryService
  </wsa:Address>
  <wsa:ReferenceParameters>
    <gram:ResourceID>Fork</gram:ResourceID>
  </wsa:ReferenceParameters>
</factoryEndpoint>

GRAM4 in 4.2 defines a default local resource manager which is used for job execution if the user did not explicitly specify one. A user however still can specify a local resource manager (LRM), e.g. if it's required that a job runs in a certain LRM. Check

globusrun-ws in 4.0 sets a default lifetime of 24h on a job if a user does not explicitly set it. In 4.2 a job will run to completion in any event if no lifetime is specified, i.e. it will not be terminated after 24h.

However, there are server-side settings define limits on an explicitly requested lifetime, and that determine what will happen to a completed job if no lifetime had been set. Check section Job Lifetime in the Execution key concepts and section Job Lifetime in the User's Guide for more information.

Due to the WSRF, WSN and WS-Adressing specification upgrade namespaces of many components have changed. Check section Specification upgrade related changes and the Java WS Core Migration guide for details.

GRAM4 does not extend from the ImmediateResourceTermination port type anymore, i.e. the Destroy() operation is no longer available to synchronously destroy job resources. Instead GRAM4 offers an asynchronous Terminate() method that lets clients terminate jobs and destroy a job resource. Check the TerminateManagedJobPortType PortType in the section 'WSDL and Schema Definition' of the Developer's guide for details and section Job termination for explanations of the new termination interface.

The Java API GramJob in 4.0 sets a default lifetime of 24h on a job if a developer does not explicitly set it. In 4.2 it will not be set and a job will run to completion in any event if no lifetime is specified, i.e. it will not be terminated after 24h.

However, there are server-side settings define limits on an explicitly requested lifetime, and that determine what will happen to a completed job if no lifetime had been set. Check section Job Lifetime in the Execution key concepts and section Job Lifetime in the User's Guide for more information.

In GRAM4 in the 4.0 series a client had to destroy subscription resources before destroying a job if it subscribed for notifications in order to cleanup state on the server-side. In GRAM4 in 4.2 all subscription resources of a job resource are destroyed on the server-side automatically if a job resource is destroyed. There's no need to keep track of subscription resources anymore.

In GRAM4 an administrator can configure a default local resource manager (LRM) being used for job submission if the client did not specify any in a job submission request. To submit a job to the default local resource manager just don't put a ReferenceParameters element in the EndpointReference used to contact GRAM4's job factory service. By querying resource properties of GRAM4's factory service a client can find out which local resource manager is the default, or which LRM's are available on the server-side.

In GRAM4 in GT 4.0 the client-side generated submission being set in CreateManagedJobInputType.JobID had been used as server-side job id for multi-jobs. In GRAM4 in 4.2 a UUID is created on the server-side to manage the job and the client-side generated ID will only be stored to enable reliable job submission. A client cannot use the self-generated id for any job operation besides a second submission call for multi-jobs anymore. See section Client-Side Generated Submission ID for more information about this.