You need to set 'transfer_input_file = <list of files staged in>'. The problem
how to get the list of files 
to be transferred.

For pre-WS GRAM, the list of staged-in files from the RSL is available to the
proxy_relocate and stage_in 
perl subroutines, but not the submit one. One hack would be to write out the
list to a file in stage_in 
and read it back in submit.

WS GRAM looks to be more troublesome. None of the perl subroutines know the
list of staged-in files.

If the client specifies a custom directory to run the job from, the submit
subroutine could request to 
transfer all the files in that directory. This assumes the client isn't using
the same directory for many 
jobs and they're not using the default of $(HOME).

A more intrusive change would be to the change both pre-WS and WS GRAM to give
the list of staged-
in files to the submit subroutine.

The real solution is to fully drop the shared file-system assumption and say
that all files transferred 
into a certain directory will be available to the job on the execute machine.
Any files outside that 
directory may or may not be available. The default for the directory would be a
unique directory for the 
job created and cleaned up automatically by GRAM. The client could specify a
different directory, but 
they should be aware of the consequences of sharing a directory across many
jobs.

With the new extensions handling code I just added to the Perl backend, you can
add multiple 'transfer_input_file' elements to list the files that need transfering:

<condor:transfer_input_file>/some/path/to/a/file</condor:transfer_input_file>
<condor:transfer_input_file>/some/path/to/a/notherfile</condor:transfer_input_file>

$description->transfer_input_file() should then return

[ '/some/path/to/a/file', '/some/path/to/a/notherfile' ].

I can add support for this and the flag elements in the adapter pretty easily. 
Users will simply have to explicity indicate what files need staging to the
compute node.  These should just be the file URLs from fileStageIn's sourceURL
elements without the 'file://'.

An update packages for 4.0.1 are available from the following page:

http://www-unix.globus.org/toolkit/downloads/development/

Feel free to reopen this bug if I did something wrong.  I don't know how to tell
whether it actually worked, but the extensions are getting through fine.  Here's
the job description I used that at very least didn't cause any errors according
to globusrun-ws:

<?xml version="1.0" encoding="UTF-8"?>
<job>
    <executable>/bin/echo</executable>
    <directory>/home/lane</directory>
    <argument>Hello</argument>
    <argument>World!</argument>
    <extensions>
        <condor:should_transfer_files>IF_NEEDED</condor:should_transfer_files>
        <condor:WhenToTransferFiles>ON_EXIT</condor:WhenToTransferFiles>
       
<condor:transfer_intput_file>/home/lane/test.xml</condor:transfer_intput_file>
       
<condor:transfer_intput_file>/home/lane/gre.txt</condor:transfer_intput_file>
    </extensions>
</job>

You could also just have one transfer_input_file element with a comma-separated
list of files like the Condor job description uses.  The string value will just
be passed directly instead of converted from an array of values.

Can this new syntax be used to add arbitrary expressions to the condor submit
description file, or just 
attributes it knows about?

What happens if a job description with these condor attributes is submitted to
a PBS GRAM?

Are there plans to address the general problem of batch systems with no shared
file system?

The condor.pm still has support for the condor_submit parameter, so I believe
if
you do the following then you can specify arbitrary parameters:

<extensions>
    <condor:condor_submit name="attrname">attrvalue</condor:condor_submit>
</extensions>

The generic extensions support only makes values available to the adapter
module.  It's up to the module to actually do something with it.  So if PBS
doesn't go looking for those parameters then it won't do anything.

Our stance, as far as I can remember, on the general problem of systems with
non-shared filesystems has been that it's too hard to have a general, automatic
solution.  We provide the filesystem mapping machanism to allow admins to
create
transfer nodes which share a filesystem with the compute nodes.  The user would
then setup file staging directives that would take advantage of this to
transfer
files to the transfer nodes which then makes the data accessible by the compute
nodes.

Hello,

I'm trying to get my GT 4.0.2 set-up under Linux
to submit Jobs to a Windows Condor pool without success.

Set-up:
-------

Host1: GT 4.0.2 + Condor Central Manager + Condor Submit + Condor Executor
Host2: A Windows XP box set up as Condor Executor

condor_status 

reflects this correctly!


Problem:
-------
When I submit my job to WS GRAM it always specifies LINUX as a requirement but
I want
this job to run on the windows box.

In the mail archive I found several hints like this one:

http://www-unix.globus.org/mail_archive/discuss/2005/10/msg00291.html

which basically says I should add this:

<extensions>
    <condorsubmit name="Requirements">Arch == "INTEL" &amp;&amp; OpSys
=="WINNT51"</condorsubmit>
</extensions>

to my job description.
Unfortunately WS GRAM does not change anything to the ClassAd.

My second approach was to try the extension mechanism in another way as
described here:

http://globus.org/toolkit/docs/4.0/execution/wsgram/admin-index.html#s-wsgram-admin-extensions

I tried to add:

<extensions>
    <condor_os>WINNT51</condor_os>
    <condor_arch>INTEL</condor_arch>
</extensions>    

also no success.

Is the extension tag even interpreted with 4.0.2? Or is it a bug maybe?

Thomas,

Please do not ask semi-related user support questions in bug reports
(especially if the reports are already closed!). If you have questions about
GRAM, sign up for the gram-user mailing list and post those questions there.
Bug reports are for problems that are clearly bugs. If you're not sure, post to
gram-user first. If you're fairly certain it's a new bug, then file a new bug
report. We will determine if it's a duplicate or not.

Peter