  Here You can find an explanation of jobstatus files.
 ID stands for job identifier and usually consists of 2 numbers
separated by dot ( number.number ).

-----------------
job.ID.status - current status of the job. It contains one word of text
representing status of the job. Possible values:
ACCEPTED    - job just
PREPARING
SUBMITTING
INLRMS
FINISHING
FINISHED
CANCELING

the possible changes are:

                                 /------<------\
                                 |             |
ACCEPTED ---> PREPARING ---> SUBMITTING ---> INLRMS ---> FINISHING ---> FINISHED
   |             |               |             |            ^
   |             |               |          CANCELING       |
   |             |               |             |            |
   \------>-------------->-------------->------------>------/

 In case of failure job can go to FINISHING from any other state (except
FINISHED). In such case all output files will have they url part removed
and will not be moved to external storage but left on computing element.
 If cancel request received job will be moved to FINISHING as in case of
failure. Intermidiate state CANCELING involves running LRMS command to
cacnel executing job.
 If job is allowed to be rerun (specified attribute rerun is greater than 0)
it can go in loop between INLRMS and SUBMITTING. But no more times than
specified value or default value given in configuration file.


------------------
job.ID.description  - contains RSL of the job after substitutions performed.


------------------
job.ID.local - information about the jobs used by GM. It consists of
lines of format  name=value . There are following names:

subject  - user subject aka DN
starttime - time when job was accepted
UI - ip of user interface (not yet)
lifetime - time to live for session directory after job finished (seconds)
notify - email addresses and flags to send mail to about job status changes.
processtime - when to start processing job (can be missing)
exectime - when to start job execution (can be missing)
rerun - number of tries to run the job left
jobname - name of the job supplied by user (can be missing)
lrms - name of lrms to run job at
queue - name of queue to run the job at
localid - job id in lrms (appears only then job's becomes INLRMS)
args - list of arguments including executable.

While job's status is ACCEPTED only subject and starttime are present.


-----------------
job.ID.input  - list of input files. Each line contains 2 values separated
by space. First value contains name of the file relative to session directory.
Second value is url or file description.
  url - ordinary url for gsiftp, ftp, http, https or gass protocols (protocols
        supported by globus library). Example:
input.dat gsiftp://grid.domain.org/dir/input_12378.dat
  file description - [size][.checksum] 
    size - size of file in bytes.
    checksum - checksum of the of the file identical to one produced 
        by cksum (1).
  each of size or checksum can be missing.
This file is used by utility called 'downloader'. Files with 'url' will be
downloaded and files with 'file description' will be checked to exist.
Each time new valid file appears in session directory it is removed from
the list and job.ID.input is updated.
  
------------------
job.ID.output  - list of output files. Each line conatins 1 or 2 values 
separated by space. First value is name of the file relative to session
directory. Second value, if present, is url. Supported urls are the same
as for job.ID.input with addition of 'replica catalog url'. For the 
description of that url look usage instructions.
 This file is used by utility called 'upploader'. Files with 'url' will be
uploaded and other files will be left in session directory. Each time 
file is uploaded it is removed from list and job.ID.output is updated.

------------------
job.ID.failed  - the existence of this file marks failure of the job. It
can also contain one or more lines of text describing the reason of failure.

------------------
job.ID.errors  - is the files containing the output of produced by external
utilities like downloader, uploader, script for job submission to LRMS, etc
on their stderr handle. Those are not necessary errors, but can be just 
useful information about actions taken during job's processing.

------------------
There are other files woth names like job.ID.* which are created and used
by different parts of GM. They presence in jobcontrol directory can not
be guaranteed and can change depending on changes in GM code.
