MULTICS TECHNICAL BULLETIN MTB747-05
To: MTB Distribution
From: Edward C. Brunelle
Date: May 7, 1987
Subject: New warn software
-----------------------------------
This MTB describes a set of proposed Answering Service and user
changes to improve the operation of blast messages (the operator
"warn" command) and the bump-for-inactivity feature of Multics.
These changes are required because of interference between the
current warn facility and the video system and the fact that the
current warn facility does not work with DSA connections.
The warn facility changes, in turn, makes it necessary to
consider changes to the Answering Service to allow the
bump-for-inactivity feature that logs users out for inactivity to
continue unaffected.
Revision 4 is a major change and there are no change bars All of
the proposed inactivity mechanism documentation has been removed
since it is no longer required.
Revision 5 is for the change in philosophy for the output of the |
warning message to the user. Instead of trying to use the |
message_facility to output the message, the system message will |
always be displayed directly on the user_i/o switch.
|
----------------------------------- |
|
Comments should be sent to the author: |
|
via Multics Forum: |
>udd>dsa>meetings>dsaimp.forum |
via Multics Mail: |
Brunelle -at System-M |
|
via Telephone: |
(HVN) 862-3595, or (602) 862-3595 |
_________________________________________________________________
Multics project internal documentation; not to be reproduced or
distributed outside the Multics project without permission of the
Director of MDC.
MTB747-05 New warn software & inactivity handling
|
|
|
|
|
|
|
| CONTENTS
|
|
| Page
|
| 1: Introduction . . . . . . . . . . . . . . . . . . . . . 1
| 2: Blast Mechanism . . . . . . . . . . . . . . . . . . . . 2
| 2.1: Current blast mechanism . . . . . . . . . . . . . . . 2
| 2.2: Proposed blast mechanism . . . . . . . . . . . . . . 2
| 2.2.1: Sending the message . . . . . . . . . . . . . . . . 2
| 2.2.2: Receiving the message . . . . . . . . . . . . . . . 3
2.3: The EOP Problem . . . . . . . . . . . . . . . . . . . 4
3: Inactivity problem . . . . . . . . . . . . . . . . . . 5
3.1: Current inactivity mechanism . . . . . . . . . . . . 5
3.2: Problems with this mechanism . . . . . . . . . . . . 5
3.3: Problem resolution . . . . . . . . . . . . . . . . . 6
3.4: New inactivity event message . . . . . . . . . . . . 6
Appendix A: Documentation . . . . . . . . . . . . . . . . 8
send_system_message_ . . . . . . . . . . . . . . . . . . 9
system_message_handler_ . . . . . . . . . . . . . . . . 12
New warn software & inactivity handling MTB747-05
1: INTRODUCTION
The chain of reasoning that led to this proposal is as follows:
1. Blast messages currently do not work properly with the video
system. They write output directly to the user's terminal
I/O channel without regard for its current state. They also
do not work over Multics Network Architecture (MNA)
channels. Compatibility with video system and MNA requires
cooperation on the part of the recipient's process.
2. The bump-for-inactivity warning on the user's terminal is a
form of blast message. If the user's process participates
in receiving and printing the message, the act of responding
to an inactivity warning will in itself cause the process to
be active once again and the bump will automatically be
cancelled.
This MTB describes
o a new mechanism for blast messages, one that operates for
DSA channels and with the video system,
o and a new mechanism for inactivity timeouts that continues
the current practice of using the Answering Service's
evaluation of whether a process is active yet allows the
Answering Service to get around the problem of the
inactivity blast message response altering the activity
state of the process.
MTB747-05 New warn software & inactivity handling
2: BLAST MECHANISM
The blast mechanism is a means in which the Answering Service
sends a message to one or more users on the system. These
messages may be operator initiated (generated by the "blast"
command), or system initiated (generated by the inactivity
mechanism).
2.1: Current blast mechanism
Currently, the Answering Service gets the recipient's channel id
from the User Table Entry (UTE) in one of its system tables
(answer_table, absentee_user_table or daemon_user_table) and
writes output directly on that channel via hcs_$tty_force. As
mentioned above, there are two problems associated with this:
o It destroys the user's terminal display.
o For a user logged in through MNA (specifically DSA), there
is no physical channel to use for the hcs_$tty_force. Thus
the user would get none of these messages.
2.2: Proposed blast mechanism
The proposed method instead sends a message via the User Message
Facility (user_message_), accompanied by a new IPS signal named
system_message_. The recipient's process handles this signal by
calling user_message_ to read the message and then outputting the
text on the terminal.
Two new subroutines will be added to the system. On the sender
side (in this case, Initializer.SysDaemon), the subroutine
send_system_message_ sends the message and the IPS wakeup. On
the receiver side, system_message_handler_ handles the
system_message_ condition. Both programs are documented in
Appendix A.
2.2.1: SENDING THE MESSAGE
The caller of send_system_message_ passes a pointer to the new
structure system_message, declared in the new include file
system_message.incl.pl1. One element of this structure is a
type, which may be SYSTEM_MESSAGE_TYPE_AS_WARN or
SYSTEM_MESSAGE_TYPE_AS_INACTIVITY for this application but can
specify other types if send_system_message_ is ever used for
other applications requiring system messages to be sent to users.
For example, the facility is appropriate for Data Management
shutdown warnings.
New warn software & inactivity handling MTB747-05
The send_system_message_ subroutine calls
as_user_message_$priv_add_message to add the message to the User
Message database and then calls hphcs_$ips_wakeup to send the
system_message_ signal to the recipient.
2.2.2: RECEIVING THE MESSAGE
Processes will now have an additional static handler for
system_message_ that calls system_message_handler_. This static
handler is established by initialize_process_ for user processes
and by sc_init_ for the Initializer process.
The system_message_handler_ subroutine calls
user_message_$read_message repeatedly to read all messages in the
User Message database that are addressed to the user. It will
output the text portion of each message to the users terminal |
through the user_i/o switch.
It was originally proposed to use the message_facility_ to |
display the message text to the user but this had to be changed |
due to the following problems: |
o If more than one user was listening to the mailbox, only the |
latest user would get the message. If that user was not the |
idle user, the message would never be seen. |
o There was no simple way to make sure the message was |
displayed before the user went blocked. Normally, the |
message facility only becomes active when the user is |
blocked. In our case, it was required that the message be |
displayed immediately to support the inactivity part of this |
proposal.
The system_message_handler_ subroutine is designed to potentially
handle other types of system message besides blast and inactivity
blast messages. It currently recognizes three types, inactivity
blast messages, blast messages and Data Management shutdown
warnings. (The latter type is reserved for future use when Data
Management is changed to call send_system_message_.) The type
indicator is included in the event message.
As it does currently, the Answering Service will continue to
format blast messages using the ioa_ control string
as_error_table_$warn_msg:
******** <DATE-TIME>
From Operator: <TEXT>
********
MTB747-05 New warn software & inactivity handling
2.3: The EOP Problem
There is an additional problem caused by the change to use a
conventional call to iox_ rather than hcs_$tty_force to print
blast messages: User processes running under the video system
will no longer see system messages when stopped at the "More?"
prompt.
This problem already exists for non-video processes. Output fed
to ring-0 tty_ (even by hphcs_$tty_write_force) cannot appear on
the terminal while ring 0's output buffer still contains some
pending characters. If ring 0 is interrupted at an End of Page
(EOP) break, it cannot print the rest of its buffer until the
user hits RETURN in response to the EOP break. Therefore, a
blast message cannot appear on the terminal until some time after
the user responds to EOP by hitting RETURN.
When a process using video is stopped at a "More?" prompt, it is
stopped inside the video system. The ring-0 output buffer is
empty. Therefore, the call to hphcs_$tty_write_force is able to
write the message immediately on the terminal; and it does,
splattering it all over the screen.
Once blast messages are changed to use send_system_message_,
video processes will no longer print them when stopped at "More?"
prompts. Blast messages will also continue to not work at EOP
breaks in non-video processes.
To restore correct operation for video processes, the
system_message_handler_ can make explicit calls to window_io_ to
print the incoming message followed by another "More?" prompt.
This change should be contingent upon deciding whether it is
worthwhile to fix the video case when the non-video case would
require extensive tty_ changes in order to work correctly. The
problem will not be resolved in this MTB.
New warn software & inactivity handling MTB747-05
3: INACTIVITY PROBLEM
The inactivity mechanism is a means by which the system can purge
itself of users which have had no activity during a site-settable
time period. This purging accomplishes two goals:
o It potentially saves users from incurring excessive
connection charges.
o It frees up resources on the system for currently active
users.
3.1: Current inactivity mechanism
The current inactivity mechanism has the Answering Service
perform a check on each process as part of its accounting update
cycle which occurs at a site-definable interval (update_time in
installation_parms, normally set to 15 minutes). It calls
hphcs_$process_status to obtain the time that the process last
called pxss$block.
If this time is earlier than the current time by more than a
certain default increment (inactive_time in installation_parms,
normally set to 60 minutes), the Answering Service warns the
process of its inactivity by calling astty_$tty_force to write a
message directly on the process' I/O channel. It also sets a
timer to go off after a site-definable interval (warning_time in
installation_parms, normally set to 5 minutes).
When the timer goes off, Answering Service checks to see if the
user has had any new activity. If not, the Answering Service
logs the process out.
3.2: Problems with this mechanism
Since using a process' I/O channel directly interferes with the
video system and MNA connected processes have no direct I/O
channel, inactivity warnings will now be sent by calling the new
send_system_message_. This change alone, however, breaks the
inactivity mechanism because the receiving process must wake up
to respond to the system message and this new activity cancels
the bump. This problem will be solved by a change in how process
inactivity is detected.
MTB747-05 New warn software & inactivity handling
3.3: Problem resolution
The solution to this dilemma is cooperation between the
system_message_handler_ and Answering Service.
A new message type will be defined for the handler:
SYSTEM_MESSAGE_TYPE_AS_INACTIVITY. The handler will special case
| this type of message by doing the following before completing
* it's activities:
o the handler will send an "inacrcvd" event message back to
the Initializer using the process' termination event channel
stored in the PIT to let it know that the user has received
all messages.
When the Initializer receives this "inacrcvd" event message, it
will cancel the current timeout scheduled to check for activity.
A new timer will be set for installation_parms.warning_time from
the time the "inacrcvd" event message was received from the user.
If no "inacrcvd" event message is received from the user, the
original timer will be used.
When the warning_time timer goes off, the Initializer will check
for any process activity which has occurred. If none is found,
the process will be bumped.
This way, the inactivity check timer will be based on the time
after the system message was processed and ignore that time used
by processing the system message. In the worst case, this will
do nothing more than leave extra inactive users on the system.
In addition, the Initializer will be changed in the code used to
check if the process can be unbumped. Currently it compares the
block state time of the process to the value of inactive_time.
It will be changed to use warning_time.
The inactivity mechanism will operate as currently implemented
for disconnected processes, and absentee and daemon users. If a
disconnected process is sent an inactivity warning and the
process is not reconnected before the warning_time grace period
expires, the process is bumped. Absentees are bumped if inactive
for more than inactive_time with no warning_time grace period.
Daemons are not bumped for inactivity.
3.4: New inactivity event message
We are defining a new user event message for the inactivity
received event message. It is "inacrcvd" (as_data_$signal_types
#12).
New warn software & inactivity handling MTB747-05
For the record, up to 19 user event messages can be defined.
Events 1-11 are currently used, 12-14 are used but defined as
obsolete and 15-19 are free. *
MTB747-05 New warn software & inactivity handling
APPENDIX A: DOCUMENTATION
The following pages document the new system message subroutines.
____________________ ____________________
send_system_message_ send_system_message_
____________________ ____________________
NAME: SEND_SYSTEM_MESSAGE_
ENTRY: SEND_SYSTEM_MESSAGE_$SEND_SYSTEM_MESSAGE_
This entry point, which requires access to hphcs_, sends a
message to a specified process accompanied by the system_message_
IPS signal. Processes have a static handler for system_message_
that invokes system_message_handler_.
USAGE
dcl send_system_message_ entry (bit (36) aligned, fixed bin, ptr,
fixed bin (35));
call send_system_message_ (recipient_process_id,
recipient_initial_ring, message_ptr, code);
ARGUMENTS
recipient_process_id
is the process id of the recipient. (Input)
recipient_initial_ring
is the initial (login) ring number of the recipient process.
(Input)
message_ptr
is a pointer to an allocated copy of one of the structures
warn_system_message, inactivity_system_message or
dm_shut_system_message, declared in the include file
system_message.incl.pl1. Operator warn messages use
warn_system_message and set the type field equal to
SYSTEM_MESSAGE_TYPE_AS_WARN. Inactivity messages use
inactivity_system_message and set the type field equal to
SYSTEM_MESSAGE_TYPE_AS_INACTIVITY. The other structure is
available for future use by Data Management. (Input)
____________________ ____________________
send_system_message_ send_system_message_
____________________ ____________________
NOTES
The structures for warn messages are as follows:
dcl 1 system_message_header aligned based,
2 version char (8),
2 type fixed bin,
2 type_version char (8);
dcl 1 warn_system_message aligned based,
2 header aligned like system_message_header,
2 caller char (64),
2 text_len fixed bin (21),
2 text char (system_message_text_len
refer (warn_system_message.text_len));
dcl 1 inactivy_system_message aligned based,
2 header aligned like system_message_header,
2 caller char (64),
2 text_len fixed bin (21),
2 text char (system_message_text_len
refer (inactivy_system_message.text_len));
STRUCTURE ELEMENTS
version
is equal to SYSTEM_MESSAGE_VERSION_1.
type
is equal to SYSTEM_MESSAGE_TYPE_AS_WARN for the
warn_system_message and SYSTEM_MESSAGE_TYPE_AS_INACTIVITY for
the inactivity_system_message.
type_version
is equal to SYSTEM_MESSAGE_AS_WARN_V1 for the
warn_system_message and SYSTEM_MESSAGE_AS_INACTIVITY_V1 for
the inactivity_system_message.
caller
is the name of the caller, to be prefixed to the message text:
CALLER: TEXT
If caller is "", only the text is printed. This is common to
all system messages.
text_len
is the number of characters in the message text. This is
common to all system messages.
____________________ ____________________
send_system_message_ send_system_message_
____________________ ____________________
text
is the text of the message. This is common to all system
messages.
The inactivity message is merely another type of warn message.
It is defined as a unique type so that the message handler can
accurately determine that special action is required in response
to it.
_______________________ _______________________
system_message_handler_ system_message_handler_
_______________________ _______________________
NAME: SYSTEM_MESSAGE_HANDLER_
ENTRY: SYSTEM_MESSAGE_HANDLER_$SYSTEM_MESSAGE_HANDLER_
This subroutine handles the system_message_ condition by
outputting any previously unprocessed messages which have been
sent to the user by send_system_message_. Processes will have a
static handler that calls this subroutine.
USAGE
dcl system_message_handler_ entry ();
dcl sct_manager_$set entry (fixed bin, entry, fixed bin (35));
%include static_handlers;
call sct_manager_$set (system_message_sct_index,
system_message_handler_, code);
NOTES
* The system_message_handler_ will output the message to the user
| outputting the text portion of each message to the users terminal
directly through the user_i/o switch.
| The handler will special case any inactivity_system_messages by
| sending an "inacrcvd" event message back to the Initializer,
| using the process' termination event channel stored in the PIT,
| to let the Initializer know that the user has received all system
messages.