4.5.1.3.
Check Job
Up one level
Introduction
The purpose of the checkJob.pl platform script is to check the status of submitted GRIA jobs. This script can be invoked either through the job service administration web interface, or by GRIA users using SOAP.
The job status information is returned to job service via the standard output. Any other information, e.g. debugging, etc, should be written to standard error or log files. The return code of this script determines whether the captured job status report is valid or not.
The job status information is fed back to the end-user. The check job platform script will be invoked, and run locally, by the Job Service middleware and will need to access files in the job workspace. It will invoke the application-specific checkJob script. This script will examine application-derived files in the job workspace working directory and will try to report the current status of the application, e.g. 50% of the job remaining, computation phase 3 complete, etc.
The STDOUT of this script will generate a status report for the Job Service middleware.
Script functionality
The check job script should do the following:
- Identify the workspace directory and change directory to it.
- Invoke the app-specific status script.
Script API
The check job script interface will be invoked with the following command:
checkJob <application specific get status executable>
- argument: specifies the application status wrapper script
Return values
- 0 upon success
- non-zero return number indicates error, STDERR and STDOUT will provide more information.
The status report is printed to STDOUT and used by the end-user, exit-codes are used by Job Service. Status debugging information is always written to STDERR.
Application-Specific Status Script Interface
This is an optional application specific script that should provide a qualitative measure of the running job. This script will run in the job working directory, e.g. work and report its status in STDOUT.
The functionality of this script is application dependent, it should try to estimate the progress of the running job, e.g. examining job input and output files, or any other applicable mechanism/technique to provide an estimation of how the job is progressing. The length of the generated report should be short for practical reasons.
