Two areas must be taken into consideration if system messages are to be created and output efficiently in BS2000:
message management
All the messages which could be needed while the BS2000 system is in use are stored in a number of ISAM files. Message files which are essential for the system run and ones which have been specified by means of parameters are made available at startup (system parameters MSGFILii and MSGNOFL, see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ"). Further message files can be specified in the MIP parameter file (SYSPAR.MIP.<version>). However, they are enabled only after the MIP subsystem has been loaded. Further message files may be added or removed during the session. See the “Introduction to System Administration” [10 (Related publications)].
System-internal message handling
Each message file created with the utility routine MSGMAKER contains the message text and a number of attributes (for searching for the message text) as well as the meaning and the response text (for /HELP-MSG-INFORMATION).
When the system is being set up, the files is opened and the management section is read into a work area in class 4 memory.
If users make requests for system messages to be output in the course of processing, the following actions are taken when handling these message outputs:
on the basis of the accompanying message code, a check is made as to whether the message is already in the message buffer or whether it needs to be read using the ISAM access GETKY
on the basis of the weight code, a check is made as to whether this message is to be output on the output medium console or whether it is to be suppressed
variable sections of the text are updated and output is initiated (if suppression has not been specified). At least one change of task is necessary for this.
Output media can be any of the following:
the main console and/or the subconsole
and/or SYSOUT/SYSLST of the user task
and/or a user area (buffer)
Every request for output of a message to the master console and/or subconsole (even if output is to be suppressed) is also written as a record to the CONSLOG file.
Saving message files
Message files which are only required for special applications should not be placed on the home pubset disks (where they merely occupy space unnecessarily), but rather on the pubset belonging to the particular application. For current requirements, disks can be attached with /IMPORT-PUBSET or the files can be restored from backup data (e.g. using HSMS). The message files are then transferred into the active system using /MODIFY-MSG-FILE-ASSIGNMENT or /MODIFY-MIP-PARAMETERS.
Individual messages (or the contents of complete message files) are integrated into the message files required for the session.
Number of message files
The messages of special software products can remain in the software product's message file. They are automatically installed with IMON.
The number of message files managed as an integral part of the overall system, and which of these should be made available in which session and perhaps removed after they are no longer needed, is left to the discretion of systems support.
Suggestions for limiting or speeding up the output of system messages
Suppression of certain system messages
Preparing, updating and outputting messages is necessary for the system to run properly, but also simultaneously increases its workload. The way in which messages are handled should be tailored to the particular requirement. For example, the request to output a message can be revoked if the loading of a program (/START-EXECUTABLE-PROGRAM) has no relevance for the operator's activities and no log of the event is evaluated (set system parameter EACTETYP to 0, see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ").
If different applications are processed sequentially during data processing, the number of outputs to the consoles which are to be suppressed should be chosen to suit each individual application.
This means that:
All messages which need to be handled differently with regard to output suppression are given different weight codes in the message files. /ADD-CONSOLE-FILTER is used to set the filter level most suitable for each individual type of workload. Productive use, program development, test operation, diagnosis following faults or after version changeover etc. and any mixture of these are all different types of workload.
An alternative method for suppressing output on the basis of the weight code is to use the message subscription or message suppression function (/MODIFY-MSG-SUBSCRIPTION, /SET-MSG-SUPPRESSION). This makes it possible for a message-receiving entity to subscribe to or suppress individual messages. Both possibilities can also be used in combination:
First you roughly define the message set by allocating routing codes and specifying weight codes.
Then you carry out the fine-tuning via subscription/suppression.
Selective output of system messages
The following applies to the assignment of routing codes (parameter service, statement SET-CODE):
With the appropriate routing codes, consoles can receive operating messages.
The passing of messages is performed by a system-internal communication mechanism (with the aid of bourses) and incurs a noticeable system overhead.
When assigning the routing codes, you should always check which messages or commands must be available on the consoles, so as to avoid superfluous messages by restricting assignment.
The message delivery can be optimized by means of the message
subscription/suppression mechanism.
Speeding up message output with DLAM (Dynamic Loadable Access Method)
Systems administration can set the DLAM flag for any message.These flags are stored in the directory of each message file. At startup, the directory of all message files which, according to the start parameters, should be available at “system ready” (system parameter MSGFILii, see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ") is evaluated and placed in the range assignment lists (in the message handler tables). Following this, all messages with the DLAM flag are read from the appropriate files.
(MSGMAKER utility routine, statement/mask: ADD-MSG and MODIFY-MSG)Advantage
The address space requirements for buffered message texts do not change during the system run (static format from startup). The path lengths are shortened if DLAM flags are set as it is then no longer necessary to check whether a message text which is currently required is already buffered. The physical I/O operation is brought forward from the system run to the startup phase.
Messages are created in class 5 memory at startup. No physical I/O operations are executed when a message is called during the system run.
Effort
Selecting and flagging the individual messages takes up expensive processing time. The use of DLAM is recommended on large servers with a high throughput rate.
Speeding up message output with LOCAL-DLAM (Local Dynamic Loadable Access Method)
If a message has the access method LOCAL-DLAM (assigned with the MSGMAKER utility routine), it is copied into class 4 memory at activation.
Advantage
As with access with DLAM, no physical input/output is necessary. In addition, there is no access to the central MIP task - all actions are executed under the job-source task. This not only reduces the system overhead, but also prevents possible lock situations between the central MIP task and other job-source tasks.
Speeding up the message output using the system parameters MSGCENTL and MSGCENTN (see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ")
MSGCENTL defines the maximum length of messages and MSGCENTN the number of messages which can be buffered in class 4 memory in order to reduce the number of file accesses.
The amount G of class 4 memory required is calculated as follows:
G = MSGCENTL * MSGCENTN [Byte]