☜	OMI - Job Draft MDC Standard					☞

5.4.31 Job

(Operation type 61) initiates an M[UMPS] process on the server.

The fields of the job request and their sequence shall be:

1. Job environment: <LS> the server’s environment in which the process shall execute.
2. Client identifier: <SS> $Job (see ANSI/MDC X11.1) of the client process making the request, an ASCII string of decimal digits.
3. Label: <SS> the label of a line in the M[UMPS] routine named in this request. If label is the empty string it refers to the first line of the routine.
   The agent shall send the label using the server’s character set profile for the routine named in the routine reference.
4. Offset: <LI> the number, 0 or more, of lines following label at which execution shall begin.
5. Routine reference: <LS> the M[UMPS] routine that the initiated process shall execute, including its name, the environment from which it shall be fetched, and its actual arguments. See 5.3.4.
6. Process parameters: <LS> as defined in 5.3.6.
7. Time out: <SS> The empty string indicates no time out; the server shall try indefinitely to initiate the process. Otherwise, the possibly non-integer decimal number of seconds that the server shall try before invoking the job timed out error condition.
   NOTE – a cancel job request may cancel the server’s attempt before process initiation succeeds.

A job request shall be erroneous while another job request from the same client is incomplete. A job request shall be complete when either of the following has occurred:

• The requested process has been initiated successfully, even if the server has not reported it to the client. That is, the job response may indicate pending and process initiation may complete later.
• The server responds with any error condition related to the job request.

The server shall respond as soon as possible, that is, it shall not wait for initiation of the requested process to complete. The response header shall indicate an error in the job request itself, or it shall contain error type 0, indicating success, and the error modifier shall denote the completion of process initiation: 0 shall indicate that process initiation has completed successfully, and 1 shall indicate that process initiation is pending – the agent should send a job status request to learn about completion.

Figure 54 – Job request

The fields of the job response and their sequence shall be:

1. Job request number: <LI> a number chosen by the server shall uniquely identify 1 job request from the time this response is sent until the job request is complete. Job status and cancel job requests shall use it to distinguish job requests. If process initiation has completed at the time of the job response, the value of job request number is unspecified.
2. Process identifier: <SS> $Job (see ANSI/MDC X11.1) of the initiated process, an ASCII string of decimal digits. If the server’s operating system does not provide this information, this field shall equal the empty string. While process initiation is pending, the value of process identifier is unspecified.

The server shall retain the job request number and status of 1 job request per client. (It may do so for more than 1 job request at the option of the implementer.) The server shall retain the job request number and status of each job request until the server has reported the disposition of that job request once, specifically until the server has taken any 1 of the following actions:

• issued a job response indicating any error.
• issued a job status response indicating any error.
• issued a job response indicating that process initiation has completed successfully.
• issued a job status response indicating that process initiation has completed successfully.
• issued a cancel job response for that job request number.
• issued a cancel all jobs response.

NOTE – an overlapping job requests error therefore causes the status of preceding job requests to be lost. Acceptance of a job request implies that it does not overlap preceding job requests (unless the implementation supports multiple pending job requests). Therefore, when the server receives non-overlapping job requests, it need retain the job request number and status of only the most recent job request per client.

Subsequent job status requests may evoke an unknown job request number error.

Figure 55 – Job response

Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.

Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.

This page most recently updated on 14-Nov-2023, 21:50:23.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)