Difference: BLAH_guide (8 vs. 9)

Revision 92008-10-02 - ElisabettaMolinari

Line: 1 to 1
 

BLAH Introduction

BLAHPD is a light component accepting commands according to the BLAH (Batch Local Ascii Helper) protocol to manage jobs on different Local Resources Management Systems (LRMS).
Line: 515 to 515
 

    Changed:
    <
    <
  • ASYNC_MODE_ON: Enable Asynchronous notification when the BLAHP server has results pending for a client. This is most useful for clients that do not want to periodically poll the BLAHP server with a RESULTS command. When asynchronous notification mode is active, the GAHP server will print out an 'R' (without the quotes) on column one when the 'RESULTS' command would return one or more lines. The 'R' is printed only once between successive 'RESULTS' commands. The 'R' is also guaranteed to only appear in between atomic return lines; the 'R' will not interrupt another command's output.
    If there are already pending results when the asynchronous results available mode is activated, no indication of the presence of those results will be given. A GAHP server is permitted to only consider changes to it's result queue for additions after the ASYNC_MODE_ON command has successfully completed. GAHP clients should issue a 'RESULTS' command immediately after enabling asynchronous notification, to ensure that any results that may have been added to the queue during the processing of the ASYNC_MODE_ON command are accounted for.
    + Request Line: ASYNC_MODE_ON + Return Line: S Immediately afterwards, the client should be prepared to handle an R appearing in the output of the GAHP server.
    + Result Line: None.
    + Example:
  • >
    >
  • ASYNC_MODE_ON: Enable Asynchronous notification when the BLAHP server has results pending for a client. This is most useful for clients that do not want to periodically poll the BLAHP server with a RESULTS command. When asynchronous notification mode is active, the GAHP server will print out an 'R' (without the quotes) on column one when the 'RESULTS' command would return one or more lines. The 'R' is printed only once between successive 'RESULTS' commands. The 'R' is also guaranteed to only appear in between atomic return lines; the 'R' will not interrupt another command's output.
    If there are already pending results when the asynchronous results available mode is activated, no indication of the presence of those results will be given. A GAHP server is permitted to only consider changes to it's result queue for additions after the ASYNC_MODE_ON command has successfully completed. GAHP clients should issue a 'RESULTS' command immediately after enabling asynchronous notification, to ensure that any results that may have been added to the queue during the processing of the ASYNC_MODE_ON command are accounted for.
    + Request Line: ASYNC_MODE_ON <CRLF> + Return Line: S <CRLF> Immediately afterwards, the client should be prepared to handle an R <CRLF>appearing in the output of the GAHP server.
    + Result Line: None.
    + Example:
  •  
      S: ASYNC_MODE_ON
      R: S
    Line: 545 to 545
     

      Changed:
      <
      <
    • ASYNC_MODE_OFF: Disable asynchronous results-available notification. In this mode, the only way to discover available results is to poll with the RESULTS command. This mode is the default. Asynchronous mode can be enabled with the ASYNC_MODE_ON command.
      + Request Line: ASYNC_MODE_OFF + Return Line: S + Results Line: None
      + Example:
    • >
      >
    • ASYNC_MODE_OFF: Disable asynchronous results-available notification. In this mode, the only way to discover available results is to poll with the RESULTS command. This mode is the default. Asynchronous mode can be enabled with the ASYNC_MODE_ON command.
      + Request Line: ASYNC_MODE_OFF <CRLF> + Return Line: S <CRLF> + Results Line: None
      + Example:
    •  
        S: ASYNC_MODE_OFF
        R: S
      Line: 555 to 555
       
      Changed:
      <
      <
      • BLAH_JOB_SUBMIT: Submit a job request to a specified queue (specified in the submit classad). This will cause the job to be submitted to the batch system.
        + Request Line: BLAH_JOB_SUBMIT
        • reqid = non-zero integer Request ID
        • submit classad = valid submit description for the job, in string representation. See paragraph 3.0 for a description of the format. Here's a list of supported attributes with a brief description.
      >
      >
      • BLAH_JOB_SUBMIT: Submit a job request to a specified queue (specified in the submit classad). This will cause the job to be submitted to the batch system.
        + Request Line: BLAH_JOB_SUBMIT <SP> <reqid> <SP> <submit classad> <CRLF>
        • reqid = non-zero integer Request ID
        • submit classad = valid submit description for the job, in string representation. See paragraph 3.0 for a description of the format. Here's a list of supported attributes with a brief description.
       
      "Cmd"
      Full path of the executable in the local filesystem
      "Args"
      List of individual arguments (no '/bin/sh' convention on argument separation, but separate arguments) for the executable
      "In"
      Full path in the local filesystem where the standard input for the executable is found
      "Out"
      Full path in the local filesystem where the standard output of the executable will be stored (at job completion).
      Changed:
      <
      <
      "Err"
      Full path in the local filesystem where the standard error of the executable will be stored (at job completion). "X509UserProxy": Full path wherethe proxy certificate is stored.
      "Env"
      Semicolon-separated list of environment variables of the form: = "Stagecmd": Sets if the executable of the job must be copied on the WorkerNode: can be "TRUE" or "FALSE". "Queue":Queue in the local batch system where the job must be enqueued. "Gridtype": String indicating the underlying local batch system (currently "pbs" and "lsf" supported).
      + Return Line:
        • result = the character "S" (no quotes) for successful submission of the request (meaning that the request is now pending), or an "E" for error on the parse of the request or its arguments (e.g. an unrecognized or unsupported command, or for missing or malformed arguments).
          + Result Lines: <result-code _moz-userdefined=""> <error-string _moz-userdefined=""> </error-string></result-code>
        • reqid = integer Request ID, set to the value specified in the corresponding Request Line.
        • result-code = integer equal to 0 on success, or an error code
        • error-string = description of error
      >
      >
      "Err"
      Full path in the local filesystem where the standard error of the executable will be stored (at job completion).
      "X509UserProxy"
      Full path wherethe proxy certificate is stored.
      "Env"
      Semicolon-separated list of environment variables of the form:
                 <parameter> = <value>
      "Stagecmd" :Sets if the executable of the job must be copied on the WorkerNode
      can be "TRUE" or "FALSE".
      "Queue"
      Queue in the local batch system where the job must be enqueued.
      "Gridtype"
      String indicating the underlying local batch system (currently "pbs" and "lsf" supported).

      + Return Line:
      <result> <CRLF>
        • result = the character "S" (no quotes) for successful submission of the request (meaning that the request is now pending), or an "E" for error on the parse of the request or its arguments (e.g. an unrecognized or unsupported command, or for missing or malformed arguments).
          + Result Lines: <reqid> <sp> <result-code> <sp> <error-string> <sp> <job_local_id> <crlf>
        • reqid = integer Request ID, set to the value specified in the corresponding Request Line.
        • result-code = integer equal to 0 on success, or an error code
        • error-string = description of error
       
        • job_local_id = on success, a string representing a unique identifier for the job. This identifier must not be bound to this BLAHP server, but instead must be allowed to be used in subsequent BLAHP server instantiations. For instance, the job_local_id must be implemented in such a fashion that the following sequence of events by the caller must be permissible:
          • a) issue a BLAH_JOB_SUBMIT command
          • b) read the job_local_id in the result line
       
      This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
      Ideas, requests, problems regarding TWiki? Send feedback