mvx is the classic shell: a prompt, a builtin table, VOC dispatch, and nothing else. Verbs are compiled BASIC programs.

mvx -a /path/to/account          # log on to an account
mvx -a acct -c "LIST PARTS"      # one command (ssh/cron style)

Interactive sessions have arrow-key history (persisted in ~/.mvx_history) and the prompt names the account.

Resolution order for a typed command: builtins → the account VOC → linked packages (in order) → the system account. Local entries override everything; the system account is the source of truth for standard verbs.

A VOC record whose attribute 1 is PA is a paragraph: the attributes after it are sentences, run in order. It is typed like a verb, reached by EXECUTE, and may be an account's LOGIN.

DAILY
001 PA
002 * the overnight run
003 SELECT ORDERS WITH DESPATCHED = "N"
004 REPORT.PICKLIST
005 COUNT ORDERS

• Comments begin with *; blank lines are skipped.

• Sentences are not echoed — a paragraph of two commands prints what those two commands print, and nothing else.

• <<text>> asks the operator text and puts the answer where it stood. The same prompt twice is one question, reused:

  002 COUNT <<Which file>> ; LIST <<Which file>>
  

• A sentence that fails does not stop the paragraph. The message names the paragraph — In paragraph DAILY: ... — because "not a verb" on its own leaves you hunting for what ran it.

• Paragraphs nest: one may invoke another.

A cataloged program still wins: a V record is looked for first, and a paragraph only when there is none.

These rules are UniData's, measured rather than assumed. Two are not what you might expect: sentences are not echoed, and <<%1>> is not parameter substitution — paragraphs have no %n parameters, and that spelling simply prompts with the text %1.

A VOC record whose attribute 1 is PQ (or PQN) is a PROC. Where a paragraph is a list of sentences, a PROC builds a command and then runs it — the older Pick mechanism, carried by accounts ported from UniData or OpenQM.

DPQ
001 PQ
002 S2          <- put the input pointer on word 2 of the command line
003 HCOUNT      <- build "COUNT " into the output buffer
004 A           <- copy the word under the pointer in after it
005 P           <- execute what was built, and carry on

Word 1 is the verb, so a PROC's first argument is word 2 — which is why S2 is the usual opening line.

An opcode MVX does not know is named, not skipped. The secondary input buffer, T terminal control, STON/STOFF stacking and the [] call are not implemented: they exist because PROC had no other way to do things MVX does directly. A PROC needing one fails loudly rather than doing half its job.

These rules are UniData 8.3's and ScarletDME 2.6-6's, which agree on every opcode above.

If the account's VOC holds a record named LOGIN, it runs when a session enters the account: at mvx -a, and on every LOGTO. It is an ordinary cataloged program, so making one is:

CATALOG BP LOGIN

• The account's own. A LOGIN in a linked package or the system account is not inherited — it would otherwise run in every account on the machine.
• On entering, not per program. A cataloged program run straight from Unix does not trigger it.
• A failure is reported, not fatal. The session is already in the account by then, so an abort in LOGIN is caught and the caller carries on.
• No loops. A LOGIN that itself does a LOGTO does not start another.
• It may not own the screen. A LOGIN entered directly sees @LEVEL = 0; one fired by a LOGTO from inside a running program sees 1, and should not prompt — the keystroke it reads is the one that program was waiting for.

LOGIN may equally be a paragraph or a PROC (above), which is what it is on UniData — a cataloged program cannot be a LOGIN there at all. The hook does not care: it runs the sentence LOGIN, whatever the record turns out to be.

UniVerse additionally honours a record named after the account, and prefers it. LOGIN is the one spelling those systems share, which is why it is the one MVX uses.

SELECT leaves its list for the next command:

> SELECT PARTS WITH COLOR = blue
2 record(s) selected
> LIST PARTS NAME PRICE          only the selected records

The list is consumed exactly once. Inside a program, EXECUTE "SELECT ..." followed by READNEXT uses the same mechanism.

Add DESCRIBE (or EXPLAIN) to LIST, SORT, SELECT, or SSELECT and the verb prints the plan the backend would use without running the query. The word can go right after the verb (LIST DESCRIBE …) or at the end of the sentence — either way it does the same thing. On a SQL backend the plan is the SQL text the push-down would issue, so you can see exactly what work moves server-side:

> LIST DESCRIBE CUST STATE WITH STATE = "VIC" AND PRICE > "500"
postgres: SELECT id FROM "acct"."CUST" WHERE "STATE" = 'VIC'
  AND NULLIF("acct".mvx_attr(rec,3),'')::numeric > '500'::numeric

> SORT ORDERS BY TOTAL FIRST 10 EXPLAIN
postgres: SELECT id FROM "acct"."ORDERS" ORDER BY "TOTAL" LIMIT 10

The plan follows the same push-down rules the query itself would: a mapped identity column is compared as a column, an unmapped or converted field through the record blob (mvx_attr), and a numeric range as a numeric comparison. When a condition can't be pushed (an @ID filter, a TRANS() join to another backend, a text range) the plan says so and notes that the verb applies it while scanning:

> LIST CUST WITH @ID = "C1000" DESCRIBE
postgres: SELECT id FROM "acct"."CUST"; 1 condition(s) applied in the verb

The description is backend-specific: a store with no server-side query planner (the local LMDB and directory backends) reports that the driver returns the id list — an index lookup when one exists, otherwise a sequential scan — and the verb applies the conditions and ordering. A future document backend would render its own native query the same way.

The classic line editor: ED FILE ID.

Every spawn — !, SH, EXECUTE, and the compiler — passes through one gate in the runtime, controlled by $MVXPRIV:

The check lives in the runtime because anyone who can compile could call the primitives directly — a shell-only check would be decorative.