☜	OMI - Request Header 1995 Version of ANSI (Equivalent to Current ISO Version) of Standard					☞

5.3.1 Request header

Each request shall contain a header that, among other things, identifies the user. Inclusion of this information permits transactions to be isolated (see 4.3.3). Without it the server would have to track users and their authorizations across transactions.

The request header is a short string <SS> so that the server can locate the field following the header regardless of the length of the header.

Note – The request header has fixed length, but future versions of OMI may specify different lengths. Servers and agents need to find the version numbers following the header in connect messages, regardless of the version in use (see 4.8).

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

1. Operation class: <LI> denotes 1 of 65 536 classes of operations. The MUMPS Development Committee assigns classes to OMI versions and to specific extensions of the standard (see 4.11). The class of operations specified by ANSI/MDC X11.2 shall be 1. All other classes are reserved for assignment by the MUMPS Development Committee.
2. Operation type: <SI> denotes a specific operation within an operation class. For example, set and kill are operation types 10 and 13.
3. User identifier: <LI> identifies a user for security purposes. See 4.5.
4. Group identifier: <LI> identifies a group of users for security purposes. See 4.5.
5. Sequence number: <LI> This sequential number starts at 1 and increments by 1 to 65 535, then continues with 1. The server may use this number to verify that requests are received and processed in the correct order. The agent may choose any valid starting sequence number for a connect request, causing the server to synchronize at that sequence number.
6. Request identifier: <LI> links responses to requests. The content of this field is left to the implementer, except that the server must return the value from each request in the corresponding response.

Table 1 shows the OMI operations and the values assigned to their operation types. These operations suffice for the database functions of ANSI/MDC X11.1. The unlock client and unlock all operations provide additional convenience for implementers.

Control operations establish and maintain the OMI session. They do not relate to application-level processes.

The global update and fetch operations perform assignment and retrieval of global variables and their values. They correspond directly to application-level database operations.

Lock operations claim and release exclusive use of nrefs, which correspond to database records by application program conventions.

Figure 2 – Form of a request header

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.

This page most recently updated on 13-Sep-2014, 14:16:37.

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