Guardian Programmer's Guide

Writing a Command-Interpreter Monitor ($CMON)
Guardian Programmer’s Guide — 421922-014
23 - 27
Controlling $CMON While the System Is Running
The $CMON process must respond to a Deluser^msg message with a Deluser^reply
structure; the reply code must be 0 to allow the deletion or 1 to reject the deletion. The
reply may also contain display text.
The format of the Deluser^reply structure is as follows:
The following code fragment rejects any attempt to delete a user except by a
super-group user (255, n):
CALL READUPDATEX(RECV^NUM,SBUFFER,RCOUNT,BYTES^READ);
IF BUFFER[0] = -55 THEN
BEGIN
REQUESTING^GROUP^ID := DELUSER^MSG.USERID.<0:7>;
IF REQUESTING^GROUP^ID = 255
THEN DELUSER^REPLY.REPLY^CODE := 0
ELSE DELUSER^REPLY.REPLY^CODE := 1;
REPLY^LEN := 2;
CALL REPLYX(DELUSER^REPLY,REPLY^LEN);
END;
Controlling $CMON While the System Is
Running
So far this section has discussed how $CMON provides static control over requests
made by TACL process. However, you can write your $CMON program to permit run-
time control over the way it responds to these messages. That is, instead of having
responses hard coded into the $CMON process, the operator can supply or change
response values at run time.
Any control that can be hard coded into $CMON can also be applied at run time. For
example, your $CMON process might allow the operator to:
• Change the text displayed when logging on. For example, the operator may want
to include some changing system-status information.
• Specify that only commands from operators are accepted. For example, the
operator may want to forbid requests from users while preparing to shut down the
system; requests from the operator, however, still need to be allowed.
Format of Deluser^reply structure:
STRUCT DELUSER^REPLY;
BEGIN
INT REPLYCODE; ![0] if 0, allows the deletion;
! if 1, rejects the deletion
STRING REPLYTEXT[0:n]; ![1] optional display text;
! maximum length is 132 bytes
END;