Customizing how users send and retrieve messages

Users issue the SEND command to send messages to other users, the operator, or to a specific operator or operator console. Users who are authorized to use the OPERATOR command can issue the SEND subcommand of the OPERATOR command to send messages. Users issue the LISTBC command to retrieve messages that other users have sent.

Before users at your installation can use SEND and LISTBC, you must add the commands to the table of authorized commands. For more information, see Specifying authorized commands/programs, and commands not supported in the background.

You give users authorization to use the OPERATOR command when you define them to either the user attributes data set (UADS) or the RACF® data base. For more information about the UADS and RACF data base, see Maintaining the UADS, RACF data base, and broadcast data set.

By default, the SEND command processor and the OPERATOR SEND subcommand processor may store a message in the mail section of the broadcast data set depending on the operands the user specifies. For example, a user can specify that SEND or OPERATOR SEND store the message if a target user is not logged on. Authorized users of the OPERATOR command can also issue the SEND subcommand to send notices. Notices are messages that are intended for all users on the system. The OPERATOR SEND subcommand processor stores notices in the notices section of the broadcast data set.

By default, when a user issues the LISTBC command to retrieve a stored message, LISTBC retrieves the message from the mail section of the broadcast data set. For more information about SEND and LISTBC, see . For more information about the SEND subcommand of OPERATOR, see .

You can customize how users send, store, and retrieve messages (mail) at your installation. You can define installation defaults in SYS1.PARMLIB member IKJTSOxx to tailor SEND, OPERATOR SEND, and LISTBC processing. Using IKJTSOxx, you can prevent all users from using the SEND command. You can also prevent users who are authorized to use the OPERATOR command from using the SEND subcommand. You can also write exits to restrict certain users from using SEND, OPERATOR SEND, or LISTBC.

You can define console names for the MCS consoles at your installation using SYS1.PARMLIB member CONSOLxx. Users can then specify the console name instead of the console ID when sending messages to an operator console. Console names are generally easier to remember and use than console IDs. For more information about defining console names, refer to .

Note: The names for extended MCS consoles are dynamically defined during console activation. Installations do not need to define names for extended MCS consoles. If you have RACF installed, your installation can control which users can send messages to other users. To control the use of the SEND command in this way, use the RACF security resource class SMESSAGE. For example, a user may send messages to another user only if permitted to the receiving user's resource within the SMESSAGE class. For information about setting up the SMESSAGE resource class, see .

Because SEND, OPERATOR SEND, and LISTBC access the broadcast data set to store and retrieve messages, you may experience contention for the data set. Instead of storing messages (mail) in the broadcast data set, you can use individual user logs to store the messages. A user log is a data set that the SEND command or subcommand processor uses to store messages in rather than storing the messages in the broadcast data set. Using user logs may reduce possible contention for the broadcast data set.

Protection of messages from users at different security labels is another reason for using individual user logs. If you have RACF installed, and your installation is using security labels, you can customize the TSO/E SEND and LISTBC commands by setting some of the operand values of the SEND PARMLIB parameter to determine security checking of the individual user logs. This is explained in the operand descriptions in this chapter.

If you use user logs, LISTBC retrieves messages from the user log. However, OPERATOR SEND continues to store notices in the notices section of the broadcast data set and LISTBC retrieves notices from the broadcast data set.

You can use various SEND, OPERATOR SEND, and LISTBC exits to customize command processing and the use of user logs. Using the exits, you can:

Restrict certain users from using the command
Change the operands users specify on the command
Encrypt and decrypt messages
Format messages or add information to messages that are stored
Allocate user logs instead of having the LISTBC command processor allocate them

Note: The EDIT and TEST commands have a SEND subcommand that operates the same as the SEND command. The TEST command also has a LISTBC subcommand that operates the same as the LISTBC command. The customization tasks for the SEND and LISTBC commands that this chapter describes also affect the SEND subcommands of EDIT and TEST and the LISTBC subcommand of TEST.

Unless otherwise indicated, when this chapter refers to the SEND command or SEND messages, the information applies to both SEND and OPERATOR SEND.

This chapter describes the different ways you can customize SEND, OPERATOR SEND, and LISTBC processing by:

Defining installation defaults in SYS1.PARMLIB member IKJTSOxx
Storing SEND messages in individual user logs
Writing SEND, OPERATOR SEND, and LISTBC exits to tailor how users send and retrieve messages. Using the exits, you can change the installation defaults you define in IKJTSOxx and tailor the use of user logs.