Button for 1977 Button for 1984 Button for 1990 Button for 1995 Button for MDC Button for notes Button for examples

OMI - Write

Draft MDC Standard

5.4.28 Write

(Operation type 47) sends data and control information to a device. The fields of the write request and their sequence shall be:

  1. Environment: <LS> the server’s environment for the device.
  2. Device name: <LS> the server’s name for the device from the open device response.
  3. Client identifier: <SS> $Job (see ANSI/MDC X11.1) of the client process making the request, an ASCII string of decimal digits.
  4. Mnemonic space: <SS> the server’s name for the mnemonic space to which the write arguments apply.
  5. Status flags: <LI> Bits = 1 shall indicate which status items the client requests to be included in the response. All other bits shall = 0:
    Bit numberItem
    0$X
    1$Y
    2$DEVICE
    3$KEY
  6. Write arguments: 0 to 65 535 write arguments as defined in 5.3.9.

If the write response header indicates an erroneous write argument or a data overflow, then the error modifier shall indicate to which write argument the error pertains, counting the first write argument in the request as 1. When more than 1 write argument is erroneous, the error modifier shall indicate the first 1.

The server shall not accept the erroneous write argument nor any subsequent write arguments.

The server shall respond as soon as the write arguments are buffered or when lack of buffer space becomes apparent. The fields of the write response shall pertain to the current condition of the device and mnemonic space. However, if a requested status item is not available at this time, the server shall not delay its response but shall indicate in the status flags that the item is not yet available.

NOTE – The client may request status again later. A request containing 0 write arguments is valid.

<LS> <LS> <SS> <SS>
<LI> Environment <LI> Device Name <SI> Client ID <SI> Mnemonic Space

<LI>
Status Flags
Write Argument Write Argument . . .

Figure 50 – Write request

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

  1. Status flags: <LI> Bits = 1 shall indicate which status items, as defined for the request message, are included in the response. All other bits shall = 0. All of the requested items that are available at the time of the response shall be included and, at the option of the implementer, additional items may also be included.
    All of the following fields b – e shall appear. Those whose bits = 0 in the status flags field shall equal the empty string.
  2. $X: <SS> the value of $X as affected by all accepted write arguments.
  3. $Y: <SS> the value of $Y as affected by all accepted write arguments.
  4. $DEVICE: <SS> the value of $DEVICE as affected by all accepted write arguments.
  5. $KEY: <SS> the value of $KEY as affected by all accepted write arguments.
  6. Last accepted argument number: <LI> shall equal the number of write arguments the server has accepted, counting the first write argument in the request as 1. When this value is less than the number of write arguments in the request, and no other error condition pertains, the error type shall equal not all write arguments accepted.

The term accepted means that the data has been buffered or sent to the device, and not necessarily that physical output has completed successfully.

Status items whose values are not available until the completion of physical output shall have bits = 0 in the status flags until they are available.

<LI> <SS> <SS> <SS> <SS> <LI>
Status Flags <SI> $X <SI> $Y <SI> $DEVICE <SI> $KEY Last Arg

Figure 51 – Write response

Button for 1977 Button for 1984 Button for 1990 Button for 1995 Button for MDC Button for notes Button for examples

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:49:58.

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