Guardian Programmer's Guide

Table Of Contents
Writing a Terminal Simulator
Guardian Programmer’s Guide 421922-014
24 - 13
Managing the BREAK Key
BEGIN
!Set device type to 6 and subtype to 30:
REPLY^TO^106.MESSAGE^NUMBER := -106;
REPLY^TO^106.DEVICE^TYPE := 6;
REPLY^TO^106.DEVICE^SUBTYPE := 30;
REPLY^TO^106.RESERVED[0] := -1;
REPLY^TO^106.RESERVED[1] := -1;
REPLY^TO^106.RESERVED[2] := -1;
REPLY^TO^106.RECORD^LEN := <configured record length for
terminal>
!Respond to the requester:
CALL REPLYX(REPLY^TO^106,$LEN(REPLY^TO^106));
END;
Managing the BREAK Key
A real terminal has a BREAK key that, when pressed, sends a Break-on-device
message to the requester that communicates with the terminal. The requester can
control BREAK handling as follows:
The requester can call SETMODE function 11 or SETPARAM function 3 to specify
the owner of the BREAK key. The owner of the BREAK key is the process that
receives the Break-on-device message when the terminal user presses the
BREAK key. The BREAK key can be owned by only one process.
The process that owns the BREAK key can call SETMODE function 12 to place a
terminal in BREAK mode or normal mode. When the terminal is in BREAK mode,
only a process that has BREAK access can communicate with the terminal. When
a terminal is in normal mode, any process that has the terminal open can
communicate with the terminal.
Typically, the BREAK key owner places the terminal in BREAK mode when it receives
a Break-on-device message.
When writing a terminal-simulation process, you must include the following logic to
m
anage the BREAK key:
The terminal-simulation process must know the current BREAK key owner.
The terminal-simulation process must communicate with other processes
depending on whether the terminal-simulation process is in BREAK mode or
normal mode.
The terminal-simulation process can send Break-on-device messages to requester
processes.
The following paragraphs discuss these topics.