☜	OMI - Open Device Draft MDC Standard					☞

5.4.22 Open device

(Operation type 41) gains ownership of a device. The device parameters of the request pertain only to the first mnemonic space named in the request. If the request names no mnemonic space, they shall pertain to the null mnemonic space (see 5.3.5).

The fields of the open device 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 a device that the client requests to open.
3. Client identifier: <SS> $Job (see ANSI/MDC X11.1) of the client process making the request, an ASCII string of decimal digits.
4. Style: <SI> 0 denotes the positional style, and 1 denotes the keyword style of device parameters. All other values are reserved.
5. Device parameters: <LS> as defined in 5.3.7.
6. Mnemonic spaces: <LS> shall contain 0 or more mnemonic spaces <SS> (see 5.3.5), which constitute the valid mnemonic spaces of subsequent transactions for the device.
7. Minimum write argument limit: <LI> the smallest maximum length of a single write argument that is acceptable to the agent.
8. Maximum write argument limit: <LI> the maximum length of a single write argument that can be processed by the agent.

Figure 43 – Open device request

The fields of the open device response and their sequence shall be:

1. Device name: <LS> often identical to the corresponding field of the request. However, the server may substitute a different name, which the client shall use in all subsequent requests referring to the device. For example:
   • A client requests a line printer and the server responds with the name of 1 printer in a pool.
   • A server returns a preferred name for a device requested with an alias.
2. Write argument limit: <LI> The server shall compare the agent’s maximum and minimum write argument limits with its own limits and shall return either the largest value possible or, if the agent’s limits are not within its bounds, a minimum write argument limit or maximum write argument limit error condition.
   NOTE – The server shall accept a write argument of this length when no output is pending to the device. However, pending output may occupy part of the maximum write argument length, and the server need not accept a write argument that would then surpass the maximum.

A successful open device transaction shall mean only that the device parameters and mnemonic spaces are acceptable, and that ownership of the device has been granted to the client. It shall not imply anything about the device’s state or accessibility on the server. That is, the error conditions device not accessible and device not ready shall not apply to this transaction.

When the client already owns the device, the device already owned error condition shall not apply. That is, a redundant open device request shall succeed if otherwise acceptable.

Figure 44 – Open device 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:49:16.

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