16B GetTerminalType¶
Validated MON 16B (14 decimal) · Mnemonic MGTTY · Group: Monitor Calls for Terminal Handling (manual section 2.6)
Available from: All programs (manual compatibility box)
Emulation source: src/handlers/mon_16B_GetTerminalType.c
Description¶
Gets the terminal type. The terminal type tells SINTRAN III how to handle a particular terminal. A wrong terminal type normally distorts the screen. The function-keys cannot be used.
- Appendix H lists the terminal types.
Parameters¶
| Name | Type | Direction | Description |
|---|---|---|---|
DeviceNumber |
INTEGER2 | In | The logical device number of the terminal. Use 1 for your own terminal in background programs. You may specify TADs. |
TerminalType |
INTEGER2 | Out | The terminal type (output). See appendix H for terminal types. |
Direction: In = the program supplies the value, Out = the call returns it, In/Out = both.
See also¶
SetTerminalType, and @GET-TERMINAL-TYPE
Compatibility¶
| Machines | Users | Programs |
|---|---|---|
| ND-100 and ND-500 | All users | All programs |
The manual's compatibility box for this call, word for word.
Yes/no fields from the YAML extraction (not in the manual's words):
| ND-100 | ND-500 | User programs | RT programs | System programs |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | No |
Examples¶
From the manual (OCR text, not corrected).
INTEGER : DeviceNumber, TerminalType
...
ON ROUTINEERROR DO
IF ErrCode > 0 THEN ...
ENDON
Monitor_Call('GetTerminalType', DeviceNumber, TerminalType)
INTEGER DeviceNumber, TerminalType
...
Monitor_Call('GetTerminalType', DeviceNumber, TerminalType)
IF (ErrCode .NE. 0) THEN ...
DeviceNumber, TerminalType : INTEGER2;
...
GetTerminalType(DeviceNumber, TerminalType);
IF ErrCode <> 0 THEN ...
01 DeviceNumber COMP.
01 TerminalType COMP.
01 ErrCode COMP.
...
MONITOR-CALL "GetTerminalType" USING DeviceNumber, TerminalType.
CALL "CbError" USING ErrCode.
IF ErrCode NOT = 0 GO ...
DeviceNumber : W BLOCK 1
TerminalType : W BLOCK 1
ErrCode : W BLOCK 1
GetTerminalType : EQU 37B9 + 16B
...
CALLG GetTerminalType, 2, DeviceNumber, TerminalType
IF K GO ERROR
...
ERROR : W1 =: ErrCode %ErrorCode in W1 register.
LDT DEVNO %Logical device number, must be a terminal.
MON 16 %Monitor call GetTerminalType.
JMP ERROR %Error return from monitor call.
STA TYPE %Normal return, store terminal type number.
...
ERROR, ... %Error number in register A.
...
DEVNO, ...
TYPE, 0
ndmonlib implementation¶
Validated Registered MON_STATUS_VALIDATED in src/core/mon_registry.c: implemented, tested and working.
| Handler | mon_16B_GetTerminalType |
| Code lines | 31 (non-blank, non-comment lines in the file) |
Notes from the handler source¶
src/handlers/mon_16B_GetTerminalType.c line 19
Terminal type is SINTRAN STATE, not a constant.
On a real system it lives in SINTRAN's per-terminal datafield and is set with
the @SET-TERMINAL-TYPE command; 16B MGTTY only REPORTS it. 17B MSTTY and
336B function 101B write it.
0 means NOT SET, and a program that needs VTM then ASKS the user:
Terminal type 000 is unknown.
Available terminal types are: ...
What is your terminal type?
That is CORRECT SINTRAN behaviour, not a defect - do not "fix" it by inventing
a type in this handler.
The emulator has no @SET-TERMINAL-TYPE yet (that belongs with the command
dispatcher, plan PART II phase 10), so the startup default comes from
ND500X_TERMINAL_TYPE, defaulting to 6. This is an emulator CHOICE, in the same
class as the pinned clock - it stands in for the @SET-TERMINAL-TYPE a real
operator would have run. Set ND500X_TERMINAL_TYPE=0 for authentic
"unset - ask me" behaviour.
Why 6 (DEC VT100, 80 columns) as the default:
- The console bytes reach a real host terminal, and host terminal emulators
speak VT100.
- The linker's own table, DDBTABLES-G06:VTM (extracted from vendor floppy
ND-disk-00047.img), lists "6: DEC VT100 (80 columns)" in the menu it
prints, so 6 is valid for the table we load.
- CAVEAT: the type list DIFFERS BETWEEN DDBTABLES VARIANTS. G06 lists
6/131/132/134/135; another observed variant jumps 3 -> 11 with no type 6.
Type 2 ("Teletype ASR 33") appears in every variant seen.
- The type->meaning mapping is NOT from a manual: Appendix H is not in the
scanned document set. It is read from the DDBTABLES menu only.
When the telnet server lands (plan PART II phase 9.3) this default should come
from the client's negotiated TERMINAL-TYPE instead of an env var.
src/handlers/mon_16B_GetTerminalType.c line 74
Device 0 means "own terminal" for a background program; device 1 is the
console (ND-860228.2 EN p505 notes).
src/handlers/mon_16B_GetTerminalType.c line 78
First read for a device adopts the startup default, standing in for the
@SET-TERMINAL-TYPE an operator would have run. Once anything has SET the
type (17B MSTTY, 336B 101B), that value wins and round-trips.
Emulation research¶
Source
This section comes from the emulation: block of the call's YAML file in the NDInsight repo. It records what was learned while implementing the call in nd500x; its status is nd500x's, not ndmonlib's.
| Status (nd500x) | stub |
| nd500x handler | nd500x/src/libmon/handlers/mon_16B_GetTerminalType.c |
| Last updated | 2026-07-17 |
Stub behaviour¶
RETURNS A CONSTANT - SAY SO. 16B MGTTY always reports terminal type 0 and never consults DeviceNumber. There is no per-device terminal-type state in nd500x: 17B MSTTY accepts and discards the type, so a set-then-get round trip does NOT read back what was set.
Parameter notes¶
| Name | Note | Verified |
|---|---|---|
| TerminalType | Written as a 32-bit word (ND-500 INTEGER = W), not a halfword, despite the manual typing it INTEGER2. | Yes |
| DeviceNumber | Read for logging only; the returned type does not depend on it. | Yes |
Observed calls¶
| Caller | Expectation | Note |
|---|---|---|
| ND linker (linker-b01.dom), startup | Called during linker startup terminal configuration. Type 0 is accepted and the linker proceeds. | Before this handler existed the auto-generated stub returned error -1 and the linker crashed in startup device configuration. Commit 940ba39. |
Return contract¶
- Success: K flag cleared; TerminalType written to the OUT parameter.
-
Errors
Code Octal Meaning 111 157B Missing parameter (fewer than 2 CALLG args)
Verified¶
| Claim | Evidence |
|---|---|
| The linker proceeds past its startup with terminal type 0. | Commit 940ba39: "16B MGTTY (GetTerminalType): returns generic terminal type 0." |
Unverified¶
- THAT 0 IS THE RIGHT ANSWER. The choice is INFERRED, not read: the handler comment reasons that Appendix H type 0 means "an ordinary/undefined terminal, the safe generic answer for an emulated console". Appendix H is NOT in the scanned set we hold, so the meaning of type 0 is NOT confirmed from a primary source. The only positive evidence is that the linker accepts it.
- THE CARVE WAS NOT MINED FOR THIS ENTRY. A carve folder exists at .../L-VSX-500/re/mon-analysis/16B-GetTerminalType/ and has not been read in.
- What real MGTTY returns for a device that is not a terminal is unknown; nd500x returns 0 for any DeviceNumber.
Sources¶
| Doc | Note |
|---|---|
| SINTRAN III Monitor Calls (ND-860228.2 EN) | The manual body of this YAML. It defers the type list to Appendix H, which we do not hold. |
Updates 2026 07 17¶
1. Terminal type is SINTRAN state (round-trips with 17B/336B 101B)
| Field | Value |
|---|---|
| Status | verified |
| Detail | The terminal type lives in SINTRAN's per-terminal datafield, set by @SET-TERMINAL-TYPE (and MON 17B MSTTY / 336B function 101B); 16B MGTTY only REPORTS it. Type 0 means NOT SET - a program that needs VTM then ASKS the user ("Terminal type 000 is unknown. / What is your terminal type?"), which is CORRECT behaviour, not a fault. nd500x models it as per-device state; the startup default stands in for @SET-TERMINAL-TYPE (ND500X_TERMINAL_TYPE, default 6 = DEC VT100). The type numbers are read from the DDBTABLES:VTM menu, NOT a manual (Appendix H not in the scanned set), and DIFFER between DDBTABLES variants. |
| Nd500x commits | 558ecc6, c87c8d0 |
Source¶
SINTRAN III Monitor Calls (ND-860228.2 EN), page 291.