z/OS system operations
To help you understand the z/OS environment operation, we present here an overview of the following:
•Operation goals
•Connecting consoles to a sysplex
•Multisystem consoles
•Consoles in a sysplex environment
•Message processing
•Message flow in a sysplex environment
•Command flow in a sysplex environment
•Console-related PARMLIB members
•System commands to display and change console characteristics
•Hardcopy log
•SYSLOG and OPERLOG
•msys for operations
5.1 Planning z/OS operations
Figure 5-1 z/OS operations
Planning z/OS operations
Operating a z/OS environment is complex and critical. The operation affects not only application performance and availability, but also the operating system itself. Because of its complexity, planning z/OS operation in a Parallel Sysplex is vital for application availability.
z/OS environment operations involves managing the following:
•Hardware such as processors and peripheral devices, including the consoles where the operators do their work
•Software such as the z/OS operating system, the job entry subsystem (JES), and subsystems like NetView that can control automated operations
•Applications that run on z/OS
Planning z/OS operations must take into account how operators use consoles to do their work and how you want to manage messages and commands. Because messages are also the basis of automated operations, understanding message processing in the z/OS system can help you to plan your automation tasks.
Planning z/OS operations also requires thinking about the particular needs of the installation, for example:
•The business goals
•Policies established by the installation to allow the installation to grow and handle work efficiently
z/OS operations goals
The goals vary from installation to installation, but they are important when planning z/OS operations. However, any installation might consider the following goals:
•Increasing system availability to meet system-level agreements (SLAs).
•Controlling operating activities and functions.
•Simplifying operators’ tasks - The complexity of operating z/OS has increased, and you need to think about the tasks and skills of your operators—how operators respond to messages at their consoles—and how you can reduce or simplify their actions. Also, you need to plan z/OS operator tasks in relation to any automation scripts currently implemented.
•Streamlining message flow and command processing - Planning z/OS operations for a system must take into account how operators use consoles to do their work and how you want to manage messages and commands. Because messages are also the basis of automated operations, understanding message processing in an z/OS system can help you plan z/OS automation. Consider how to manage messages and commands:
 – Operators need to respond to messages
 – Routing messages to operator consoles
 – Suppressing messages to help your operators manage
•A single system image allows the operator, for certain tasks, to interact with several images of a product as though they were one image. For example, the operator can issue a single command to all z/OS systems in the sysplex instead of repeating the command for each system.
•A single point of control allows the operator to interact with a suite of products from a single workstation, thereby reducing the number of consoles the operator has to manage.
Planning the operations environment
The z/OS environment at an installation can affect how you plan to meet your operations goals. Your z/OS operating environment might be a single z/OS system or a multisystem environment. Depending on the environment, operating z/OS can involve different approaches to your planning tasks. For example, planning console security for a multisystem environment requires more coordination than for a single z/OS system. But much of the planning you do for a single system can serve as the basis for planning z/OS operations in a multisystem environment.
5.2 Operating a z/OS environment
Figure 5-2 Operating a z/OS environment
Operating a z/OS environment
Controlling the operating system effectively involves operator tasks such as:
•Displaying current system status, such as the number of active jobs and teleprocessing functions, so you can take appropriate actions to operate the system efficiently and to correct potential problems.
•Displaying the status of devices and the availability of paths.
•Communicating among several consoles.
•Communicating within a sysplex. In a sysplex, several z/OS systems interact to process work.
•Setting the time and changing the system parameters.
•Using the system restart function to control certain system functions.
•Responding to messages.
•Activating a WLM service policy for a sysplex.
z/OS command structure
z/OS provides system and subsystem commands that display job and system status either when requested or continually at regular intervals. Other commands route status information to one or more consoles and provide communication among operators in a multiple-console environment, as well as communication with time-sharing users. Many commands let you display information about all the systems in a sysplex, and some commands allow you to control any target system in the sysplex.
5.3 z/OS console types
Figure 5-3 z/OS console types
z/OS console types
Figure 5-3 shows the four types of consoles:
MCS MCS consoles are devices that are locally attached to an z/OS system and provide the basic communication between operators and z/OS. MCS consoles are attached to control devices that do not support SNA protocols. You can define up to 99 consoles through the CONSOLxx PARMLIB member. In the past, MCS consoles were connected to non-SNA 3174 terminal controllers. Today MCS consoles are mostly PCs with TN3270E terminal emulation, which are connected to an IBM 2074 console support controller. If you have a z990 or a z890 and as a minimum z/OS R3 installed, you can use an OSA-Express 1000Base-T Ethernet adapter as an OSA integrated console controller. In this configuration you also use PCs with TN3270E terminal emulation.
SMCS SNA Multiple Console Support (SMCS) is a console that uses z/OS Communications Server to provide communication between operators and z/OS instead of direct I/O to the console device. It is implemented as a VTAM application. SMCS consoles can be real 3270-type devices, but usually they are 3270 emulators such as IBM Personal Communications software. Since this type of console uses VTAM for communication, it is not available as an NIP console.
EMCS Extended MCS (EMCS) consoles are programmable consoles defined and activated through an intended programming interface (the MCSOPER macro with REQUEST=ACTIVATE). The number of active EMCS consoles is not restricted. Programs that use EMCS consoles are the TSO/E CONSOLE command, SDSF (with JES2), (E)JES (with JES3), or user-written programs.
System Console integration is supported by z/OS and allows the hardware management console to support both hardware functions and the operating system IPL, recovery, and problem analysis. The system console in problem determination mode is automatically defined by z/OS during system initialization. The name of this type of console is SYSCONS.
 
Note: The system console function is provided as part of the Hardware Management Console (HMC). An operator can use the system console to initialize MVS and other system software, and during recovery situations when other consoles are unavailable.
5.4 IBM 2074 console support controller
Figure 5-4 IBM 2074 console support controller
One 2074 controller can replace up to 32 3174 non-SNA controllers
Since IBM no longer produces 3174 controllers and most of them were built with parallel channel attachments, there was a need for a new generation of console controllers. The IBM 2074 console support controller is the successor to the 3174s. It is based on an IBM Netfinity® PC in TN3270E mode, which fits into standard 19-inch racks. You are able to connect your consoles to 32 z/OS images over one 2074. That helps you save a lot of cabling in your data center.
 
Note: The 2074 controller is still supported but can no longer be ordered.
Up to two ESCON channel attachments
Channel attachments between the 2074 and the CPUs can be done in three ways:
•Switched ESCON
•Switched FICON bridge
•Non-switched ESCON
Ethernet or Token Ring LAN-attached consoles
With the IBM 2074 you have console PCs with Personal Communications running TN3270E emulation instead of 3278 terminals. These PCs connect via TCP/IP protocol to the 2074 controller.
Master console support for z/OS IPL
Because you need one master console for IPL in the sysplex, the 2074 delivers this support.
MCS console support for z/OS
MCS consoles are the devices normally used as console types. The IBM 2074 console support controller can also handle this type. You can find a description in 5.3, “z/OS console types” on page 241.
Minimum of two IBM 2074 controllers is recommended
From an availability point of view, we recommend that you install a minimum of two 2074 console support controllers. To eliminate single points of failure, they should also be configured with two ESCON ports.
Refer to Introducing the IBM 2074 Control Unit, SG24-5966 for more details.
5.5 2074 console support controller configuration
Figure 5-5 2074 configuration
2074 configuration
Figure 5-5 shows a configuration with multiple LPARs on two CECs. With the use of ESCON Multiple Image Facility (EMIF) you can share the 2074s between several LPARs. You can either connect the 2074 directly to the CPU or, as shown here, using ESCON directors. MCS consoles are attached to the 2074 via TCP/IP protocol and TN3270E terminal emulation. These consoles are PCs. Token Ring (4/16 Mb/sec) and Fast Ethernet (10/100 Mb/sec) are supported. The 2074 converts the TN3270E sessions so that they appear as local non-SNA terminals to the z/OS operating systems.
5.6 OSA integrated console controller
Figure 5-6 OSA integrated console controller
OSA integrated console controller
The OSA-Express Integrated Console Controller (OSA-ICC) support is a no-charge function included in Licensed Internal Code (LIC) on z9-109, z990, and z890 servers. It is available via the OSA-Express2 and OSA-Express 1000BASE-T Ethernet features, and supports Ethernet-attached TN3270E consoles.
The OSA-ICC provides a system console function at IPL time and operating systems support for multiple logical partitions. Console support can be used by z/OS, z/OS.e, z/VM, zVSE, and TPF. The OSA-ICC also supports local non-SNA DFT 3270 and 328x printer emulation for TSO/E, CICS, IMS, or any other 3270 application that communicates through VTAM.
With the OSA-Express2 and OSA-Express 1000BASE-T Ethernet features, the OSA-ICC is configured on a port-by-port basis, using Channel Path Identifier (CHPID) type OSC. Each port can support up to 120 console session connections, can be shared among logical partitions using Multiple Image Facility (MIF), and can be spanned across multiple Logical Channel Subsystems (LCSSs).
Figure 5-5 shows an example of the OSA-Express Integrated Console Controller in a single system configuration.
Refer to OSA-Express Integrated Console Controller Implementation Guide, SG24-6364 for more details.
5.7 Multisystem consoles in a sysplex
Figure 5-7 Multisystem consoles in a sysplex
MCS, SMCS, and EMCS consoles
Consoles can be active on any system in a sysplex and can provide sysplex-wide control. MCS uses XCF services for command and message transportation between systems and thus provides a single system image for the operators. Normal message presentation is controlled by a console’s ROUTCDE and MSCOPE settings, and the UD (undeliverable message) attribute.
MCS sysplex features
MCS multisystem support features:
•Sysplex-wide action message retention facility (AMRF)
•Sysplex-wide unique reply IDs
•Sysplex-wide command routing through:
 – ROUTE operator command
 – Command prefix facility (CPF)
 – CMDSYS setting for a console (through the CONSOLE statement in the CONSOLxx parmlib member or CONTROL V,CMDSYS= operator command)
SMCS consoles support most of the same functions that MCS consoles do. There are a few differences:
•Synchronous WTO/R, also known as Disabled Console Communication Facility (DCCF), is not supported for SMCS consoles. The system console (HMC) or an MCS console must be used instead.
•SMCS consoles are not available during NIP. The system console or an MCS console must be used instead.
•SMCS consoles require VTAM to be active. If VTAM is not active for any reason, then SMCS consoles will not be available. The system console and MCS consoles do not rely on VTAM, and these could be used instead.
•SMCS consoles must be activated differently than MCS consoles. The activation process depends on the console definitions, but in all cases, VARY CONSOLE and VARY CN,ONLINE do not work for SMCS.
•SMCS does not support output-only (message stream and status display) consoles. SMCS consoles must always be full-capability consoles. MCS supports output-only consoles.
•SMCS does not support printer consoles, and cannot be used as hardcopy devices. MCS supports printer consoles and hardcopy devices.
5.8 Sysplex operating environment
Figure 5-8 Sysplex operating environment
Sysplex operating environment
The sysplex operating environment provides a simpler and more flexible way to operate consoles in a multisystem environment. Many changes were introduced into multiple console support (MCS) to support the sysplex environment.
In a sysplex, MCS or SMCS consoles can:
•Be attached to any system
•Receive messages from any system in the sysplex
•Route commands to any system in the sysplex
Therefore, new considerations are necessary when defining MCS consoles in this environment, such as:
•There is no requirement that each system have consoles attached.
•The 99 console limit for the sysplex is extended with the use of extended MCS consoles (EMCS). This adds greater flexibility when attaching consoles.
•A sysplex, which can have up to 32 systems, can be operated from a single console.
•Multiple consoles can have master command authority.
With MCS consoles in a sysplex, no matter where they are attached, it is possible to control any system in the sysplex. The ability to assign each console a unique name and unique characteristics greatly eases the task of system management.
5.9 Support for multisystem management
Figure 5-9 Support for multisystem management
Support for multisystem management
In a sysplex, the major tasks of operating an individual z/OS image do not change very much. Consoles are used to receive messages and issue commands to accomplish system tasks. With the existence of multiple z/OS images and multiple subsystems, the potential exists for the operator to receive an enormous number of messages, since there is the capability to route all messages from all z/OS systems to a single console.
Single system image
A single system image allows the operator, for certain tasks, to interact with several images of a product as though they were one image. The operator can issue a single command to all z/OS systems in the sysplex instead of repeating the command for each system.
Single point of control
A single point of control allows an operator to interact with a suite of products from a single workstation. An operator can accomplish a set of tasks from a single workstation, thereby reducing the number of consoles the operator has to manage.
Base for applications to be sysplex aware
Multisystem consoles can be used by applications to be sysplex aware due to the fact that no matter on which system the applications exist, command routing and message routing can be done. The application does not have to exist on the same system as a console used to communicate with it.
5.10 Message processing
Figure 5-10 Message processing
Message processing and contents
When the z/OS system and any program running under the z/OS system require communication with operators, they issue messages. The z/OS write to operator (WTO) and the write to operator with reply (WTOR) macro services cause messages to be routed to the operators and hardcopy log.
A message contains text to provide information, describe an error, or request an operator action. A message contains an identifier, which is usually a three-letter prefix to identify the system component that produced the message, and a message serial number to identify the individual message. The identifier might contain other information, for example, a message type code.
IOS351I DYNAMIC CHANNEL PATH MANAGEMENT NOT ACTIVE
....
IEA989I SLIP TRAP ID=X33E MATCHED
....
*IXC585E STRUCTURE SYSTEM_OPERLOG IN COUPLING FACILITY CF1
PHYSICAL STRUCTURE VERSION BC7E4AB5 792253EC,
IS AT OR ABOVE STRUCTURE FULL MONITORING THRESHOLD OF 80%.
ENTRIES: IN-USE: 26771 TOTAL: 34220, 78% FULL
ELEMENTS: IN-USE: 27416 TOTAL: 34270, 80% FULL
Figure 5-11 Message examples
Message types
There are three types of messages:
Unsolicited A message routed by a routing code; that is, the message is issued by the system and it is not a response to a command.
Solicited These messages are responses to commands issued by an operator and normally routed back to the console where the command was issued. Some operator commands support the L= operand, which specifies the display area, console or console name, or both, of the console where the command response is to be routed.
Synchronous There are situations in which system operations cannot continue until the system operator takes some external action. An example might be an authorized application detecting a critical problem that warrants stopping the entire system to correct. Using the LOADWAIT macro and the WTO macro with the WSPARM and SYNCH=YES parameters stops the system so the operator can correct a problem, if possible. By using LOADWAIT and WTO, you issue a synchronous message to the operator and place the system into a restartable or non restart able wait state. A multiple line WTOR can be used only when SYNCH=YES is also specified. SYNCH=YES indicates the request is to be processed synchronously. This type of WTOR is used in error and recovery environments, when normal message processing cannot be used. The message is sent to the console, and the reply is obtained immediately, before control is returned to the caller.
The essential difference between solicited and unsolicited messages is that solicited messages are (normally) routed by the console ID that issued the command; while unsolicited messages go to consoles that are receiving the routing codes or other general routing attributes used for the message.
Message codes
The IBM message type codes, specified by a letter following the message serial number, are associated with message descriptor codes as shown in Table 5-1.
Table 5-1 Message type and descriptor codes
Type Code
Descriptor Code
W (wait)
1
A (action) or D (decision)
2
E (eventual action)
3
I (information)
4 through 10
E (critical eventual action)
11
I (information)
12 and 13
The descriptor code identifies the significance of the message. Descriptor codes are specified in the DESC parameter of the WTO or WTOR macro. Messages can be routed to a specific console through the CONSID or CONSNAME parameter of the WTO or WTOR macro. Messages can also be routed to a group of consoles by assigning routing codes through the ROUTCDE parameter of the WTO or WTOR macro. The routing code identifies where a message is displayed. A console definition includes the set of routing codes it should receive. More than one routing code can be assigned to a message.
Refer to z/OS MVS Routing and Descriptor Codes, SA22-7624 for more details.
5.11 Message flow in a sysplex environment
Figure 5-12 Message flow in a sysplex environment
Message flow in a sysplex environment
In a sysplex, a message is routed to all active consoles on all systems that are eligible to receive that particular message.
Figure 5-12 shows the message flow in a sysplex. It is important to understand this flow because in a sysplex environment, message flow is changed to send messages issued on one system to other systems in the sysplex using XCF services.
1. The z/OS write to operator (WTO) and the write to operator with reply (WTOR) macro services cause messages to be routed to the consoles and the hardcopy log.
2. First on the issuing system, the message is processed by the message processing facility (MPF). This processing is based on entries in the MPFLSTxx PARMLIB member. MPF processing allows an installation to influence how WTO and WTOR messages are to be processed. Through the MPFLSTxx member, you can specify some processing options for a message.
3. Following MPF processing, the message is broadcast to all active subsystems that request to receive control for the WTO subsystem interface (SSI) function code 9. The subsystem must use the IEAVG700 interface to indicate that all WTOs and WTORs are to be broadcast. The message is presented to each subsystem in turn. Each subsystem may inspect the message and process it as appropriate. A subsystem can alter write-to-operator queue element (WQE) fields, in which case later subsystems on the SSI will see the changed WQE. A WQE is an internal control block that contains the message text and all related information for that message. The IHAWQE macro maps the WQE fields.
For example, when NetView is using the SSI rather than an extended MCS console for z/OS communication, NetView on the SSI inspects all messages to see whether they are marked by MPF as eligible for automation. NetView intercepts automation message text and selected attributes from the WQE and sends the data to the NetView address space for further processing. NetView does not modify the actual WQE.
4. After the message has been inspected by all active subsystems, it is written to the hardcopy log (usually the SYSLOG data set, the operations log (OPERLOG), or both) unless hardcopy logging is suppressed by an exit. OPERLOG is a log stream maintained in a Coupling Facility that uses the System Logger to record and merge communications about programs and system functions from each system in a sysplex. The messages are logged using message data blocks (MDBs), which provide more data than is recorded in the SYSLOG.
5. Finally, the message is routed for display on the appropriate MCS and extended MCS consoles. The routing may require message transportation using XCF services to other systems in the sysplex because some receiving consoles may not be physically attached to the system where the message was issued.
XCF services
After the XCF transportation on the receiving system, the message goes through the SSI loop, but it is not logged, and finally the message is processed by the message queueing tasks to be displayed on the consoles.
If a message is destined for a specific console that is not active in the sysplex, it is logged and discarded unless it is an action message or WTOR message, in which case it is processed as an undelivered message. It is sent to all active consoles receiving UD messages. The master console is a UD receiver by default.
MCS queueing of messages
Messages that are already delivered to an active extended MCS console, but not yet retrieved, are purged from the MCS queues when the console is deactivated; that is, unprocessed queued messages are not rerouted.
MSCOPE specifications
The MSCOPE specification on the CONSOLE statement in the CONSOLxx PARMLIB member allows you to screen those systems in the sysplex from which a console is to receive messages not explicitly routed to the console.
5.12 Command flow in a sysplex environment
Figure 5-13 Command flow in a sysplex environment
Command flow in a sysplex environment
When an operator command is entered through the MGCR(E) macro service, the following processing flow takes place:
1. If the command contains a prefix or the console has a CMDSYS specification that directs the command to another system, the command is immediately transmitted using XCF services to the processing system.
For command prefix and CMDSYS routing, the command is first transported to the receiving system before any system symbol substitution takes place.
A REPLY command is sent to the system where the WTOR was issued. If the REPLY command text contains system symbols, substitution occurs on the receiving system.
2. If the command is not transmitted to another processing system, it is processed on the issuing system by the installation MPF command exit routines. The exits are specified using the CMD statement in the MPFLSTxx PARMLIB member. These exits can perform authority checking, modifying the command text or the command processing.
For commands containing system symbols, substitution has occurred before the exit is entered.
3. The command is then broadcast on the subsystem interface (SSI) to all active subsystems. Each subsystem inspects the command and decides whether to process it. The subsystems base the decision on the command prefix characters of the command string. For example, by default, NetView looks for a percent sign (%) and processes the commands starting with the % sign.
Subsystem selects message
When a subsystem decides to process the command, the command is passed to subsystem processing, and a return code is set to indicate that the command was processed by a subsystem.
At this point in processing, all system symbol substitution has occurred. The original command text is also available.
4. After the command has been examined by all active subsystems, it is logged to the hardcopy log (usually SYSLOG or OPERLOG).
The hardcopy log contains the command before any system symbols contained in the command have been substituted, and it also contains the command after substitution has occurred.
5. If none of the subsystems have marked the command as having been processed, it is assumed to be an z/OS command and is passed to the appropriate z/OS command processor. If a command processor does not exist, an error message is issued stating that the command is invalid.
5.13 Console-related parmlib members
Figure 5-14 Console-related PARMLIB members
Console-related PARMLIB members
Figure 5-14 summarizes the console-related PARMLIB members, their chaining, and also lists the various statements in each member.
Besides the CONSOLxx PARMLIB member, several other related PARMLIB members affect console operations and are shown in Figure 5-14. Within the CONSOLxx member, you may reference:
CNGRPxx This member defines console groups for alternate console switching.
CTnOPSxx This member specifies the component tracing options for the operation services (OPS) component.
MMSLSTxx This member is used to display translated U.S. English messages into another language that your installation has provided.
This member references the message configuration member CNLcccxx, which defines how translated messages are to be displayed at your installation.
The primary objective of the MMS is to provide a programmable interface for message translation. The z/OS message service allows components of, or products running on, z/OS to translate U.S. English messages into the user’s native language.
MCS messages displayed on locally attached MCS consoles are not translated. When the z/OS message services (MMS) is active, the TSO/E CONSOLE command attempts to translate console messages to the primary language specified in the user’s profile (UPT).
MPFLSTxx This member is used for message processing control.
PFKTABxx This member is used to define any PFK tables for the MCS consoles.
CNLcccxx This member is used to specify the time and date format for translated messages by using the MONTH, DAY, DATE, and TIME statements.
Refer to z/OS MVS Initialization and Tuning Reference, SA22-7592 for more details.
5.14 Display console status information
Figure 5-15 Display console status information
Display console status information
Use the DISPLAY CONSOLES,ACTIVE command to display the status of all consoles in the sysplex including SMCS. The fields are defined as follows:
MSG: CURR=0 Current use of WTO buffers
LIM=1500 Specified limit of max WTO buffers
RPLY: CURR=2 Number of WTOR messages displayed and waiting for reply
LIM=999 Specified limit of max WTOR buffers
SYS=SC63 SC63 is the system the console is defined to
PFK=00 Active PFK table defined in CONSOLxx parmlib member
CONSOLE ID Console identifier
AUTH=CMDS Command authority for the console
ROUTCDE=ALL All routing codes established for the console
The DISPLAY CONSOLES,BACKLOG command is useful if there is a WTO flood coming from another system.
If you need information about EMCS consoles, use the DISPLAY EMCS command. See 5.16, “Display all defined EMCS” on page 261 for additional command examples for displaying EMCS information.
5.15 Display system requests
Figure 5-16 Display system requests
Display system requests
DISPLAY R,ALL informs you about outstanding system requests requiring operator actions. You can display the following:
•WTOR messages
•Action messages saved by AMRF
•Action messages issued by the communication task
•Action messages that where not displayed on all necessary consoles
Use the following form of the DISPLAY command to display outstanding messages requiring operator action. You can request that the system display:
•The immediate action messages (descriptor codes 1 or 2), eventual action messages (descriptor code 3), and critical eventual action messages (descriptor code 11)
•The device numbers of devices waiting for mount requests to be fulfilled
•The device numbers of devices waiting for operator intervention
•The status of the action message retention facility
•An alphabetical list of keynames of outstanding action messages
•The messages issued by a specified system
•The messages that await operator response at a specified console
•The messages that have specific routing codes
5.16 Display all defined EMCS
Figure 5-17 Display all defined EMCS
Display all defined EMCS
Use the DISPLAY EMCS command (instead of the DISPLAY CONSOLES command) to display information about extended MCS (EMCS) consoles. When the system searches for any consoles you specify, it allows wildcard matching. CN, SYS, and KEY can include wildcard characters (* and ?) that allow a single parameter to match many different actual conditions. For example, CN=AD? matches console names like AD1 or AD2 but not ADD1. CN=A* matches A1 or AD1 or ADD1.
With the DISPLAY EMCS,S,STATUS=L command you can display and determine the total number of EMCS consoles defined in the sysplex. STATUS=L displays both the active and inactive extended MCS consoles.
5.17 Display information about an EMCS
Figure 5-18 Display information about an EMCS
Display information about an EMCS
The DISPLAY EMCS,FULL,CN=consolename command displays all available information about the console selected with the CN criteria. The displayed fields have the following meanings:
CN= Console name
STATUS=A EMCS is in status active
CNID= Console identifier
KEY= Console key name assigned to a console group, which makes it possible to group consoles by function
SYS= System the console is defined to - SC63 in this example
AUTO=N No indicates that the console does not receive messages specified for automation through MPF
DOM=NORMAL Indicates that the system directs all appropriate DOMs to the console
TERMNAME= Terminal name
CMDSYS= Commands processed on the system where the console is attached
LEVEL=ALL All levels of messages sent to the console
AUTH=MASTER Master authority for the console
MSCOPE=*ALL Displays messages from all systems in the sysplex on the console
ROUTCODE=NONE No routing codes established for the console
5.18 Defining and changing console characteristics
Figure 5-19 Defining and changing console characteristics
Defining and changing console characteristics
The CONSOLxx parmlib member lets you define certain devices as consoles and specify attributes that determine how your operators can use MCS or SMCS consoles. CONSOLxx contains four statements that define and control consoles for an MVS system:
•CONSOLE
•INIT
•DEFAULT
•HARDCOPY
CONSOLE statement
The CONSOLE statement lets you define each console by device number on the CONSOLE statement. You must have a CONSOLE statement for each device that you want to use as a console. Use the Add Device panel in hardware configuration definition (HCD) to specify the device number and the unit type for MCS consoles only. SMCS consoles require the terminals to be defined for use via z/OS Communications Server. A CONSOLxx member can include multiple CONSOLE statements: one for each console in the configuration.
You use the CONSOLE statement to define a device as a console. You define each console device with one CONSOLE statement. CONSOLE also lets you specify console attributes that control the following for an MCS or SMCS console:
•Console security by assigning command authority levels
•Message routing and message formatting
•Certain console screen functions (console mode, methods for deleting messages from the screen, ways to control display areas on the screen, and how to set up the PFKs for the console)
•Console operation in a sysplex
INIT, DEFAULT, and HARDCOPY statements
The INIT, DEFAULT, and HARDCOPY statements define general characteristics for all MCS and SMCS consoles in the system or sysplex. The INIT statement is used to control basic initialization values for all MCS or SMCS consoles in the configuration.
You use the DEFAULT statement to control certain default values for MCS and SMCS consoles in the configuration.
You can use the optional HARDCOPY statement to define the characteristics of the hardcopy message set and specify the hardcopy medium. You can control how to record messages and commands for the system. After IPL, operators can use the VARY command to do the following:
•Change the set of messages included in the hardcopy message set
•Assign SYSLOG or OPERLOG, or both, as the hardcopy medium
You can use several system commands to change the console characteristics dynamically. Each command has an equivalent statement in the CONSOLxx parmlib member. The changes are only temporary; for permanent changes the CONSOLxx member should be updated. This enables you to keep the definitions over the next IPL. For more details, refer to z/OS System Commands, SA22-7627. Chapter 3 shows all the details of the dynamic change capabilities.
5.19 The hardcopy medium
Figure 5-20 The hardcopy medium
The hardcopy medium
Hardcopy processing allows your installation to have a permanent record of system activity and helps you audit the use of operator commands. The group of messages and commands that are recorded is called the hardcopy message set. The system log, operations log, or MCS printer that receive messages are called the hardcopy medium.
HARDCOPY statement in the CONSOLxx member
You can specify whether the hardcopy medium is the system log (SYSLOG) or the operations log (OPERLOG) at system initialization using the HARDCOPY statement in the CONSOLxx member of parmlib.
SYSLOG is a data set residing in the JES spool space
The system log (SYSLOG) is a data set residing in the primary job entry subsystem’s (JES) spool space. It can be used by application and system programmers to record communications about problem programs and system functions. The operator can use the LOG command to add an entry to the system log. SYSLOG is queued for printing when the number of messages recorded reaches a threshold specified at system initialization. The operator can force the system log data set to be queued for printing before the threshold is reached by issuing the WRITELOG command.
OPERLOG uses the System Logger log stream
The operations log (OPERLOG) is a log stream that uses the System Logger to record and merge communications about programs and system functions from each system in a sysplex. Only the systems in a sysplex that have specified and activated the operations log will have their records sent to OPERLOG. For example, if a sysplex has three systems, SYS A, SYS B and SYS C, but only SYS A and SYS B activate the operations log, then only SYS A and SYS B will have their information recorded in the operations log.
Change with VARY HARDCPY
Once the system has been initialized, operators can use the VARY HARDCPY command to redefine the hardcopy medium.
Display status with D C,HC
Use the D C,HC commands to display the hardcopy medium status; see Figure 5-21.
Figure 5-21 D C,HC command example
5.20 z/OS operations log (OPERLOG)
Figure 5-22 z/OS operations log (OPERLOG)
z/OS operations log (OPERLOG)
The OPERLOG uses System Logger services to record and merge communications about programs and system functions from each system in a sysplex, providing a sysplex-wide merged and chronologically ordered message log.
The messages are logged using message data blocks (MDB), which provide more data than is recorded in the SYSLOG. You can use member IEAMDBLG, in SYS1.SAMPLIB, to convert OPERLOG records into SYSLOG format.
Only the systems in the sysplex that have specified and activated the operations log will have their records sent to OPERLOG.
There is only one OPERLOG log stream within the entire sysplex, but the recording of the messages into the log stream can be activated on a system basis. You might have systems that need to merge in the OPERLOG log stream and other systems that can continue to record independently on their SYSLOG. Only the systems in a sysplex that have specified and activated the operations log have their records sent to OPERLOG.
Defining OPERLOG as a DASD-only log stream is suitable only for a single system sysplex, because a DASD-only log stream is single-sysplex in scope and you can only have one OPERLOG log stream per sysplex. This means that if you make OPERLOG a DASD-only log stream, only one system can access it.
Browse OPERLOG with the SDSF LOG option
You can browse OPERLOG or SYSLOG with the system display and search facility (SDSF) LOG option. The log you are browsing, OPERLOG or SYSLOG, is shown on the upper left corner of the log display. SDSF displays which media is currently browsing and you can switch from OPERLOG to SYSLOG by using the LOG OPERLOG or LOG SYSLOG command at any time.
If you are browsing the OPERLOG while structure rebuild takes place either due to a failure or to a maintenance procedure, the log stream data will be unavailable for the time it takes to rebuild the log stream in the alternate coupling facility. For the duration of this interval, you are notified that data is not available with an error message in your upper right corner.
Accessing OPERLOG log streams
SYS1.SAMPLIB contains the sample program IEAMDBLG to read log blocks from the OPERLOG log stream and convert them to SYSLOG format. The program is an example of how to use the services of the System Logger to retrieve and delete records from the OPERLOG stream.
IEAMDBLG reads the records created in a given time span, converts them from Message Data Block (MDB) format to Hard-copy Log format (HCL or JES2 SYSLOG), and writes the SYSLOG-format records to a file.
IEAMDBLG also has an option to delete from the log stream all the records created prior to a given date. When you use the delete option, a suggestion is to first copy the records to an alternate media and then conditionally delete them in a separate JCL step. This ensures that you have a copy of the data before deleting. If you do not execute the commands in two separate conditional steps, deletion occurs simultaneously with copy without any guarantee that the copy process was successful.
 
Note: More details about setting up and using OPERLOG are in:
•z/OS MVS Planning: Operations, SA22-7601
•z/OS MVS Setting Up a Sysplex, SA22-7625
•Systems Programmer’s Guide to z/OS System Logger, SG24-6898
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset