EMS Manual Abstract This manual describes the Event Management Service (EMS). EMS is a collection of processes, tools, and interfaces that provide event-message collection and distribution on a system running the HP NonStop™ Kernel operating system. This manual is intended for programmers, operators, and those who configure and manage systems and networks. Product Version EMS H02 Supported Release Version Updates (RVUs) This manual supports D30.02 and all subsequent D-series RVUs, G01.
Document History Part Number Product Version Published 426909-001 SPI F40, EMS F40 February 2001 426909-002 SPI G05, EMS G06 May 2002 426909-003 SPI EMS G06 June 2004 426909-004 SPI EMS H02 February 2012 426909-005 SPI EMS H02 October 2012
Legal Notices Copyright 2012 Hewlett-Packard Development Company L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
EMS Manual Index Legal Notices What’s New in This Manual xix Manual Information xix New and Changed Information About This Manual xxi Manual Organization xxi Reading Guidelines xxiii Additional Information xxv Notation Conventions xxvi HP Encourages Your Comments xix xxx Part I: Introduction to EMS 1. Introduction to EMS EMS in the System Environment 1-2 EMS Communications in the DSM Environment EMS Capabilities and Features 1-5 Basic Capabilities 1-6 Key Features 1-6 Applications of EMS 1-8 1-3 2.
Contents 3. Retrieving Event Messages Interactively Pre-Log Filtration (PLF) 2-8 Log-File Management 2-8 Distributor Support 2-9 Event Message Distributors 2-9 Consumer, Forwarding, and Printing Distributors Compatibility Distributor ($Z0) 2-10 EMS Filters 2-11 Compiled Filters 2-11 Filter Tables 2-12 Burst Filters 2-12 Text Formatting Tools 2-12 Definition Files 2-14 EMS Object Programs 2-14 EMS Utility Programs 2-15 EMS Procedures 2-15 Standard Events 2-16 2-10 Part II: Using EMS 3.
Contents 5. Compiled Filters 5.
Contents 7. Burst Detection and Suppression 7.
Contents 10.
Contents 10. Generating Standard Events Task 3.1: Determine the Operational States of Your Objects and Subsystem Functions 10-6 Task 3.2: Customize Your Standard Events 10-8 Task 4. Define Private Event Types for Your Subsystem 10-9 Task 4.1: Determine Management Functions and If EMS Is the Appropriate Platform 10-10 Task 4.2: Specify Which Operations Are Defined for Your Management Functions 10-11 Task 4.3: Specify the System Data Needed to Automate These Operations 10-11 Task 4.
Contents 11. Procedure Calls for Standard Events Task 8.11: Define Private Tokens 10-24 Task 8.12: Compile Your DDL Definitions 10-26 Task 9. Create and Build Your EMS Templates 10-26 Task 10. Code and Test Your Event Generation Code 10-27 Task 10.1: Define the EMS Collector for Your Events 10-27 Task 10.2: Build Your Event Message Buffer 10-28 Task 10.3: Send Your Event Message Buffer to the EMS Collector 10-29 Task 10.4: Compile Your EMS Code 10-29 Task 10.5: Test Your EMS Code 10-30 Task 11.
Contents 12. Configuring EMS Considerations 11-30 Standard Usage Threshold Event 11-31 The Algorithm 11-31 Implementation 11-32 EMS_UTCB_INIT_ 11-33 EMS_USAGE_THRESHOLD_CHK_ 11-35 EMS_USAGE_THRESHOLD_EVT_BLD_ 11-36 Usage Threshold Programming Example 11-41 EMS_COMMON_TOKENS_EVT_BLD_ Procedure 11-44 Condition Code Settings 11-47 Considerations 11-47 Procedure for Sending Events 11-48 Program Example 11-48 Part IV: Configuring and Maintaining EMS 12.
Contents 13. EMS Programs Primary Collector Logging After a System Load Logging After a Subvolume Switch 12-27 Switching Log Files 12-28 12-25 13.
Contents 16. Event Routing Declaring Buffers and Subsystem IDs in TAL 15-7 Procedure Descriptions 15-8 EMSADDSUBJECT and EMSADDSUBJECTMAP Procedures 15-8 EMSADDTOKENS and EMSADDTOKENMAPS Procedures 15-10 EMSGET and EMSGETTKN Procedures 15-12 EMSINIT and EMSINITMAP Procedures 15-17 EMSTEXT Procedure 15-19 16.
Contents 18. Distributor Event Messages REPLACE Command (ZEMS-CMD-REPLACE) 17-29 STATUS Command (ZCOM-CMD-STATUS) 17-30 STATUS Command (ZEMS-CMD-STATUS) 17-41 18.
Contents 20.
Contents 21.
Contents 21.
Contents 22. Collector Errors 22.
Contents A.
Contents B. Example of Reporting Events Filter Parameters A-34 Tracking Earlier Events A-34 Stopping at the End of the Logged Messages Using PASS Values A-37 A-36 B. Example of Reporting Events Testing the Program B-1 The MAKE TACL Macro File B-3 The DDL Compile-Control File B-3 The DDL Source File B-4 The SOURTMPL File B-5 The C Source File B-6 The TACL Source File B-10 C.
Contents EMS Manual—426909-005 xviii
What’s New in This Manual Manual Information EMS Manual Abstract This manual describes the Event Management Service (EMS). EMS is a collection of processes, tools, and interfaces that provide event-message collection and distribution on a system running the HP NonStop™ Kernel operating system. This manual is intended for programmers, operators, and those who configure and manage systems and networks. Product Version SPI EMS H02 Supported Release Version Updates (RVUs) This manual supports D30.
What’s New in This Manual Changes to the 426909-004 Manual Changes to the 426909-004 Manual This manual contains these changes: Added a Note in EMS Procedures.
About This Manual This manual describes the Event Management Service (EMS)—a collection of processes, tools, and interfaces that provide event-message collection and distribution in the Distributed Systems Management (DSM) environment. This manual is intended for programmers, operators, and those who configure and manage systems and networks. This manual describes information for: Server Type Product Version Supported RVUs HP NonStop S-series T9631F40 G00.
About This Manual Manual Organization Section 9, Standard Events Describes the EMS events that subsystems and applications generate to support operations management on NonStop Kernel operating systems. Section 10, Generating Standard Events Describes the steps involved in generating standard events and provides an example using a fictitious subsystem. Section 11, Procedure Calls for Standard Events Describes procedure calls that help subsystems and applications format standard events.
About This Manual Reading Guidelines Appendix B, Example of Reporting Events Provides a sample program that illustrates how to use the EMS procedures to build an event message and how to send the message to the EMS collector. Appendix C, Standard Event Sample Files Provides sample files to help you create your external specification, DDL, and templates. Appendix D, EMS Usage Best Practices and Recommendations Describes best practices for creating event messages.
About This Manual Programmers Section 3, Retrieving Event Messages Interactively Section 4, Retrieving Event Messages Programmatically Section 9, Standard Events Section 10, Generating Standard Events Section 11, Procedure Calls for Standard Events Section 14, EMS Definitions Section 15, EMS Procedures Section 17, Distributor Commands and Responses Section 19, Collector Commands and Responses Appendix A, Example of Retrieving Event Messages EMS-Management Programmers You need the com
About This Manual Additional Information Filter Programmers Because the filter language exists in the context of TACL, you need the TACL Reference Manual.
About This Manual Notation Conventions Notation Conventions General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual: UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required.
About This Manual General Syntax Notation braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example: LISTOPENS PROCESS { $appl-mgr-name } { $process-name } ALLOWSU { ON | OFF } | Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: INSPECT { OFF | ON | SAVEABEND } … Ellipsis.
About This Manual Notation for Messages !i and !o. In procedure calls, the !i notation follows an input parameter (one that passes data to the called procedure); the !o notation follows an output parameter (one that returns data to the calling program). For example: CALL CHECKRESIZESEGMENT ( segment-id , error ) ; !i !o !i,o. In procedure calls, the !i,o notation follows an input/output parameter (one that both passes data to the called procedure and returns data to the calling program).
About This Manual Notation for Management Programming Interfaces horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: LDEV ldev [ CU %ccu | CU %... ] UP [ (cpu,chan,%ctlr,%unit) ] { } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed.
About This Manual HP Encourages Your Comments The message types specified in the REPORT clause are different in the COBOL85 environment and the Common Run-Time Environment (CRE). The CRE has many new message types and some new message type codes for old message types. In the CRE, the message type SYSTEM includes all messages except LOGICAL-CLOSE and LOGICAL-OPEN. HP Encourages Your Comments HP encourages your comments concerning this document.
Part I: Introduction to EMS This part of the manual introduces the Event Management Service (EMS) and provides an overview of its components and architecture: Section 1, Introduction to EMS Section 2, EMS Components and Architecture EMS Manual—426909-005
Part I: Introduction to EMS EMS Manual—426909-005
1 Introduction to EMS The Event Management Service (EMS) is a collection of processes, tools, and interfaces that support the reporting and retrieval of event information.
Introduction to EMS EMS in the System Environment EMS in the System Environment EMS runs as a layer between the subsystem environment and the operations environment: In the subsystem environment, subsystem software directly controls resources (such as communication lines, files, and processes). Subsystems can be HP products such as Pathway, components of DSM such as ViewPoint, or user-written programs.
Introduction to EMS EMS Communications in the DSM Environment Figure 1-1. EMS in the System Environment Subsystem Environment Event Management Service - EMS Primary Collector ($0) Event Log Files Subsystems Alternate Collectors Event Log Files Operations Environment Forwarding Distributor Remote Collector Printing Distributor Printer/file/ terminal Consumer Distributor Management Application VST004.
Introduction to EMS EMS Communications in the DSM Environment Figure 1-2. EMS and Command-Response Interfaces Management Applications Event Messages Distributors Event Messages Command Response Log files Event Messages Subsystems Event Messages Collectors VST005.vsd The major EMS processes (such as collectors and distributors) are controlled through the command-response interface.
Introduction to EMS EMS Capabilities and Features sending command messages. For each command, the subsystem returns a response message. The management application and the subsystem communicate synchronously, in a one-command, one-response dialog. The EMS interface is unidirectional and asynchronous.
Introduction to EMS Basic Capabilities Event messages can be reported by subsystems for the NonStop server or subsystems you write. They are subsystem specific, and hundreds of different event messages are produced by subsystems for the NonStop server alone. Although this wide range of messages provides the diversity and depth of information required to manage systems and networks, it also creates the need for tools to manage the event messages themselves.
Introduction to EMS Key Features Subsystem generality. Each EMS message has a number of elements called tokens. Each token consists of a data value and an associated tag that identifies the data value. All subsystems use tokens to build event messages, thus ensuring that messages have the same general format and present similar information in similar ways.
Introduction to EMS Applications of EMS You can have any convenient number of distributors on a system. In general, both interactive and programmatic methods are provided for configuring and controlling collector and distributor processes. Collector processes support many configuration options to let you tailor the logging strategy according to your requirements for performance, reliability, and use of resources. Reliability.
2 EMS Components and Architecture This section describes the processes, files, and interfaces that together provide the event management capabilities described in Section 1, Introduction to EMS. Later sections describe how to perform various tasks using these components, including standard events (those that subsystems and applications must generate to support operations management). Other sections include detailed specifications for the interfaces mentioned here.
EMS Components and Architecture Event Messages Event Messages Event messages are based on tokens that convey information about events, which are significant occurrences in the subsystem environment. Because of their token structure, event messages are much more convenient and efficient for applications to process than text messages. Information is easier to find and in a more convenient form.
EMS Components and Architecture Special Kinds of Event Messages Every event message includes an event number that uniquely identifies that type of event message among all the types that the subsystem is capable of generating. The event number is the primary indication of what happened (printer out of paper, line down, takeover by backup process, and so on). Also, every event message includes a subject: the name or number of the hardware or software component most directly involved in the event.
EMS Components and Architecture Special Kinds of Event Messages Subsystems typically identify these events as critical: Potential or actual loss of data Loss of a major subsystem function Loss of a fault-tolerance capability, such as a redundant resource or failurerecovery function Loss of subsystem integrity (for example, an unrecoverable internal error in a subsystem) To indicate a critical event, the subsystem assigns the value TRUE to the ZEMS-TKNEMPHASIS token.
EMS Components and Architecture Flow of Event Messages Flow of Event Messages Two types of EMS processes manage the flow of event messages from the subsystem environment to the operations environment: Event Message Collectors accept event messages from subsystems and log them.
EMS Components and Architecture Flow of Event Messages Figure 2-1.
EMS Components and Architecture Event Message Collectors Event Message Collectors EMS supports two types of event message collectors. Primary Collector ($0) Each system (or node) has only one primary event message collector, named $0. The primary collector, initiated at system generation, provides a central collection point for all events from all subsystems in a system. $0 uses the $ZOPR process to perform waited operations.
EMS Components and Architecture Subsystem Support Subsystem Support Subsystems and user-written applications send event information to the primary and alternate collectors by means of the WRITEREAD procedure call. Event messages are based on tokens rather than text. Pre-Log Filtration (PLF) Pre-log filtration lets primary and alternate collectors use EMS filters to determine whether specific events should be logged to the EMS log files.
EMS Components and Architecture Distributor Support Primary Collector Log-File Attributes The primary collector assumes default values for log file parameters at system generation. You can change the values programmatically through the collector's SPI ALTER or CONTROL commands or interactively through the EMSCCTRL utility. For a description of the collector's command-response interface, see Section 19, Collector Commands and Responses.
EMS Components and Architecture Consumer, Forwarding, and Printing Distributors Depending on the nature of the destination, you can use one of four types of distributors: Consumer Sends selected event messages to a requesting management application. Forwarding Sends selected event messages to an EMS collector on another node in the network or to an alternate collector on the same node.
EMS Components and Architecture EMS Filters The compatibility distributor has no interactive or programmatic command interface of its own. It is controlled indirectly through commands to the primary collector. The primary collector can be instructed, through its own commands, to change certain parameters that affect the compatibility distributor.
EMS Components and Architecture Filter Tables specifications of the EMF language and the filter compiler, see The Filter Language on page 5-7 and The Filter Compiler on page 5-44. Filter Tables Filter tables are EDIT files you load into a collector or distributor, at which time the table is automatically converted to an object representation that is then evaluated for each event by a collector or distributor. For a detailed description of filter tables, see Filter Tables on page 6-1.
EMS Components and Architecture Text Formatting Tools message uniquely identify its template. For information on format templates and template files, see the DSM Template Services Manual. b. If no template is invoked for this message, EMSTEXT checks for the TEXT token. If EMSTEXT finds ZEMS-TKN-TEXT, EMSTEXT generates displayable message text from the token’s contents.
EMS Components and Architecture Definition Files type of the first subject is one that EMSTEXT cannot format. (EMSTEXT can format most token types, such as file, device, string, and integer.) Note. Applications should retry a call to open or read a template file if a timeout message is returned. A timeout is not a fatal error. EMSTEXT error—(extstat1,extstat2) prevented display of event.
EMS Components and Architecture EMS Utility Programs FILTER, which identifies the compiled filters, filter tables, and up to one burst filter that can be added to the collector to implement pre-log filtration EMSDIST (EMS Distributor) is the object program for starting printing distributors, forwarding distributors, or consumer distributors. Like EMSACOLL, the EMSDIST program provides a number of command parameters, including the FILTER parameter.
EMS Components and Architecture Standard Events EMSADDTOKENS and EMSADDSUBJECT put additional tokens and eventmessage subjects in the buffer. Subsystems that report events use these procedures to create their event messages. (For details, see Section 15, EMS Procedures.) Standard Events For a description of... See...
Part II: Using EMS This part of the manual describes basic procedures for using EMS and provides supplemental reference information: Section 3, Retrieving Event Messages Interactively Section 4, Retrieving Event Messages Programmatically Section 5, Compiled Filters Section 6, Filter Tables and Burst Filters Section 7, Burst Detection and Suppression EMS Manual—426909-005
Part II: Using EMS EMS Manual—426909-005
3 Retrieving Event Messages Interactively This section describes how to retrieve event messages with little, if any, configuration or programming. Displaying messages, either as they are generated or in a saved log file, is a good way to become familiar with the EMS environment before you undertake a larger project, such as writing a management application or configuring a large network of EMS components.
Retrieving Event Messages Interactively Displaying Current Event Messages Displaying Current Event Messages Assuming the log files are secured so that you can access them, it is easy to run a printing distributor. The simplest case is to run a printing distributor to your terminal by entering this TACL command: EMSDIST/NAME $dist/TYPE PRINTING, COLLECTOR $0, TEXTOUT $TERM1 This example runs a printing distributor and sends the output to a terminal called $term1.
Retrieving Event Messages Interactively Creating Simple Compiled Filters Creating Simple Compiled Filters A printing distributor needs a filter to specify which event messages to print and which to ignore. If you do not specify a filter, it uses its default filter, which passes all event messages.
Retrieving Event Messages Interactively Creating Simple Filter Tables For information about compiled filters, see Section 5, Compiled Filters. For information about creating filter tables and burst filters, see Section 6, Filter Tables and Burst Filters. Creating Simple Filter Tables To try running a printing distributor with a filter table, you can write one of your own. A filter table is represented as an EDIT file and does not need to be compiled.
4 Retrieving Event Messages Programmatically This section describes the interface between a management application and a consumer distributor. Because event messages follow the SPI format, and the interface to the distributor follows the command-message protocol, you should be familiar with the SPI Programming Manual. Section 3, Retrieving Event Messages Interactively, also applies to this section.
Retrieving Event Messages Programmatically Getting Started Getting Started 1. Start the consumer distributor interactively or programmatically: If you start the distributor interactively, you can provide all of its environment specifications when you start it, or you can leave some of the specifications for the management application to establish when it has opened the distributor.
Retrieving Event Messages Programmatically Getting Started 2. Use the OPEN procedure to open the process. You can also use the FILE_OPEN_ procedure, which is mandatory if the process is started at a high PIN. 3. Use the WRITE procedure to send the process a start-up message. When you send a start-up message, the only parameter you must specify is the distributor type (“TYPE C” for consumer).
Retrieving Event Messages Programmatically Changing the Environment Changing the Environment Your management application can dynamically control its distributor environment—the source (or sources) of event messages, the log file position, and the filter and its parameters—by using the distributor’s subsystem programmatic interface (SPI). To control the distributor environment, use the ADD, ALTER, DELETE, and REPLACE commands described in Section 17, Distributor Commands and Responses.
Retrieving Event Messages Programmatically Filters and Filter Parameters ZEMS^VAL^BUFLEN, count^read); IF <> THEN ... ! Handle the error ! Reset buffer length to what you declared for spibuffer spi^error := SSPUTTKN(spibuffer, ZSPI^TKN^RESET^BUFFER, ZEMS^VAL^BUFLEN); ! See if anything wrong with response buffer IF spi^error <> ZSPI^ERR^OK THEN ...
Retrieving Event Messages Programmatically Event-Message Sources Event-Message Sources You must specify the source of the event messages the distributor is to access: either the current log files of one or more primary or alternate collectors, or a saved log file. Event message sources can be added or deleted. To change from one source to another, delete the current source and add the new source. You can access up to ten collectors (current log files), but only one saved log file.
Retrieving Event Messages Programmatically Event-Message Sources ! And send the command message CALL WRITEREAD(fnum, spibuffer, buffer^length, ZEMS^VAL^BUFLEN, count^read); IF <> THEN ... ! Handle the error ! The response message is now in spibuffer. ! Reset buffer length to what you declared for spibuffer spi^error := SSPUTTKN(spibuffer, ZSPI^TKN^RESET^BUFFER, ZEMS^VAL^BUFLEN); ! See if anything wrong with response buffer IF spi^error <> ZSPI^ERR^OK THEN ...
Retrieving Event Messages Programmatically Event-Message Sources This example illustrates some of these restrictions by showing how to start with the previous two-collector example and end up with the distributor connected to a saved log file called $OPS.LOG.SV930315: ! Build CONTROL command message to delete both collectors IF (error := SSINIT(spibuffer, ZEMS^VAL^BUFLEN, ZEMS^VAL^SSID, ZSPI^VAL^CMDHDR, ZEMS^CMD^CONTROL)) THEN ...
Retrieving Event Messages Programmatically Event-Message Sources ZSPI^TKN^RETCODE, error, 1); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ... IF error <> 0 THEN ... ! Build and send CONTROL command message to add log file ! Initialize spibuffer for distributor CONTROL command IF (error := SSINIT(spibuffer, ZEMS^VAL^BUFLEN, ZEMS^VAL^SSID, ZSPI^VAL^CMDHDR, ZEMS^CMD^CONTROL)) THEN ... ! Get external name of log file for use as token value sbuf ':=' ["$OPS.LOG.
Retrieving Event Messages Programmatically Log File Position ! Check if anything wrong with response buffer IF spi^error <> ZSPI^ERR^OK THEN ... ! Buffer ok. Was distributor CONTROL command ok? spi^error := SSGETTKN(spibuffer, ZSPI^TKN^RETCODE, error, 1); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ... IF error <> 0 THEN ...
Retrieving Event Messages Programmatically Log File Position greenwich^time := CONVERTTIMESTAMP(local^time, 2); ! Initialize spibuffer for distributor CONTROL command ! message IF (error := SSINIT(spibuffer, ZEMS^VAL^BUFLEN, ZEMS^VAL^SSID, ZSPI^VAL^CMDHDR, ZEMS^CMD^CONTROL)) THEN ... ! Place token--with time token-value--in spibuffer spi^error := SSPUTTKN(spibuffer, ZEMS^TKN^GMTTIME, greenwich^time); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ...
Retrieving Event Messages Programmatically Specifying Multiple Parameters in One Command Setting the value of GMTTIME or LOGTIME to -1 causes the distributor to use the default positioning specifications (for collectors, the messages as they are logged; for a saved log file, the beginning of the file). Note. If a SETTIME command resets the system time to earlier than it was, one or more event messages will have time stamps out of sequence: earlier than that of the last message before the reset.
Retrieving Event Messages Programmatically Obtaining an Event Message (GETEVENT) only carry it forward to the next GETEVENT command message. You do not need to examine the token. You must not include the context token when its contents are not valid—that is, when the distributor has just been opened and no message has been returned yet or when a log-file positioning operation has just been performed.
Retrieving Event Messages Programmatically Obtaining an Event Message (GETEVENT) ! Save an image of this buffer for later GETEVENT commands spibuffer^image ':=' spibuffer for ZEMS^VAL^BUFLEN Bytes; ! Determine how many bytes of spibuffer have been used spi^error := SSGETTKN(spibuffer, ZSPI^TKN^USEDLEN, buffer^length); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ...
Retrieving Event Messages Programmatically Obtaining an Event Message (GETEVENT) END ELSE ! Command completed without event message BEGIN ! An error occurred on the command END; ! Move context into spibuffer^image spi^error := SSMOVETKN(ZSPI^TKN^CONTEXT, spibuffer, 1, spibuffer^image, 1); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ... ! Build a GETEVENT command message that includes EOFSTOP ! and CONTEXT.
Retrieving Event Messages Programmatically Extracting Tokens From the Response (SSGET) Extracting Tokens From the Response (SSGET) At the highest level, the GETEVENT response includes only a few basic tokens, among them the event message itself. To extract these tokens from the response buffer, use the SSGET procedure. (For a description of SSGET, see the SPI Programming Manual.) ZSPI^TKN^RETCODE.
Retrieving Event Messages Programmatically Extracting Tokens From the Event Message (EMSGET) The tokens you choose to extract depend on your application. For example, to get the value of the event number token and get the subject token from an event message: ! Retrieve the event number from the event message spi^error := EMSGETTKN(emsbuffer, ZEMS^TKN^EVENT^NUMBER, event^number); ! Handle any error from SPI procedure IF spi^error <> ZSPI^ERR^OK THEN ...
Retrieving Event Messages Programmatically Generating Display Text (EMSTEXT) Generating Display Text (EMSTEXT) Event messages contain information in a form most suitable for programmatic access, rather than for display. To obtain text suitable for display, use the EMSTEXT Procedure on page 15-19. EMSTEXT lets you specify several parameters that control the form of its output: The event message buffer. The length of each line of text. The maximum number of lines of text.
Retrieving Event Messages Programmatically Generating Display Text (EMSTEXT) Example 4-1. Normal-Format Text Produced by EMSTEXT 93-07-09 16:31:45 \COMM.$ZTNT TANDEM.TELNET.
Retrieving Event Messages Programmatically EMS Manual—426909-005 4-20 Generating Display Text (EMSTEXT)
5 Compiled Filters This section describes compiled filters. For a detailed description of filter tables and burst filters, see Section 6, Filter Tables and Burst Filters. Topic Page Writing and Compiling Filters 5-1 The Filter Language 5-7 The Filter Compiler 5-44 Writing and Compiling Filters The filter language and compiler are used to construct compiled filters. Note.
Compiled Filters Introduction to the Filter Language Source of Event Messages The collector or distributor executes the filter from the beginning for each event message that it reads. The collector or distributor reads messages sequentially from its event message source. Event messages are sent from subsystems to primary and alternate collectors by WRITE or WRITEREAD procedures. For distributors, the event message source is either a saved log file or the log files of one or more collectors.
Compiled Filters Creating a Compiled Filter You can supplement the filter language facilities with your own TACL commands and macro invocations. During filter compilation, TACL expands any text in the filter source that is surrounded by brackets ([]).
Compiled Filters Creating a Compiled Filter Loading Standard Definitions You must load the standard definitions of SPI and of each subsystem whose tokens you use. These TACL statements load the standard definitions for SPI and EMS: #PUSH dummy #LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL #LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL #POP dummy You could also use this ATTACHSEG TACL command: ATTACHSEG SHARED $SYSTEM.ZSPISEGF.
Compiled Filters Considerations for Writing Filters Errors detected: 0 Warnings detected: 0 For more information, see The Filter Compiler on page 5-44. For a working example of a filter specification, the TAL source of an application, and the DDL file that supports the filter, see Appendix A, Example of Retrieving Event Messages.
Compiled Filters Considerations for Writing Filters Efficiency Filters help a forwarding distributor make the network more efficient. Unneeded event messages that you exclude with a well-written filter help reduce network message traffic. Caution. Do not use a forwarding distributor to return a message to its system of origin. Doing so can cause a message loop that rapidly consumes system and network resources and causes event-message flooding.
Compiled Filters The Filter Language When checking the subsystem ID of an event message, use the SSID function— which ignores the version—as in this example: IF NOT ( ZSPI^TKN^SSID = SSID(ZPWY^VAL^SSID) ) THEN FAIL; Correctness To help you write accurate compiled filters: Check that the event messages come from the correct subsystem. That is, begin the filter with an IF statement to exclude any event messages whose main subsystem ID (the value of the ZSPI^TKN^SSID token) is not the one you want.
Compiled Filters Overview of Filter Operation information about filter tables and burst filters, see Section 6, Filter Tables and Burst Filters. Note. Symbolic names in this section are in TACL form, using circumflex (^) symbols rather than hyphens, because of the interface of the filter language to TACL. Overview of Filter Operation A filter operates in a collector or a distributor, which might already be running or must be started.
Compiled Filters Basic Components The compiler uses TACL to translate token names to token codes. The TACL process used is the one that calls the compiler. For more information about the relationship between the filter language and TACL, see The Filter Compiler on page 5-44. Basic Components This subsection describes the lexical elements of the filter language—such as names, operators, and constants—without much discussion of their relationship to each other.
Compiled Filters Tokens Table 5-1. Reserved Words (page 2 of 2) (continued) DESTINATION FILTER OR TRUE DO IF PASS WHILE ELSE LIST REQUIRED EMSTEXTMATCH LITERALLY SSID Names Names in the filter language follow the conventions used in TACL, except for length. Names contain letters, digits, underscores (_), and circumflexes (^), and begin with a letter. Case is not significant. TACL names can contain up to 31 characters. Names in the filter language cannot be longer than 30 characters.
Compiled Filters Tokens When you refer to a token, specify a subsystem ID using syntax that: Qualifies the token name with a subsystem ID. For details, see Qualified Tokens on page 5-12. Refers to a token name without qualification in contexts in which the subsystem ID of the token matches the EMF default subsystem ID. For details, see Tokens (Unqualified) on page 5-11.
Compiled Filters Tokens Example 2 This example shows an indexed token reference: ABC^TKN^STUFF(3) = 5 In this example, the value of a stuff token is compared to 5. Specifically, the event message is searched, from left to right, until the third stuff token is found. The value of that token is then compared with 5. If the event message contains fewer than three stuff tokens, the value of the comparison is FALSE. For details, see Comparisons With Missing Values on page 5-25.
Compiled Filters Tokens index is an integer that specifies an occurrence of the token in the event message. index must have a value between 1 and 1023, inclusive. By omitting index, you select the first occurrence of the token. If you specify a value for index that is less than 1 or greater than 1023, the filter compiler issues this error message: *** Error *** This number must be between 1 and 1023, inclusive.
Compiled Filters Tokens Fields A field name refers to a simple subcomponent (containing an integer, for example) of a structured token within the event message. In a comparison, the field name represents the value of the subcomponent or of an array of subcomponents. The syntax to refer to a field: token-name.struct-name [ : field-name [ ( index ) ] ] ... [ : field-name [ ( index ) ] ] [ ( range ) ] token-name is the name of a structured token.
Compiled Filters Constants Example 1 To use a field reference to exclude all messages except the ones created by the $ZVPT process: [#DEF fname32^struct STRUCT BEGIN CHAR systemname (0:7); FNAME name; END; ] FILTER fld_ref; BEGIN -- Refers to field of a SENDERID token IF ZEMS^TKN^SENDERID.fname32^struct:name = $ZVPT THEN PASS; END; As this example shows, to refer to a subcomponent of a structured token, you must first define the structure in TACL (within brackets, as usual).
Compiled Filters Constants Integers You can use any signed integer constant that can be expressed internally in 64 bits. For example: 1 99 -523 32769 2114678910123456708 You write unsigned, integer constants the way you write signed, positive integers. Strings Surround the characters of a string constant with double quotes. For example: "pqrstuvw" Subsystem IDs You can refer to a subsystem ID in either of two ways.
Compiled Filters Constants Considerations The compiler converts a subsystem ID expressed in the syntax just shown to an internal form. For a description of the internal form of a subsystem ID, see the SPI Programming Manual. To compare subsystem IDs, you should ordinarily use the SSID function, which removes the version number from a subsystem ID. Comparisons with version numbers stop working as soon as a new version of the event messages is released.
Compiled Filters Constants Considerations Do not include spaces in file names. Spaces are included in the syntax box only to increase visibility. You can use either uppercase or lowercase characters for file names. The compiler converts file names to internal form (24-bytes). A file name must include the volume and the file name. The system name and subvolume name are optional. Examples These file names are correct: $SYSTEM.X.Y \comm.$pubs.any.name These file names are incorrect: Y any.
Compiled Filters Bit-Extraction Operator Bit-Extraction Operator To extract bits from a specified operand creating an unsigned integer value: operand . < bit-1 : bit-2 > operand is any token value, field, or constant that occupies a byte, word, double word, or quad word. bit-1 is an integer in the range 0 through 63 that does not exceed the range implied by the data type: (0:7) for bytes, (0:15) for words, and so forth.
Compiled Filters Comparisons operand is a token name (qualified or unqualified), a field name (qualified or unqualified), a constant, or a bit-extraction operator applied to any of the elements just mentioned. The way the filter compares values—token values with token values or token values with constants—depends on the data types involved. Associating Token and EMF Data Types Table 5-2 lists the EMF (EMS filter) data type used to represent each of the token (and field) types and related information.
Compiled Filters Comparisons As shown in Table 5-2, the filter language associates many token data types with four EMF data types: signed, unsigned, string, and file name. For comparison all token values and field values are treated as one of these four types. The filter language treats many token data types as unsigned values. Because of the internal structure of such data types, it is not meaningful to use most EMF comparisonoperators, such as <, to compare values of many token data types.
Compiled Filters Comparisons is not possible between a signed (or unsigned) value and a string (or file name) value. These types are considered incompatible. Comparing Values With Composite Data Types The filter language treats certain token types as composites, for purposes of comparing. These composites consist of two or more data-type elements, as defined here. For example, a subsystem ID consists of six unsigned integers.
Compiled Filters Comparisons Except for expressions governed by a LITERALLY function, string comparisons ignore character case, which makes these strings equal: "abc" "ABC" "AbC" For information on making case-sensitive comparisons, see LITERALLY Function on page 5-41. Comparing Signed Values No conversion is necessary in a comparison of a ZSPI^TYP^INT token TKN^I with a small integer. For example: IF TKN^I < 3 THEN PASS; The value 3 and the token both have INT values.
Compiled Filters Comparisons The node that compares the file names When writing a file name in a filter, you should normally omit the node name. The file names are equal: If both file names are in local form, the value of the file-name comparison depends on whether the names match. If both file names are in network form, the value of the file-name comparison depends both on whether the system numbers match and on whether the rest of the file parts match.
Compiled Filters Boolean Expressions Comparisons With Missing Values The values of one or both operands of a comparison might be missing due to any of these causes: The comparison refers to a token that is not in the current event message. The comparison refers to an optional parameter that was omitted when the other parameters, if any, were supplied.
Compiled Filters Declarations Table 5-3. Elements of Boolean Expressions (page 2 of 2) (continued) Element Description AND (A AND B) is a Boolean expression that is TRUE if both A and B are TRUE. Otherwise (A AND B) is FALSE. (If A is FALSE, B is not evaluated.) OR (A OR B) is a Boolean expression that is TRUE if A is TRUE, if B is TRUE, or if both A and B are TRUE. Otherwise (A OR B) is FALSE. (If A is TRUE, B is not evaluated.) NOT (NOT A) is a Boolean expression that is TRUE if A is FALSE.
Compiled Filters Declarations FILTER Declaration The syntax for declaring a filter: FILTER filter-name [ ( param [ , param ] ... ) ]; BEGIN [ SSID ( subsystem-id ) ] [ variable-decls ] statement [ ; statement ] ... END filter-name is an identifier. param is the qualified name of a parameter token optionally followed by the keyword REQUIRED or by the keyword OPTIONAL. For the meaning of these keywords, see Filter Parameters on page 5-29.
Compiled Filters Declarations Example 1 This filter selects event messages local to the \ABCD system: FILTER forward^only^local^events; BEGIN IF ZEMS^TKN^SYSTEM = [#SYSTEMNUMBER \ABCD] THEN PASS ELSE FAIL; END; Example 2 This filter selects event messages that have a ZEMS^TKN^ACTION^NEEDED token set TRUE, no matter which subsystem created the message. The #SET command just before the filter defines the subsystem ID for EMS, namely ZEMS^VAL^SSID, for use in the filter itself.
Compiled Filters Declarations Filter Parameters Filter parameters let you specify the value of certain tokens when you install the filter, rather than when you compile the filter specification. The values of these parameter tokens cannot be changed while the collector or distributor is examining a series of event messages. Otherwise, filter parameters must be changed by object-oriented SPI command messages like ADD, ALTER, DELETE, or REPLACE.
Compiled Filters Statements FILTER f ( SSID(myssid, MY^TKN^1) ); FILTER g ( SSID(myssid, MY^TKN^2) OPTIONAL ); FILTER h ( SSID(myssid, MY^TKN^3) REQUIRED ); Example 2 This example shows a reference to the MY^TKN^3 parameter token: IF MY^TKN^3 > 131 THEN PASS 1; MY^TKN^3 is qualified by myssid in the declaration but is unqualified in the comparison. Statements This subsection describes the filter language statements: the assignment, compound, destination, IF, PASS, and FAIL statements.
Compiled Filters Statements Boolean-expression is any valid Boolean expression. Considerations Any variable not explicitly assigned the value TRUE is FALSE because variables are initialized to FALSE each time a new event message is examined. You cannot save Boolean values from one event message to the next. Variables are automatically initialized to FALSE each time a new event message is examined.
Compiled Filters Statements LIST ( ssid-token ) if present, allows the user to enter the list identifier by the ssid-token. Considerations If you do not specify a subsystem ID on the compound statement, the subsystem ID in ZSPI^TKN^SSID is assumed. In such a compound statement, simple (unqualified) names of tokens represent tokens of the subsystem that generated the event message. Explicit qualification of a token name overrides the implicit qualification provided by a compound statement.
Compiled Filters Statements Destination Statement The destination statement has been added to the filter source to describe a distributor's routing configuration. Filters with destination statements can only be used in printing distributors. Multiple statements per filter are allowed.
Compiled Filters OBJECT Statements is the program file name of the destination process. It must be fully qualified. If the node name is not given, the name of the distributor's node is substituted later. Currently, the EMF (EMS filter) language requires file names to begin with either a dollar sign ($) or a backslash (\) character. To avoid hard-coded file names, a DEFINE name can be given that is later resolved by the distributor.
Compiled Filters Statements DISCARDEVENT Statement The DISCARDEVENT statement stops filter execution immediately and rejects the current event message in any compiled filter, whether it is the only filter present or any filter in a multiple-filter environment. Unlike the FAIL statement, DISCARDEVENT rejects the message outright and does not pass it on to any other filters. DISCARDEVENT Example This filter fragment makes use of a DISCARDEVENT statement and an implicit FAIL statement: . . .
Compiled Filters Statements IF fflag THEN FAIL; IF qflag THEN PASS; -- If control reaches this point, an implicit FAIL -- statement is executed. END -- End of filter specification IF Statement The IF statement provides for conditional execution of a statement that follows THEN and a statement that follows ELSE. IF expression THEN statement-1 [ ELSE statement-2 ] expression is any Boolean expression. statement-1 is any statement. statement-1 is executed only if expression is TRUE.
Compiled Filters Statements The filter PASS statement has been enhanced to allow an optional list of routing IDs, in addition to the value that can currently be returned. A routing distributor also returns the PASS value itself to the destination if the event is unformatted, which was previously done for consumer distributors only. In the case of multiple filters, each filter can send a different PASS value to its destinations. Note.
Compiled Filters Functions This filter fragment shows a PASS statement that routes the event to destinations 1 and 2 (and no pass value returned): . . . IF qflag THEN PASS ,1,2; Functions The filter language includes Boolean functions DECOMPOSE, DECOMPOSEERROR, EMSTEXTMATCH, FILENAMECOMPARE, LITERALLY, MATCH, TOKENPRESENT, and the SSID function. DECOMPOSE Function This function returns the parts of a 12-word internal-format file name, a file-name string, or a process handle.
Compiled Filters Functions SUFFIX Specifies inclusion of the trailing portion PREFIX Specifies inclusion of the leading portion NO DEFAULTS Specifies that =_DEFAULTS not be used DECOMPOSEERROR Function This function returns the error resulting from the most recently executed DECOMPOSE function if an error occurred. A 0 is returned if no error occurred.
Compiled Filters Functions Considerations Use this function with caution. If possible, filtering should always be done by tokens. Use the EMSTEXTMATCH function only if no other way is possible (for example, for event messages that contain text instead of tokens). EMS is moving toward using tokens instead of text in event messages. Using text increases maintenance and reduces performance.
Compiled Filters Functions FILENAMECOMPARE Function This function compares two values to determine whether they refer to the same object. FILENAMECOMPARE returns TRUE if the values represent the same object. FILENAMECOMPARE ( value , value ) value is a token name representing a D-series file name. This statement passes all events generated by a particular instance of $null: IF FILENAMECOMPARE (ZEMS^TKN^PROC^DESC, #\ncn.
Compiled Filters Functions MATCH Function The MATCH function determines whether the value of a specified token matches the pattern specified by a template. MATCH returns TRUE if the value of the token (or field) matches the template. MATCH comparisons are case insensitive as are string comparisons. For more information, see Comparing Strings on page 5-22. MATCH ( token-specifier , template ) token-specifier is the name of any token or field whose value type is string or file name.
Compiled Filters Functions subsystem-id is a subsystem ID, expressed as a name or as a constant. Consideration Subsystem IDs are treated in comparisons as the EMF (EMS filter) unsigned values, and unsigned values of unequal length are compared for the length of the shorter value. Therefore, to compare a subsystem ID with the SSID function of another subsystem ID ignores the version in the comparison.
Compiled Filters The Filter Compiler Example This filter executes the compound statement only if the application actually passed the MY^TKN^STIME parameter token to the distributor: [ #DEF myssid STRUCT LIKE ZSPI^DDL^SSID; ] [ #SET myssid [myorg].[mynum].[myver] ] FILTER ptest( SSID ( myssid, MY^TKN^STIME ) OPTIONAL ); BEGIN IF TOKENPRESENT ( MY^TKN^STIME) THEN BEGIN . . . END; END; The Filter Compiler This subsection describes how to compile a filter specification.
Compiled Filters Compiler Directives Before compiling a filter, you must load the standard definitions for SPI and for any subsystem whose names you use in the filter. Loading standard definitions defines the names for a subsystem: names of tokens, names of values, and most other names that you might need. Names of subsystem IDs are defined but not initialized by loading the standard definition files. You can place TACL commands at the beginning of a filter (in brackets) to initialize subsystem IDs.
Compiled Filters Compiler Invocation NOLIST Directive The NOLIST directive causes current source statements to be excluded from the compiler output file. For details, see also the LIST directive. ?NOLIST SOURCE Directive The SOURCE directive causes the compiler to include language text from the specified file. ?SOURCE file-name file-name is a file name of an EDIT file (file code 101) with language text.
Compiled Filters Compiler Errors and Warnings run-option is CPU, LIB, MEM, PRI, STATUS, SWAP, or TERM. For more information, see the RUN command in the TACL Reference Manual. object-file is the file name to contain the compiled filter. The default object file name is FOBJECT, on the current volume and subvolume. Considerations If you omit the IN and INV parameters, the compiler prompts the TACL IN file— typically a terminal—interactively for the filter specification.
Compiled Filters Compiler Errors and Warnings Compiler Warning Messages This subsection describes warning messages that indicate potential problem areas of your source filter and that begin with *** WARNING ***. The compiler inserts a circumflex (^) in your listing to mark the item the message describes. Each of these message text boxes contains the exact text of one warning message. The text following each box describes the cause, effect, and recovery for that message.
Compiled Filters Compiler Errors and Warnings Recovery. None needed. *** Warning *** Failed to rename old-file to new-file (error err) Cause. The compiler received error err while attempting to rename a file but was able to recover. Effect. The file is not renamed, but the compiler continues. Recovery. None needed. *** Warning *** Invalid compiler command - command Cause. The indicated compiler directive does not exist or is misspelled. Effect. The command is not executed, but the compiler continues.
Compiled Filters Compiler Errors and Warnings Effect. The compiler performs the comparison as if the names were string data of the same length. Recovery. None needed. Compiler Error Messages This subsection describes error messages that represent source-filter errors and that begin with *** ERROR ***. After presenting one of these errors, the compiler continues to run and to diagnose any further problems. The compiler inserts a circumflex (^) in your listing to mark the problem the message describes.
Compiled Filters Compiler Errors and Warnings Cause. The indicated field name (the name of a subcomponent of a structured token) is undefined or has an inappropriate array index. If the array index is out of range, the circumflex (^) marks the incorrect index. A field without an index has an assumed index of zero, by a TACL rule. If you declare x(1:5) and then refer to x, you receive this error message. Effect. The compiler continues to its next task. Recovery.
Compiled Filters Compiler Errors and Warnings Cause. A file named in a compiler SOURCE directive has an invalid file code. The file should be an EDIT file. Effect. The compiler SOURCE directive is not executed. Recovery. Check that your compiler SOURCE directive refers to an EDIT file. *** Error *** Currently not supported: feature Cause. The indicated feature is not supported by this version of the compiler. Effect. The unsupported feature is not executed. Recovery.
Compiled Filters Compiler Errors and Warnings Cause. The size and offset of the indicated field is too large to be the value of the indicated token. The compiler cannot detect this condition if the token is of variable length and not extensible. Effect. The command is not executed. Recovery. Check that the end of field falls within the token’s value by modifying the field or the token appropriately. *** Error *** Expected a Boolean variable Cause.
Compiled Filters Compiler Errors and Warnings Effect. The command is not executed. Recovery. Check that your map information does not exceed 4000-bytes. *** Error *** Expected a valid token: not a valid SPI data type Cause. The data type of the token code is not one of those defined by the programmatic interface. Effect. The command is not executed. Recovery. Use SPI-defined data types for token codes. (For details, see the SPI Programming Manual.
Compiled Filters Compiler Errors and Warnings Effect. The command is not executed. Recovery. Check that the field has an even byte offset. *** Error *** Field names must be less than 255 characters Cause. The name of the indicated field is longer than 255 characters. Effect. The command is not executed. Recovery. Restrict the length of referenced field names to no more than 255 characters. *** Error *** Format: Indent or reclen not allowed if format off Cause.
Compiled Filters Compiler Errors and Warnings Effect. The command is not executed. Recovery. Check the syntax of your command and remove the indicated character. *** Error *** Invalid syntax - continuing Cause. The indicated statement has an error in syntax. Effect. The compiler tries to recover by ignoring one or more lexical tokens, but might not be able to do so. Recovery. Check the statement for syntax errors, and fix any that exist. *** Error *** Invalid syntax - end of input Cause.
Compiled Filters Compiler Errors and Warnings Cause. The parser detects a routing ID specification in a PASS statement, and the RID was not defined in a previous DESTINATION statement. Effect. The command is not executed. Recovery. Check that the specified routing ID is defined in a previous DESTINATION statement. *** Error *** Startup too big: Startup message is too long Cause. The parser detects an incompatibility in the DESTINATION statement. Effect. The command is not executed. Recovery.
Compiled Filters Compiler Errors and Warnings Recovery. Check that the indicated number falls in the range from 0 to 255. *** Error *** This token was not declared with this SSID Cause. The indicated token was declared to be a parameter token, but was also declared to be associated with a different subsystem descriptor than it is now used with. A parameter token can be used with only one subsystem descriptor. Effect. The command is not executed. Recovery.
Compiled Filters Compiler Errors and Warnings Cause. An identifier, assumed to be a Boolean variable, was used but not previously declared. The compiler automatically declares it to avoid duplicate messages. Effect. The command is not executed. Recovery. Check that all used Boolean variables have been declared. *** Error *** Unterminated string Cause. A string constant is missing its final double quote, for example “xyz. Effect. The command is not executed. Recovery.
Compiled Filters Compiler Errors and Warnings Recovery. Use a more recent version of the operating system (B00 and later). *** Fatal *** Can't make a new ZZEFnnnn file name Cause. The compiler cannot successfully create the specified file name. Effect. The compile terminates. Recovery. Report this internal error to your service provider. *** Fatal *** Exceeded available parameter storage space Cause. Too many parameter tokens are declared, using more than 32000-bytes of storage.
Compiled Filters Compiler Errors and Warnings Cause. The compiler receives an error while trying to communicate with its TACL process. Effect. The compile terminates. Recovery. Correction depends on the specified Guardian error. TACL Fatal-Error Messages This subsection describes fatal-error messages produced by TACL that begin with *** EMF: .
Compiled Filters Completion Codes Cause. The compilation failed for some reason other than bad input. Effect. The compile ends without successful results. Recovery. Determine what caused the failed compile (possibly a TACL problem). *** EMF: Unknown compiler request has caused an internal error Cause. An undefined or misspelled TACL macro directive has been processed by TACL; TACL then terminates the compilation abnormally. An error internal to the compiler or to a TACL macro caused the termination.
6 Filter Tables and Burst Filters This section describes filter tables and burst filters and describes how to construct, add, replace, and delete them from a collector or distributor: Topic Page Filter Tables 6-1 Burst Filters 6-7 For more information on compiled filters, the EMS filter (EMF) language, and the filter compiler, see Section 5, Compiled Filters. For more information on configuring and implementing BDS in a collector or distributor, see Section 7, Burst Detection and Suppression.
Filter Tables and Burst Filters Filter Table Format The filter table contains three base columns: subsystem owner, subsystem ID, and event number. You can replace the event number column with a standard type or user type column. A hierarchical dependency exists between columns: an owner can have several subsystem IDs, and a subsystem ID can have several event numbers. You can specify a pass value for each event or group of events.
Filter Tables and Burst Filters Filter Table Keywords first column are interpreted as directives. The filter must contain a ?PASS or ?FAIL directive. The ?COMMENT directive skips lines until another directive is encountered. The owner name in the filter table (up to 8 characters) starts in position 1, the subsystem name or number in position 10, and the event number in position 20. Event number ranges are permitted (a..b), as well as wild cards in the owner, subsystem, or event column.
Filter Tables and Burst Filters Filter Table Keywords Table 6-1. Filter Table Keywords (page 2 of 2) (continued) Keyword Description ?EMPHASIS n n is either (0) or (1) and signifies the severity of the event. If set to (1), the event is considered critical. ?USER n,m n is the group number and m the user number of the user ID associated with the process that generated the event. Either one must be smaller than 256. The user number can be the asterisk (*) wild-card character (example: 255,*).
Filter Tables and Burst Filters Filter Table Errors Filter Table Errors These errors can be returned when the conversion from filter table text file to filter table object fails. The return code for these errors is ZEMS-ERR-FLT-FORM (1019). The detailed error code is returned in ZEMS-TKN-FILTER-ERROR. The row and column locations of the error occurrences are returned in ZEMS-TKN-FAIL-REASON. (The column is in bits <0:5>, and the row is in bits <6:15>).
Filter Tables and Burst Filters Multiple Filters Directive SUPPRESS missing Incompatible directives Object file purge error 48 Object file create error Object file open error Object file write error = = = = = = -59 -60 -100 -101 -102 -103 Multiple Filters Alternate collectors and distributors accept specification of multiple filters in the startup line of the EMSACOLL and EMSDIST program, respectively. Multiple filters are run in sequential order for each event.
Filter Tables and Burst Filters Logical Connection Is AND Use the object-based SPI command ADD to load multiple filters or a single filter into a collector or distributor. Filter names are submitted as multiple object token values. To remove a filter or replace a set of filters with a PASSALL default filter, use the DELETE command. The CONTROL command cannot be used by collectors to add, alter, replace, or delete filters.
Filter Tables and Burst Filters Burst Filters filter directives in an EDIT file. The collector or distributor converts this EDIT file to a filter object in the same manner as for standard filter tables. A burst filter always acts like a FAIL filter because it suppresses event bursts that conform to the prevailing BDS configuration criteria. When BDS is enabled in a collector, these suppressed events are discarded rather than logged to disk.
Filter Tables and Burst Filters Burst Filters Burst Filter Directives Defined in terms of the filter directives used to configure a burst filter, an event burst is the occurrence of N or more similar events during T1 seconds. An event burst is considered to have ended when the bursting event does not occur for T2 seconds. The values of the N, T1, and T2 parameters are supplied by the user.
Filter Tables and Burst Filters Burst Filters Table 6-2. Burst Filter Directives Filter Directive Represents ?SUPPRESS The filter is a burst filter. This directive is required and must precede all other burst filter configuration directives. ?N m The number of similar events repeated within T1 seconds that constitute a burst condition. The variable must be in the range of 2 through 32,767 events. The default value is 100.
Filter Tables and Burst Filters Burst Filters Burst Filter Example This example shows EDIT file for a burst filter: ?COMMENT Burst Detection/Suppression ?SUPPRESS ! Number of event occurrences for a burst ?N 50 ! Burst start detection interval (seconds) ?T1 60 ! Burst end detection interval (seconds) ?T2 120 ! Periodic check for burst end (seconds) ?T3 30 ! Maximum number of simultaneous bursts ?S 20 ! Subject length to compare ?L 0 For examples of the consequences of different BDS configurations, see BDS
Filter Tables and Burst Filters Burst Filters EMS Manual—426909-005 6-12
7 Burst Detection and Suppression This section describes the burst detection and suppression (BDS) and specific-event suppression features of EMS: Topic Page Event Suppression Strategies 7-1 BDS Features 7-2 Implementing BDS 7-6 Implementing Specific-Event Suppression 7-7 Types of Collector Events BDS and PLF Do Not Suppress 7-9 For more information about the structure of filter tables and burst filters, see Section 6, Filter Tables and Burst Filters.
Burst Detection and Suppression BDS Features This strategy, referred to here as specific-event suppression, requires the use of a filter table or compiled filter that clearly identifies the specific event type to be suppressed. Pre-log filtration (PLF) refers to the use of one or more filters in a primary or alternate collector to prevent certain events from being sent from the collector to its log file.
Burst Detection and Suppression BDS Parameters see repetitive events, either disable BDS or alter the BDS parameters so they do not suppress the expected repetitive events. BDS users should first create burst filters that enable burst detection in one or more of your EMS distributors.
Burst Detection and Suppression BDS Parameters Possess the same value for their first subject Note. You can consider events similar if they have the same SSID and event number, without regard for their subject tokens and values. BDS allows an option for omitting the subject token code and subject value from the comparison criteria. Collectors convert text generated by a sender-invoked WRITE procedure into text events. Two or more text events are considered similar only if their text is identical.
Burst Detection and Suppression BDS Configuration Examples the first event subject in the event burst. This burst-detected event alerts operators that EMS has begun suppressing an event. Operators should not interpret the absence of further copies of the event as an indication that the underlying problem has been corrected.
Burst Detection and Suppression Implementing BDS represents the PU number 1 through 4). In this configuration, a change of state in one of the lines generates a line event, four PU events, and 128 (4x32) LU events. However, only the line event requires attention. The other events simply waste processing time and disk space. BDS can be used here to eliminate most of the 128 LU events, but probably none of the PU events (because there are only four of them).
Burst Detection and Suppression Implementing BDS From a Distributor Programs. If you use EMSACOLL SUPPRESS to enable BDS, you cannot use the EMSACOLL FILTER option. When the alternate collector is first started, use the FILTER keyword of the EMSACOLL command to add a burst filter that contains the BDS directives. If you use the EMSACOLL FILTER option to load a burst filter to enable BDS, you cannot use the EMSACOLL SUPPRESS option.
Burst Detection and Suppression Implementing Specific-Event Suppression From a Primary Collector Implementing Specific-Event Suppression From a Primary Collector To enable specific-event suppression in the primary collector, use one of these methods: While the primary collector ($0) is running, use the FILTER keyword of EMSCCTRL to specify a filter table or compiled filter that contains the eventsuppressing directives (this command enables PLF).
Burst Detection and Suppression Types of Collector Events BDS and PLF Do Not Suppress Types of Collector Events BDS and PLF Do Not Suppress Many of the events generated by an EMS collector are not suppressed by either the BDS or pre-log filtration (PLF) facilities. These events concern the state and behavior of the collector.
Burst Detection and Suppression Types of Collector Events BDS and PLF Do Not Suppress EMS Manual—426909-005 7-10
Part III: Designing and Implementing Event Reporting This part of the manual discusses EMS events and describes procedures involving standard events: Section 8, Reporting Events Section 9, Standard Events Section 10, Generating Standard Events Section 11, Procedure Calls for Standard Events EMS Manual—426909-005
Part III: Designing and Implementing Event Reporting EMS Manual—426909-005
8 Reporting Events EMS is a general facility for collecting and distributing event information, and it accepts event messages from NonStop Kernel subsystems, such as Pathway and Expand, and from user-written subsystems. This section describes how your program can produce event messages and send them to EMS for collection and distribution.
Reporting Events Task 1: Decide What Events to Report Task 1: Decide What Events to Report Determine what events your subsystem can detect, which of those events it should report to EMS, and which of those reported events should be considered critical or action events. Task 1.1: Decide Which Detectable Events to Report to EMS In general, your subsystem should produce an event message to report any occurrence that might affect how the system or network is managed or maintained.
Reporting Events Task 1.2: Decide Which Reported Events Are Critical or Action Events detect this situation). For example, a subsystem that performs retries when a failure occurs should send one event message after exhausting the retry count, rather than send one event message for each retry attempt. You might discover more subtle cases where it would be appropriate to condense redundant events into a single event message or to report only the first occurrence of an event.
Reporting Events Task 1.2: Decide Which Reported Events Are Critical or Action Events need to be mounted or when printers run out of paper, but action events can be appropriate for other subsystems in other circumstances as well. Do not report an action event when only a specific user or process can resolve the problem. Assume that EMS will route the message through a filter that selects action events for ViewPoint to display for an operator.
Reporting Events Task 2: Decide What to Include in Event Messages Both messages in the action-event pair should include the appropriate action tokens because applications use those tokens to match the action-attention message with the corresponding action-completion message. Because the operator might overlook a displayed event message or, rarely, an event message might be lost, your subsystem should reissue any action-attention event that has not been remedied within an appropriate period of time.
Reporting Events What Is Provided for You Event messages are almost always filtered before reaching an interested party, so ensure that the information is presented in a way that allows many filtering options. Some examples of filtering considerations: It is more convenient to filter on a token at the top level than on a token within a list. Present any information that a user might want to include in the filtering criteria as a token at the top level, as opposed to packaging it inside a list.
Reporting Events What You Must Provide Table 8-1.
Reporting Events What You Must Provide subsystem are aware of which tokens in each of your messages are unconditional and stable—that is, tokens that are fundamental to the meaning of that message and unlikely to be changed or deleted in future versions of your software. If you must delete an unconditional token or change its meaning, indicate this by changing the value of the event-number token.
Reporting Events What You Must Provide component instead of the ATM itself). Sometimes the process producing the event message does not have the same view of the environment as the process that supports the programmatic command-response interface for that subsystem (or the subsystem might not support a command-response interface). For action events, identify the resource that requires attention as the subject of the event message.
Reporting Events What You Can Optionally Provide Its value distinguishes an action-attention message (the value is TRUE) from an action-completion message (the value is FALSE). Identify the resource that needs service by making it the subject of the event message. Both messages of the action-event pair must identify the same subject, using the same name and token for that resource.
Reporting Events Task 3: Create a Data Definition File Avoid packing several items as bit fields within a word because such fields can be difficult for an application to extract. Follow familiar formats for familiar items. An easy way to ensure compatibility with NonStop Kernel subsystems and with the expectations of application programmers retrieving your event messages, is to use the appropriate ZSPIDDL-defined types for your tokens.
Reporting Events Task 4: Write the EMS Interface in Your Program For specific information about how to define a subsystem ID, see the SPI Programming Manual. For more information about DDL, see the Data Definition Language (DDL) Reference Manual. For an explanation on how a DDL dictionary (not a source file) is used to create event templates and store other information for a subsystem, see Section 9, Standard Events, Section 10, Generating Standard Events, and the DSM Template Services Manual.
Reporting Events Example: Writing an EMS Interface Into a Program CALL OPEN ( COLNAME, FILENUM); In COBOL85, use ENTER COBOL85^SPECIAL^OPEN, rather than the OPEN verb, to open the FD when you are using messages containing tokens. Do not use this statement when you are using ASCII text. Step 2: Build Event Messages Because an event message has a specialized header and other unique characteristics, building one requires a different set of procedures than building a command or response message.
Reporting Events Example: Writing an EMS Interface Into a Program ! Call WRITEREAD to send event-message buffer to $0-CALL WRITEREAD ( FILENUM, ! from OPEN EVENT^BUF, ! event-message buffer EVENT^SIZE, ! from SSGETTKN above 0 ); ! read count The read count must be 0 (zero) when sending an event message. WRITEREAD is used instead of WRITE to indicate to the collector that the buffer is an event message and not ASCII text.
9 Standard Events Standard events are a small set of events that subsystems and applications should generate to support operations management and conform with future enhancements to these standard events. The small number of standard events improves many aspects of event management.
Standard Events Introduction to Standard Events Introduction to Standard Events This section describes events that subsystems and applications should generate to support operations management on NonStop systems. Detailed content of each event is specified as are the circumstances under which to generate the event, which EMS template to use to display each event, and how programmed operators (management applications) and human operators should use these events.
Standard Events Requirements for Standard Events Requirements for Standard Events These events are designed to support requirements from known existing management applications running on NonStop systems. These requirements should be satisfied for future enhancements to these standard events. The requirements are: Each standard event supports a well-defined management function or operation. Events without a clear purpose should not be defined.
Standard Events Object State Monitoring Functions and display these tokens for the human operator according to the EMS template provided for the event. You define an EMS template for each standard event so that information is presented consistently to operators. Subsystem and application developers are expected to use these standard templates for their standard events.
Standard Events Reactive Problem Management Functions enters this state. Report this same event every time the operator tries but fails to bring the object back into service. When an object needs an operator to change its state An object is in an intervention-needed state when it needs the operator to change its state.
Standard Events Reactive Problem Management Functions 2. Problem diagnosis. An operator should be able to detect the specific cause of a problem and the action required to resolve it. 3. Problem bypass and recovery. An operator should be able to bypass a problem, if necessary, until the problem can be resolved. The decision whether to bypass or not is a tradeoff between the cost to the enterprise due to the loss of a failed component and the cost in providing the bypass capability. 4. Problem resolution.
Standard Events Reactive Problem Management Functions To find the event with the actual cause of the problem, use the problem management application to search the EMS log for an Object Unavailable event with a subject the same as the underlying object specified in this event. Repeat this search algorithm until it finds an Object Unavailable event that contains the actual cause of the failure.
Standard Events Proactive Problem Management Functions Proactive Problem Management Functions Proactive problem management deals with managing problems that might, but have not yet, occurred. This involves predicting, from received EMS events, whether to take actions to prevent an object from becoming unavailable or performing at less than full capacity. The Object Monitoring Facility (OMF) provides some of these functions.
Standard Events Production Requests Requiring Operator Attention These system-wide resources are better monitored outside the subsystems and applications (making an individual subsystem or application unnecessary) by monitor programs such as the Object Monitoring Facility (OMF): CPU (percent busy) Disk files (percent file full) Disk volumes (percent volume full) Transaction response time (in units of time) Subsystems, applications, and monitor programs that generate Usage Threshold events shoul
Standard Events Underlying Philosophy of Standard Events 4. The operator corrects the problem. If the subsystem cannot detect the operator has corrected the problem, it should provide an interface, like the commandresponse interface, so the operator can notify the subsystem when the problem is corrected. 5. The subsystem creates and sends the Operator Attention Completed event message, specifying the completed service and the same ID as in the original request. 6.
Standard Events Underlying Philosophy of Standard Events Information about the subsystem or application reporting the message—a subsystem identifier (SSID), process identifiers, and other relevant information about the creator of the message. Some information is conditional; for example batch job ID. Standard events contain a batch job ID token only if the object is part of a batch job (has a job ID).
Standard Events Event Numbers Subsystems determine the objects to report in an event. However, this section recommends some commonly used schemes for naming objects in events. Use one of these schemes to name your objects to minimize the amount of subsystem-specific knowledge a management application needs to learn. For the requirements and the naming schemes for objects represented by a single group name, see Object Name for a Group of Objects on page 9-16.
Standard Events Object Name for Event Subject A standard event type lets operators quickly identify the kind of events they need to collect and process in their systems. Unlike event number, which lets management applications take action on a specific object type, event type lets management applications simply and efficiently process a group or class of events, regardless of which subsystem or application the events came from.
Standard Events Object Name for Event Subject an automated teller machine (ATM), and the token value contains the actual name of that ATM. Should uniquely identify the process, or control point, in the NonStop Kernel network where management applications can send commands to control or inquire about the object. If the name cannot identify the control point, the subsystem or application must specify the name of a manager process if that is the control point.
Standard Events Object Name for Underlying Object Object Name for Underlying Object When an object that a subsystem communicates with directly, but that is defined and controlled in another subsystem, goes out of service, an Object Unavailable event is reported. If the object went out of service because another object that this object depended on has became unavailable, the name of the other object should be in the event message.
Standard Events Object Name for a Group of Objects If non-File System FILE_OPEN_ is used to establish communication with the underlying object (for example, using the operating system Message System), all the names used should be the name for the underlying object. One or more tokens in the event can represent the names.
Standard Events Detailed Description of Standard Events name in the token is a group. This style of group naming is consistent with the second level of support for object template naming used by communication subsystems internally at HP. The wild-card format is allowed because it is an established way for naming a group of objects by certain subsystems. The new token identifier format is allowed because not all objects use the wild-card naming scheme.
Standard Events Common-Standard Tokens That EMS Provides “C” means the token is a conditional token and must be provided if the specified condition applies; if the token is not provided, the default meaning specified is to be associated with the absence of the token. Some tokens, for example ZEMS-TKNEMPHASIS and ZEMS-TKN-SUPPRESS-DISPLAY, are always in an event, even if you did not add or generate them. If you do not add or generate them, these tokens receive default values.
Standard Events Sender Process ID Common-Standard Tokens That EMS Provides ZEMS-TKN-NODENUM ZEMS-TKN-CPU ZEMS-TKN-PIN ZEMS-TKN-PROC-DESC ZEMS-TKN-USERID (ZSPI-TYP-INT2,U) (ZSPI-TYP-UINT,U) (ZSPI-TYP-UINT,U) (ZSPI-TYP-STRING,U) (ZSPI-TYP-BYTE-PAIR,U) The Expand system-number, CPU number, PIN, process descriptor, and user ID of the process reporting the event. These tokens reflect the sender only when WRITEREAD(X) is used to send the event to the collector.
Standard Events Common-Standard Tokens That Subsystems Provide Common-Standard Tokens That Subsystems Provide These tokens are defined by HP but provided by subsystems and applications when they create the event message. These tokens are required in all event messages. Unconditional token types are identified with a “U;” conditional token types are identified with a “C.
Standard Events Event Subject Common-Standard Tokens That Subsystems Provide marked by ZEMS-TKN-SUBJECT-MARK (ZSPI-TYP-MARK,U) Identifies the objects that are most directly involved in the event. The token following the token ZEMS-TKN-SUBJECT-MARK is the subject name.
Standard Events Manager Name Common-Standard Tokens That Subsystems Provide ZEMS-TKN-NAME-MANAGER (ZSPI-TYP-STRING,C) Identifies the manager process for objects in the event subject. It must be in \node.$process form. If this token is present, it is the name of the process where commands can be sent to inquire or control the object reported in the event subject. If this token is not present: If the event subject is a process name, the process name is the \node.
Standard Events Standard Content Type Common-Standard Tokens That Subsystems Provide ZEMS-TKN-CONTENT-STANDARD (ZSPI-TYP-ENUM,C) Indicates the type of standard event.
Standard Events Critical Indicator Common-Standard Tokens That Subsystems Provide ZEMS-TKN-EMPHASIS (ZSPI-TYP-BOOLEAN,C) Indicates the critical nature of the condition reported in the event. Standard values are: ZSPI-VAL-TRUE indicates event is critical. ZSPI-VAL-FALSE indicates event is not critical (default).
Standard Events Object Available Event Tokens Object Available Event Tokens An Object Available event must be generated for a subsystem or application object whenever the object becomes available. The subsystem or application (or its manager process) that controls the object is responsible for reporting this event. This event should be reported as soon as the object becomes available, including at system and application startup time. The subject of this event is the object that became available.
Standard Events Object Other State Change Event Tokens Object Other State Change Event Tokens An Object Other State Change event must be reported for a subsystem or application object whenever the object enters a state, other than object available or unavailable, with these qualities: Requires operator intervention before its state can change Persists in the same state long enough for the operator to notice The subsystem or application (or its manager process) that controls the object must report t
Standard Events Object Unavailable Event Tokens The subject of this event is the object that has became unavailable. If multiple objects went out of service for the same reason, these objects can be represented by lists or group names. For more information about the use of this event, see Object State Monitoring Functions on page 9-4 and Reactive Problem Management Functions on page 9-5. These event-specific tokens are to be provided in addition to the common-standard tokens.
Standard Events Symptom String Object Unavailable Event Tokens ZEMS-TKN-SYMPTOM-STRING (ZSPI-TYP-STRING,C) Identifies where in the subsystem code the fault occurred. The information should point to a specific subsystem code location, and the information should remain unchanged for the same symptom from release to release of the program code. The purpose is to use this symptom string to help determine if a problem with similar symptoms has been reported previously.
Standard Events Operator Attention Completed Event Tokens Operator Attention Completed Event Tokens (This event was known as an action event prior to standard events.) An Operator Attention Completed event must be reported by a subsystem or application whenever the request from an earlier Operator Attention Needed event has been completed. The subsystem or application that reported the Operator Attention Needed event is responsible for reporting this event.
Standard Events Transient Fault Event Tokens The subsystem or application (or its manager process) that needs the attention of the operator is responsible for reporting this event, and for providing the cause, effect, and recovery text of this event to the operator. The subject of this event is the resource, such as tape or printer, that needs attention. The name of the resource should be a fully qualified operating system name. Only one resource per event should be specified.
Standard Events Usage Threshold Event Tokens For more information about the use of this event, see Requirements for Standard Events on page 9-3 and Proactive Problem Management Functions on page 9-8. These event-specific tokens must be provided in addition to the common-standard tokens. Unconditional token types are identified with a “U.” Type of Fault ZEMS-TKN-TXFAULT-TYPE (ZSPI-TYP-ENUM,U) Enumerated values are defined by subsystems, and they must be greater than or equal to ZEMS-VAL-MIN-USER-VALUE.
Standard Events Usage Threshold Event Tokens report_hi and report_low values, these objects can be represented by lists or group names. These event-specific tokens must be provided in addition to the common-standard tokens. Unconditional token types are identified with a “U;” conditional token types are identified with a “C.
Standard Events Usage Threshold Event Tokens Configured High Level to report ZEMS-TKN-UTIL-CONFIG-HI Configured Low Level to report ZEMS-TKN-UTIL-CONFIG-LOW Unit of Measure ZEMS-TKN-UTIL-UNIT (ZSPI-TYP-FLT,U) Identifies the configured usage value that triggers event generation when usage has exceeded this value. (ZSPI-TYP-FLT,U) Identifies the configured usage value that triggers event generation when usage has fallen below this value.
Standard Events Description of Standard EMS Templates Description of Standard EMS Templates Information in standard events is encoded by tokens, which are designed for programs and not intended for use by human operators. EMS templates are used to provide formatting instructions for the display of these tokens by operator console products like ViewPoint. This subsection defines a standard EMS template for each standard event.
Standard Events Object Other State Change Event Standard Template Object Other State Change Event Standard Template MSG: ZEMS-TKN-CONTENT-STANDARD, ZEMS-VAL-OTHER-STATE-CHANGE "(Other) State Change <31><32> - <31><33>" ", event number: <1>" ", reason: <2>" ", previous state: <3>" ", current state: <4>" "<*IF 21>, manager: <11><*ENDIF>" "<*IF 22>, batch ID: <12><*ENDIF>" "<*IF 23>, user content: <13><*ENDIF>" 1:ZEMS-TKN-EVENTNUMBER 2:ZEMS-TKN-CHANGE-REASON, ENUM 3:ZEMS-TKN-STATE-PREVIOUS ENUM 4:ZEMS-TKN-S
Standard Events Operator Attention Completed Event Standard Template Operator Attention Completed Event Standard Template Note. The Action ID token is not shared, which means it must always be qualified by the EMS SSID.
Standard Events Transient Fault Event Standard Template Transient Fault Event Standard Template MSG: ZEMS-TKN-CONTENT-STANDARD, ZEMS-VAL-TRANSIENT-FAULT "Transient Fault <31><32> - <31><33>" ", event number: <1>" ", fault type: <2>" "<*IF 21>, manager: <11><*ENDIF>" "<*IF 22>, batch ID: <12><*ENDIF>" "<*IF 23>, user content: <13><*ENDIF>" 1:ZEMS-TKN-EVENTNUMBER 2:ZEMS-TKN-TXFAULT-TYPE ENUM 11:ZEMS-TKN-NAME-MANAGER 12:ZEMS-TKN-BATCHJOB-ID 13:ZEMS-TKN-CONTENT-USER, ENUM 21:TOKENPRESENT(ZEMS-TKN-NAME-MANAGE
Standard Events Extensions to Standard Events 32:ZSPI-TKN-NEXTTOKEN, TOKENHEADING 33:ZSPI-TKN-NEXTTOKEN, TOKENVALUE Extensions to Standard Events Subsystem developers can make these extensions: Enhance the meaning of standard events Subsystem developers should provide extra tokens to a standard event if these tokens help describe the conditions reported by the subsystem. Subsystem developers could, but are not required to, extend the standard template to display these tokens.
10 Generating Standard Events This section describes how to generate standard events and provides an example of a fictitious subsystem to help subsystem developers design, define, build, and release event messages: Topic Page Task 1. Determine Your Subsystem ID and Acronym 10-2 Task 2. Analyze Your Subsystem Environment 10-2 Task 3. Generate Standard Events for Your Subsystem 10-6 Task 4. Define Private Event Types for Your Subsystem 10-9 Task 5. Migrate Existing Events 10-13 Task 6.
Generating Standard Events Task 1. Determine Your Subsystem ID and Acronym Task 1. Determine Your Subsystem ID and Acronym 1. Register your company name with HP. The company name is the Z-OWNER field (8-character) of your SSID. 2. Request a subsystem number and name from your subsystem number keeper. The subsystem number is the Z-NUMBER field (16-bit signed integer) of your SSID.
Generating Standard Events Task 2.1: Identify Types of Objects to Manage in Your Subsystem Provide automated recovery for your functions whenever possible.
Generating Standard Events Task 2.2: Identify the Characteristics of Your Objects Task 2.2: Identify the Characteristics of Your Objects 1. Define the names of each of your objects. Every object must be addressable within the network; that is, the object must have a name. A name is necessary because the object must be accessible separately from other objects in the subsystem. Both program and human interfaces should be able to determine the existence and name of any object.
Generating Standard Events Task 2.4: Identify the Events for Your Subsystem 1. Define the valid states of your object. 2. Define the valid transitions between these states. 3. Define the possible conditions (induced internally or externally to your subsystem) that cause each transition. 4. Define the actions for operators or your subsystem to take after the transition (for example, report an EMS event, or restart the object).
Generating Standard Events Task 2.5: Design Your Asynchronous Management Interface If a command and control interface does not exist for the object reported in your events, why generate the event? If no action can be taken on the object by a user or program, directly or indirectly, why generate the event? Task 2.
Generating Standard Events Task 3.1: Determine the Operational States of Your Objects and Subsystem Functions Operational State Event Type to Generate (page 2 of 2) Available Object Available Persistent Object Other State Change Need operator to change state Object Other State Change 2.
Generating Standard Events Task 3.2: Customize Your Standard Events Task 3.2: Customize Your Standard Events As needed for your subsystem, you can customize your standard events: For event type... Customize as follows: (page 1 of 2) Object Unavailable Identify which errors make the subject unavailable and where they originate (use ZEMS-TKN-FAILURE-CAUSE values).
Generating Standard Events Task 4. Define Private Event Types for Your Subsystem For event type... Customize as follows: (page 2 of 2) Usage Threshold Use the EMS_CHECK_USAGE_THRESHOLD_ procedure to determine if this type should be sent for each monitored usage: Operator Attention Needed/ Intervention Completed Transient Fault 1. Identify the object and kind of usage to monitor in each event. Consider all objects when selecting resources to monitor. 2.
Generating Standard Events Task 4.1: Determine Management Functions and If EMS Is the Appropriate Platform events, but it could provide a better focus for your existing events and might help identify enhancements to those events. Task 4.
Generating Standard Events Management Area Task 4.2: Specify Which Operations Are Defined for Your Management Functions Software Providing Function EMS Support? Effective delivery of the information system’s service to end users. Potential problems indicated by functions: performance monitoring analysis and tuning, accounting and billing, capacity planning, workload balancing, and network design.
Generating Standard Events Task 4.3: Specify the System Data Needed to Automate These Operations Data for Problem Detection and Isolation The operator needs to know that an object is no longer providing the services it was designed to provide (for example, a CPU or controller failed, or a software process ended abnormally).
Generating Standard Events Task 4.4: Specify the EMS Event Types for Your System Data Data for Problem Resolution To foster problem resolution, provide: Recommended action—the subsystem's best guess at how to correct the problem. This sometimes fixes the problem, but not always. It is difficult for a subsystem to determine the correct recovery action without having all the problem information. Manager process name—for the failed object.
Generating Standard Events Incorporating Old Events Into New Events Change the semantics of the event. Obsolete the event. Stop generating the event when the same conditions occur. Extend the event beyond the original recommended buffer size. For any external token, you cannot: Change the semantics and syntax of the token. Make the token obsolete (or delete it). Change the token name, literal value, or type of the token. Delete the literals defined for the values of the token.
Generating Standard Events Task 6. Design Your Event Messages 1. Add to your old event any common-standard tokens defined in Section 9, Standard Events, that are not already in your old event. 2. Classify your old event by assigning an event type to the event: Use the event types defined for the ZEMS-TKN-CONTENT-STANDARD or ZEMS-TKN-CONTENT-USER tokens whenever possible. If you define your own event types, you must define corresponding enumerated values for the ZEMS-TKN-CONTENT-USER token.
Generating Standard Events Task 6. Design Your Event Messages For guidelines for the ZEMS-TKN-SUPPRESS-DISPLAY token, see CommonStandard Tokens That Subsystems Provide on page 9-20. 4. Determine whether the manager process is relevant to the event. It is relevant only if your event contains the ZEMS-TKN-NAME-MANAGER token. 5. Define whether the event is standard or private: A standard event is an event defined in Section 9, Standard Events.
Generating Standard Events Task 7. Write Your Event External Specification How the operator must diagnose and resolve the reported problem (For example, take a trace, and then take the line down and restart it.) The cause, effect, and recovery information tells operators what to do with your events. Use as much detail as possible. You must include this information in Task 7. Write Your Event External Specification on page 10-17.
Generating Standard Events Task 7.3: List the Standard Management Functions Your Subsystem Supports Whether your subsystem interacts with processes from another subsystem either in the generation of your events or in the management of your subsystem. If so, describe these processes. Whether your subsystem depends on tokens and events defined by another subsystem. If so, briefly describe the subsystems and EMS files that you need (for example, ZSPIDDL, ZEMSDDL, and ZCOMDDL).
Generating Standard Events Task 7.4: Describe the Private Management Functions You Support Task 7.4: Describe the Private Management Functions You Support If your EMS events support nonstandard management functions, list them in your ES {3.2}. Create a new subsection {3.2.x} to describe each listed management function.
Generating Standard Events Task 7.8: Enumerate Your Private Values to Standard EMS Tokens Task 7.8: Enumerate Your Private Values to Standard EMS Tokens If you have private values for these tokens, define their values ss-VAL-valuename and list them under the token in your ES: ZEMS-TKN-CHANGE-REASON ZEMS-TKN-CONTENT-USER ZEMS-TKN-STATE-CURRENT ZEMS-TKN-STATE-PREVIOUS ZEMS-TKN-TXFAULT-TYPE ZEMS-TKN-UTIL-UNIT Task 7.
Generating Standard Events Task 7.11: Describe the Details of Each Event Message Describe the message text for the display of your event if different from the one provided by the standard template. You will need to provide your EMS template to describe this event text later. Cause description, effect description, recovery procedures Describe the cause, effect, and recovery procedures for the reported condition. This information is intended for the operator.
Generating Standard Events Task 8. Create and Build Your DDL Definitions Task 8. Create and Build Your DDL Definitions Create a DDL file for the DDL definitions for your events. Each subtask corresponds to a section of the same name in the sample file from which you create your definitions.
Generating Standard Events Task 8.4: Define Your External SSID Task 8.4: Define Your External SSID Specify the company name and the subsystem acronym assigned to your subsystem; for example, TANDEM.PWY.0 for the HP Pathway subsystem. Task 8.5: Specify Event Number Definitions ZEMS-TKNEVENTNUMBER Provide an 89 enumeration clause that briefly describes the type for each of your event types; for example, X25 line down.
Generating Standard Events Task 8.8: Specify Private Enumerations of Other Subsystems’ Tokens Make the enumeration clause 40 characters or fewer with no AS clause specifying the default display for this enumerated token. Use AS clauses in the individual level 89 items. This information is displayed by the standard template. Task 8.
Generating Standard Events Task 8.11: Define Private Tokens Determine whether your token is a simple or extensible structured token: A simple token contains a single field or multiple fields in a fixed structure. A simple token cannot be extended. Extension is done by adding other tokens. Use simple tokens whenever possible. An extensible structured (MAP) token is a structure that lets new fields be added in subsequent versions of the subsystem.
Generating Standard Events DDL DEF. Specify the DDL definition that defines the fields of your extensible structure token: Task 8.12: Compile Your DDL Definitions Name your definition as ss-DDL-structname. Define all your DDL definitions in one place in the common DDL structure definitions section. SSID clause. See Defining a Simple Token. HEADING clause. See Defining a Simple Token. NOVERSION or VERSION clause. If version is specified, it must be greater than the last version field used.
Generating Standard Events Task 10. Code and Test Your Event Generation Code assign the DDL definitions of your enumerations to these tokens so the standard templates can display them. 4. If you defined your own enumerations with 89 enumeration clauses to tokens from other subsystems, assign the DDL definitions of your enumerations to those tokens so they can be incorporated into the display by templates defined by you or by those other subsystems. 5.
Generating Standard Events Task 10.2: Build Your Event Message Buffer Use the FILE_OPEN_ procedure to open the primary or alternate collector process. Task 10.2: Build Your Event Message Buffer 1. If you are generating a usage threshold event: a. For each resource whose usage is to be reported, allocate a control block dedicated for that resource. Initialize the control block (only once) using the EMS_UTCB_INIT_ procedure. b. Call EMS_USAGE_THRESHOLD_CHK_ every time the usage level of a resource changes.
Generating Standard Events Task 10.3: Send Your Event Message Buffer to the EMS Collector Required Common Token Default Value (page 2 of 2) ZEMS-TKN-CONTENTUSER ZEMS-VAL-NULL unless specified by the corresponding optional parameter in the EMS_COMMON_TOKENS_EVT_BLD_ procedure ZEMS-TKN-EMPHASIS ZSPI-VAL-FALSE unless specified by the corresponding optional parameter in the EMS_COMMON_TOKENS_EVT_BLD_ procedure ZEMS-TKN-SUPPRESSDISPLAY ZSPI-VAL-FALSE Task 10.
Generating Standard Events Task 10.5: Test Your EMS Code The tokens you defined for your subsystem Include only the definitions in the programming language of your code. For information on how to include a definition file in your programming language, see the SPI Programming Manual. Get all HP provided tokens from the ZSPIDEF subvolume.
Generating Standard Events Task 11. Release and Distribute Your EMS Files Task 11. Release and Distribute Your EMS Files Release and distribute these EMS files you created (including your code modules that format and generate the events): Event/Token Definition Formatting Template ssssDDL ssssTMPL ssssC SidTMPL ssssCOB ssssTACL ssssTAL where ssss is your subsystem acronym and id is your three-character ID of the subsystem.
Generating Standard Events Objects to Be Managed Subsystem ZSAM provides network independent end-to-end reliable transport service for applications through the X.25 public and private data networks. Access to the X.25 network service is provided by another subsystem. Application 1 Application N File System interface Subdevice-1 Manager Subdevice-N Network independent end-to-end reliable transport service Tape (user profile) File System interface (another subsystem) X.
Generating Standard Events Event Subjects Event Subjects The corresponding subject names to the specified objects types are: Object Type Event Subject Name Subdevice slot (Not analyzed in this example) Local application (Not analyzed in this example) Transport connection ZSAM-TKN-subj-tp Underlying X.25 network service ZSAM-TKN-subj-netx25 User profile tape ZSAM-TKN-subj-tape Event Types ZSAM supports all standard management functions and generates all standard events that support them.
Generating Standard Events Subsystem States Previous Current State Transition Diagram and Events for ZSAMTKN-subj-netx25 EMS State Standard Event to Be Generated ZSAM Event Number Net down ->net up A Obj avail ZSAM-EVT-netx25-up Net up ->net reset A -- -- Net reset ->xreset A Tran fault ZSAM-EVT-netx25-dataloss Net reset ->net up A -- -- Net up ->net down U Obj unavail ZSAM-EVT-netx25-down (Not shown as a state, but while in “net up” state, the req queue for net svc is checked
Generating Standard Events State Transition Diagram and Events for ZSAMTKN-subj-tp State Transition Diagram and Events for ZSAM-TKN-subj-tp (5) Reset Xreset TP-RESET Connected (4) (4) (6) Disconnecting Xconn (3) (7) (2) Connecting (1) Avail (A) Unavail (U) Xdisk Disconnected initial state=net up state 012 Subsystem States Previous Current EMS State Standard Event to Be Generated ZSAM Event Number disconnected -> connecting U -- -- connecting -> xconn -> co
Generating Standard Events State Transition Diagram and Events for ZSAMTKN-subj-tape State Transition Reason Standard Token Values 1 Requested by local application State change event not generated 2 Rejected by remote TP or aborted by operator or local app State change event not generated (only Object Unavailable event) 3 Connecting takes > T2— persistent state ZEMS-TKN-STATE-STATE-PREVIOUS (ZSAM-VAL-): disconnected ZEMS-TKN-STATE-STATE-CURRENT (ZSAM-VAL-): connecting ZEMS-TKN-CHANGE-REASON (ZS
Generating Standard Events Private Tokens and Templates for Events Event-name (ZSAM-EVT-) Event-type (ZEMS-VAL-) (ZSAM-VAL-) Private tokens (ZSAM-TKN-) (ZSAM-MAP-) Private Templates? (page 2 of 2) netx25-up object-available -- No netx25-dataloss transient fault -- No netx25-util-req usage threshold -- tp-disconnected object-unavailable tp-diagcode Yes* tp-connected object-available -- No tp-x-conntime other-statechange No tp-x-reset transient-fault No tp-data-usage data-usage
Generating Standard Events Private Tokens and Templates for Events EMS Manual—426909-005 10-38
11 Procedure Calls for Standard Events This section describes procedure calls that help subsystems and applications format standard events: Topic Page Introduction to Procedure Calls 11-2 EMS_TRANSIENT_FAULT_EVT_BLD_ Procedure 11-2 EMS_OBJ_UNAVAIL_EVT_BLD_ Procedure 11-7 EMS_OBJ_AVAIL_EVT_BLD_ Procedure 11-13 EMS_OTHER_STATE_CHANGE_EVT_BLD_ Procedure 11-18 EMS_OPER_ATTN_NEEDED_EVT_BLD_ Procedure 11-23 EMS_OPER_ATTN_COMPED_EVT_BLD_ Procedure 11-27 Standard Usage Threshold Event 11-31 EMS_CO
Procedure Calls for Standard Events Introduction to Procedure Calls Introduction to Procedure Calls To generate a standard event, your subsystem must call the corresponding event-building procedure followed by a send procedure. One event-building procedure is provided for each of the standard event types. To generate common tokens only, use the EMS_COMMON_TOKENS_EVT_BLD_ procedure call.
Procedure Calls for Standard Events EMS_TRANSIENT_FAULT_EVT_BLD_ Procedure The syntax of EMS_TRANSIENT_FAULT_EVT_BLD_ is: { status := } { CALL } EMS_TRANSIENT_FAULT_EVT_BLD_( buffer ! , maxbuflen ! , SSID ! , Event number ! , Transient fault type ! , Subject token ID ! , Subject value ! , [ Subject length ] ! , [ Subject SSID ] ! , [ buflen ] ! , [ Critical indicator ] ! , [ Manager name:Manager name length ] ! , [ Job ID ] ! ); status i,o i i i i i i i i o i i:i i returned value INT:value returns on
Procedure Calls for Standard Events Event number EMS_TRANSIENT_FAULT_EVT_BLD_ Procedure input INT:value is a number, specific to this subsystem, that identifies this event message. Transient fault type input INT:value is the type of the transient fault. The value is defined by the caller and should be greater than or equal to ZEMS-VAL-MIN-USER-VALUE (1024). Subject token ID input INT(32):value is the token code of the subject of this event message. Subject value input STRING .
Procedure Calls for Standard Events Condition Code Settings If not present, the default is ZSPI-VAL-FALSE. Manager name input STRING .EXT:ref:* if present, is the name of the manager process of the object that received the transient fault. If present and Manager name length is not zero, Manager name is added to the event buffer. Otherwise, Manager name is not added to the event buffer. Manager name length input INT:value if present, is the length, in bytes, of the Manager name.
Procedure Calls for Standard Events Considerations Considerations To generate the common tokens: SSID: from SSID. Event subject token code: from Subject token ID Event subject value: from Subject value Event subject SSID: from Subject SSID Manager Name (zems-tkn-name-manager): from Manager name. Conditional. Event Number (zems-tkn-eventnumber): from Event number Standard Content type (zems-tkn-content-standard): ZEMS-VAL-TRANSIENT-FAULT. User Content type (zems-tkn-content-user): ZEMS-VAL-NULL.
Procedure Calls for Standard Events EMS_OBJ_UNAVAIL_EVT_BLD_ Procedure value point to the extra two bytes. Do not count the two-byte length field as part of the subject length. The subject of this event is the object that received the transient fault. The Subject value must be fully qualified so that it can be uniquely identified from any point in a network; for example, \nodename.$volume.subvolume.filename. Use EMSADDSUBJECT or EMSADDSUBJECTMAP to specify additional subjects.
Procedure Calls for Standard Events -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 EMS_OBJ_UNAVAIL_EVT_BLD_ Procedure Illegal parameter value Missing parameter Illegal parameter address Buffer full Invalid checksum Internal error Token not found Illegal token code or map Invalid subsystem ID Operation not supported Insufficient stack space buffer input, output INT .EXT:ref:* is the event-message buffer provided by the caller.
Procedure Calls for Standard Events EMS_OBJ_UNAVAIL_EVT_BLD_ Procedure ZEMS-VAL-INTERNAL-FAILED ZEMS-VAL-REASON-UNKNOWN Users can also enter their own defined values. Subject token ID input INT(32):value is the token code of the subject of this event message. Subject value input STRING .EXT:ref:* is the value of the subject to be added to the event message. Subject length input INT:value if present, is the length, in bytes, of the Subject value.
Procedure Calls for Standard Events Symptom string EMS_OBJ_UNAVAIL_EVT_BLD_ Procedure input STRING .EXT:ref:* if present, is a string that uniquely identifies the code location where the failure was found. If present and Symptom string length is not zero, Symptom string is added to the event buffer. Otherwise, Symptom string is not added to the event buffer. Symptom string length input INT:value if present, is the length, in bytes, of the symptom string.
Procedure Calls for Standard Events Condition Code Settings if present, is the job ID (for use by the NetBatch facility) that associates with the object that became unavailable. If Job ID is zero or not present, see Considerations on page 11-11. Condition Code Settings The condition code has no meaning following a call to EMS_OBJ_UNAVAIL_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID.
Procedure Calls for Standard Events If the Subject token ID has a variable-length value, choose one of these ways to specify the length: Considerations If the Subject length is present, the Subject length is the length, in bytes, of the Subject value. If the Subject length is not present, place the subject length in the two bytes that immediately precede the Subject value. Make the Subject value point to the extra two bytes. Do not count the two-byte length field as part of the subject length.
Procedure Calls for Standard Events EMS_OBJ_AVAIL_EVT_BLD_ Procedure EMS_OBJ_AVAIL_EVT_BLD_ Procedure The EMS_OBJ_AVAIL_EVT_BLD_ procedure formats the standard object available event. The event reports the object that became available.
Procedure Calls for Standard Events EMS_OBJ_AVAIL_EVT_BLD_ Procedure maxbuflen input INT:value is the length, in bytes, of the buffer, and cannot be greater than ZEMS-VAL-EVTBUFLEN (4024). SSID input INT .EXT:ref:6 is the ID of the subsystem that owns the object that is available. Event number input INT:value is a number, specific to this subsystem, that identifies this event message. Current state input INT:value is the current state of the object that became available.
Procedure Calls for Standard Events EMS_OBJ_AVAIL_EVT_BLD_ Procedure Subject length input INT:value if present, is the length, in bytes, of the Subject value. This parameter is ignored unless the Subject token ID is defined as a variable-length token. For more information, see Considerations on page 11-16. Subject SSID input INT .EXT:ref:6 if present, is the ID of the subsystem to which the Subject token ID belongs.
Procedure Calls for Standard Events Condition Code Settings Job ID input INT:value if present, is the job ID (for use by the NetBatch facility) that associates with the object that became available. If Job ID is zero or not present, see Considerations on page 11-16. Condition Code Settings The condition code has no meaning following a call to EMS_OBJ_AVAIL_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID.
Procedure Calls for Standard Events If the Subject token ID has a variable-length value, choose one of these ways to specify the length: Considerations If the Subject length is present, the Subject length is the length, in bytes, of the Subject value. If the Subject length is not present, place the subject length in the two bytes that immediately precede the Subject value. Make the Subject value point to the extra two bytes. Do not count the two-byte length field as part of the subject length.
Procedure Calls for Standard Events EMS_OTHER_STATE_CHANGE_EVT_BLD_ Procedure EMS_OTHER_STATE_CHANGE_EVT_BLD_ Procedure The EMS_OTHER_STATE_CHANGE_EVT_BLD_ procedure formats the standard other state change event.
Procedure Calls for Standard Events buffer EMS_OTHER_STATE_CHANGE_EVT_BLD_ Procedure input, output INT .EXT:ref:* is the event-message buffer provided by the caller. maxbuflen input INT:value is the length, in bytes, of the buffer, and cannot be greater than ZEMS-VAL-EVTBUFLEN (4024). SSID input INT .EXT:ref:6 is the ID of the subsystem that owns the object that had the state change. Event number input INT:value is a number, specific to this subsystem, that identifies this event message.
Procedure Calls for Standard Events Subject value EMS_OTHER_STATE_CHANGE_EVT_BLD_ Procedure input STRING .EXT:ref:* is the value of the subject to be added to the event message. Subject length input INT:value if present, is the length, in bytes, of the Subject value. This parameter is ignored unless the Subject token ID is defined as a variable-length token. For more information, see Considerations on page 11-21. Subject SSID input INT .
Procedure Calls for Standard Events Condition Code Settings Job ID input INT:value if present, is the job ID (for use by the NetBatch facility) that associates with the object that had the state change. If Job ID is zero or not present, see Considerations on page 11-21. Condition Code Settings The condition code has no meaning following a call to EMS_OTHER_STATE_CHANGE_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID.
Procedure Calls for Standard Events If the Subject token ID has a variable-length value, choose one of these ways to specify the length: Considerations If the Subject length is present, the Subject length is the length, in bytes, of the Subject value. If the Subject length is not present, place the subject length in the two bytes that immediately precede the Subject value. Make the Subject value point to the extra two bytes. Do not count the two-byte length field as part of the subject length.
Procedure Calls for Standard Events EMS_OPER_ATTN_NEEDED_EVT_BLD_ Procedure EMS_OPER_ATTN_NEEDED_EVT_BLD_ Procedure The EMS_OPER_ATTN_NEEDED_EVT_BLD_ procedure formats the standard operator attention needed event. The event reports the object and the needed operator action, such as mounting a tape or changing paper in a printer.
Procedure Calls for Standard Events maxbuflen EMS_OPER_ATTN_NEEDED_EVT_BLD_ Procedure input INT:value is the length, in bytes, of the buffer, and cannot be greater than ZEMS-VAL-EVT-BUFLEN (4024). SSID input INT .EXT:ref:6 is the ID of the subsystem that owns the object that needs operator attention. Event number input INT:value is a number, specific to this subsystem, that identifies this event message.
Procedure Calls for Standard Events buflen EMS_OPER_ATTN_NEEDED_EVT_BLD_ Procedure output INT:value if present, is the length, in bytes, of the formatted buffer. If the buffer cannot be built, zero is returned. Critical Indicator input BOOLEAN:value if present, is a Boolean variable that indicates the critical nature of the problem reported in the event. The literal ZSPI-VAL-FALSE (0) indicates the problem is not critical. Otherwise, the problem is critical.
Procedure Calls for Standard Events Condition Code Settings Condition Code Settings The condition code has no meaning following a call to EMS_OPER_ATTN_NEEDED_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID. Event subject token code: from Subject token ID Event subject value: from Subject value Event subject SSID: from Subject SSID. Conditional. Manager Name (zems-tkn-name-manager): Conditional. Event Number (zems-tkn-eventnumber): from Manager name.
Procedure Calls for Standard Events EMS_OPER_ATTN_COMPED_EVT_BLD_ Procedure If Job ID is not present or the value is zero, the procedure calls system procedure PROCESS_GETINFO_ to get the job ID. If the job ID obtained is nonzero, the job ID is added to the event buffer. Otherwise, the job ID is not added to the event buffer. The nonzero job ID obtained from calling PROCESS_GETINFO_ is the NetBatch job ID associated with the process that calls this EMS event-building procedure.
Procedure Calls for Standard Events EMS_OPER_ATTN_COMPED_EVT_BLD_ Procedure -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 Illegal parameter value Missing parameter Illegal parameter address Buffer full Invalid checksum Internal error Token not found Illegal token code or map Invalid subsystem ID Operation not supported Insufficient stack space buffer input, output INT .EXT:ref:* is the event-message buffer provided by the caller.
Procedure Calls for Standard Events Subject length EMS_OPER_ATTN_COMPED_EVT_BLD_ Procedure input INT:value if present, is the length, in bytes, of the Subject value. This parameter is ignored unless the Subject token ID is defined as a variable-length token. For more information, see Considerations on page 11-30. Subject SSID input INT .EXT:ref:6 if present, is the ID of the subsystem to which the Subject token ID belongs.
Procedure Calls for Standard Events Condition Code Settings if present, is the job ID (for use by the NetBatch facility) that associates with the object that no longer needs operator attention. If Job ID is zero or not present, see Considerations on page 11-30. Condition Code Settings The condition code has no meaning following a call to EMS_OPER_ATTN_COMPED_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID.
Procedure Calls for Standard Events Standard Usage Threshold Event If Job ID is not present or the value is zero, the procedure calls system procedure PROCESS_GETINFO_ to get the job ID. If the job ID obtained is nonzero, the job ID is added to the event buffer. Otherwise, the job ID is not added to the event buffer. The nonzero job ID obtained from calling PROCESS_GETINFO_ is the NetBatch job ID associated with the process that calls this EMS event-building procedure.
Procedure Calls for Standard Events Implementation Configured_High_Level: Defines the value that the usage variable must reach or exceed in order to generate the event. Configured_High_Level_switch: A Boolean variable that controls whether the event is to be generated when the usage reaches the Configured_High_Level value. Configured_Low_Level: Defines the value that the usage variable must fall to or below in order to generate the event.
Procedure Calls for Standard Events EMS_UTCB_INIT_ A usage threshold control block is allocated by the caller for each object whose utilization level is to be monitored. The usage threshold control block is used by the three procedures to keep information about the Configured_High_Level, Configured_Low_Level, Configured_High_Level_switch, Configured_Low_Level_switch, Current utilization level, Previous utilization level, Previous timestamp, and Internal status.
Procedure Calls for Standard Events EMS_UTCB_INIT_ Usage Threshold Control Block input, output INT .EXT:ref:20 is the control block used by subsequent calls to EMS_USAGE_THRESHOLD_CHK_ and EMS_USAGE_THRESHOLD_EVT_BLD_. Configured High Level input FLOAT:value is the configured high usage level used in calculating whether a Usage Threshold event should be generated.
Procedure Calls for Standard Events EMS_USAGE_THRESHOLD_CHK_ Considerations The caller should provide enough space (20 words) for Usage Threshold Control Block, and the content should not be modified by the caller. EMS_USAGE_THRESHOLD_CHK_ The EMS_USAGE_THRESHOLD_CHK_ procedure returns whether a standard usage threshold event should be generated.
Procedure Calls for Standard Events EMS_USAGE_THRESHOLD_EVT_BLD_ Considerations If EMS_USAGE_THRESHOLD_CHK_ returns 0 and report event returns ZSPIVAL-TRUE, the user should call EMS_USAGE_THRESHOLD_EVT_BLD_ to generate the standard usage threshold event. Otherwise, the user should not generate the standard usage threshold event. The caller should not modify the content of the Usage Threshold Control Block.
Procedure Calls for Standard Events buffer EMS_USAGE_THRESHOLD_EVT_BLD_ input, output INT .EXT:ref:* is the event-message buffer provided by the caller. maxbuflen input INT:value is the length, in bytes, of the buffer and cannot be greater than ZEMS-VAL-EVTBUFLEN (4024). SSID input INT .EXT:ref:6 is the ID of the subsystem that owns the object whose usage is being reported. Event number input INT:value is a number, specific to this subsystem, that identifies this event message.
Procedure Calls for Standard Events EMS_USAGE_THRESHOLD_EVT_BLD_ Subject SSID input INT .EXT:ref:6 if present, is the ID of the subsystem to which the Subject token ID belongs. If not present or the value is all zeros, the default SSID (specified in SSID) is assumed. In this case, the Subject SSID is not added to the event buffer. buflen output INT:value if present, is the length, in bytes, of the formatted buffer. If the buffer cannot be built, zero is returned.
Procedure Calls for Standard Events EMS_USAGE_THRESHOLD_EVT_BLD_ Condition Code Settings The condition code has no meaning following a call to EMS_USAGE_THRESHOLD_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID. Event subject token code: from Subject token ID Event subject value: from Subject value Event subject SSID: from Subject SSID. Conditional. Manager Name (zems-tkn-name-manager): name.Conditional.
Procedure Calls for Standard Events EMS_USAGE_THRESHOLD_EVT_BLD_ If Job ID is not present or the value is zero, the procedure calls system procedure PROCESS_GETINFO_ to get the job ID. If the job ID obtained is nonzero, the job ID is added to the event buffer. Otherwise, the job ID is not added to the event buffer. The nonzero job ID obtained from calling PROCESS_GETINFO_ is the NetBatch job ID associated with the process that calls this EMS event-building procedure.
Procedure Calls for Standard Events Usage Threshold Programming Example Usage Threshold Programming Example This C example illustrates how the standard usage threshold event is reported: /* * External declarations */ #pragma RUNNABLE #pragma NOXMEM #include #include #include #include #include nolist #include nolist #include nolist nolist nolist nolist
Procedure Calls for Standard Events Usage Threshold Programming Example float config_high_level = 0; float config_low_level = 0; short util_unit = ZEMS_VAL_UTIL_UNIT_PERCENT; float current_util_level = 0; short result; short myap_evt_usage_threshold = 108; char line_name[LINE_NAME_LEN] = "value of the subject short zcom_ssid[6]; char token_value[TOKEN_LENGTH] = "token value "; short status; short coll_name_len = sizeof(coll_name) - 1; "; strncpy(myap_ssid.u_z_filler.
Procedure Calls for Standard Events Usage Threshold Programming Example */ , usage_threshold_cb /* usage threshold control block */ , , , , , ZCOM_TKN_SUBJ_LINE line_name LINE_NAME_LEN zcom_ssid buf_len /* subject token id */ /* subject value */ /* subject length */ /* subject ssid */ /* return actual buffer length */ , ZSPI_VAL_TRUE )) /* return actual buffer length */ handle_error_usage_threshold(status); /* Add additional tokens if needed */ if ( status = EMSADDTOKENS ( buffer ,/* ssid */ ,MYAP_TK
Procedure Calls for Standard Events EMS_COMMON_TOKENS_EVT_BLD_ Procedure EMS_COMMON_TOKENS_EVT_BLD_ Procedure The EMS_COMMON_TOKENS_EVT_BLD_ procedure builds the common tokens required in all subsystem-defined events.
Procedure Calls for Standard Events EMS_COMMON_TOKENS_EVT_BLD_ Procedure is the length, in bytes, of the buffer. It cannot be greater than ZEMS-VAL-EVTBUFLEN (4024). SSID input INT .EXT:ref:6 is the ID of the subsystem originating the event. Event number input INT:value is a number, specific to this subsystem, that identifies this event message. User Content type input INT:value is a number that identifies the type of a subsystem-defined event.
Procedure Calls for Standard Events EMS_COMMON_TOKENS_EVT_BLD_ Procedure If not present or the value is all zeros, the default SSID (specified in SSID) is used. In this case, the Subject SSID is not added to the event buffer. buflen output INT:value if present, is the length, in bytes, of the formatted buffer. If the buffer cannot be built, zero is returned. Critical Indicator input BOOLEAN:value if present, is a Boolean variable that indicates the critical nature of the problem reported in the event.
Procedure Calls for Standard Events Condition Code Settings Condition Code Settings The condition code has no meaning following a call to EMS_COMMON_TOKENS_EVT_BLD_. Considerations To generate the common tokens: SSID: from SSID Event subject token code: from Subject token ID Event subject value: from Subject value Event subject SSID: from Subject SSID Manager Name (zems-tkn-name-manager): Conditional. Event Number (zems-tkn-eventnumber): from Manager name.
Procedure Calls for Standard Events If the Subject token ID has a variable length, choose one of these ways to specify the length. Procedure for Sending Events If the Subject length is present, the Subject length is the length, in bytes, of the Subject value. If the Subject length is not present, place the subject length in the two bytes that immediately precede the Subject value. Make the Subject value point to the extra two bytes.
Procedure Calls for Standard Events Program Example #include #include #include "$dsv.Zspidef.ZSPIC" #include "$dsv.Zspidef.ZEMSC" #include "$dsv.Zspidef.
Procedure Calls for Standard Events Program Example { /* Build the event buffer by calling EMS_OBJ_UNAVAIL_EVT_BLD_ */ if ( status = EMS_OBJ_UNAVAIL_EVT_BLD_ ( event_buf ,ZEMS_VAL_EVT_BUFLEN ,(short *)&myap_ssid /*subsystem identifier ssid */ ,myap_evt_obj_unavail /* event number */ ,current_state ,previous_state ,ZEMS_VAL_OPERATOR_INITIATED /* change reason */ ,ZCOM_TKN_SUBJ_LINE /* subject token id */ ,subject_value /* value of the subject to be added */ ,SUBJECT_LEN , /* subject ssid */ , /* underlying
Part IV: Configuring and Maintaining EMS This part of the manual provides procedures and supplemental information for the configuration and routine use of EMS: Section 12, Configuring EMS Section 13, EMS Programs Section 14, EMS Definitions Section 15, EMS Procedures Section 16, Event Routing EMS Manual—426909-005
Part IV: Configuring and Maintaining EMS EMS Manual—426909-005
12 Configuring EMS This section describes the major components of EMS and their characteristics. This information will help you make decisions about configuring EMS components to meet your network and system management requirements. Topic Description Page Basic Attributes of EMS Components Some EMS components characteristics are fixed; you cannot change them. Others are variable.
Configuring EMS Primary Collectors Figure 12-1. Relationship Between EMS Components Alternate Collectors Primary Collector ($0) Filters Filters Log Files Forwarding Distributor Compatibility Distributor ($Z0) Log Files Consumer Distributor Printing Distributor VST006.vsd Primary Collectors Each system must have one, and only one, primary collector process, named $0. The primary collector process is configured during system generation and is started when the system is loaded.
Configuring EMS Log Files An alternate collector can run as a process pair, or it can run without a backup. Each alternate collector has a unique name, defined when the collector is started. An alternate collector is started by a TACL RUN command or by another process. The attributes associated with each alternate collector govern only the operation of that collector.
Configuring EMS Log Files $SYSTEM.SYSTEM.ZZEVCONF as a context file. The context data in this file is used after a system load or log file failure. $SYSTEM.ZLOGnn.ZZEV0000 as a log file. This file receives the first event messages logged after the system comes up. $SYSTEM.ZLOGnn.ZZEVCONF as a context file. A configuration file (ZZEVCONF) is always present on the subvolume that contains the log files. For a more complete description of the ZZEVCONF files, see Log File Operation on page 12-23.
Configuring EMS Log Files If you do not specify the log subvolume, the alternate collector looks for a default subvolume (DEFAULTSUBVOL) specification on the TACL RUN command. If the collector finds a default subvolume specification, it uses this as the log subvolume. If it does not find a default subvolume specification, it uses the value =_DEFAULTS. Log subvolumes cannot be shared. The log subvolume containing the log files of one collector cannot contain log files for any other collector.
Configuring EMS Log Files Alternate collector attributes have default values assigned by the collector when you start the collector, unless you include a value for an attribute as a RUN command parameter. You can change the value of most log file and collector attributes after a collector is running by using the SPI CONTROL command or the EMSCCTRL program. Table 12-1.
Configuring EMS Log Files written to the log file. Blocking of events also reduces the number of message system write requests. Setting this attribute to ON makes the collector block event messages before writing them to the log file. Default value for the primary and alternate collectors is ON. The EMSCCTRL program can dynamically change the event blocking mode.
Configuring EMS Log Files by the collector. For instance, if MAXFILE is 4 (the default), the files at a given time might be ZZEV0007, ZZEV0008, ZZEV0009, and ZZEV0010. File ZZEV0010 would be the active file. Allowable values for MAXFILE are 2 through 1000. This attribute value is saved in ZZEVCONF. To change the value of this attribute, issue the SPI CONTROL command or run the EMSCCTRL program.
Configuring EMS Log Files PROTECTION This attribute defines the file protection (read, write, execute, and purge) assigned to disk files when they are created or renamed. This attribute is saved in the ZZEVCONF file. It has a default value of COOO. To change this attribute, issue the SPI CONTROL command or run the EMSCCTRL program. REPLYAFTERWRITE (Alternate Collector only) This attribute determines when the alternate collector replies to event issuers.
Configuring EMS Log Files SECONDARYEXTENT This attribute establishes the value for the secondary extent size (number of pages) to be used when a log file is created by a primary or alternate collector. Even-numbered values in the range 2 through 65534 are allowed. The setting of this attribute is saved in the ZZEVCONF file. SECONDARYEXTENT has a default value of 100. To change the value of this attribute, issue the SPI CONTROL command or run the EMSCCTRL program.
Configuring EMS Log Files Running primary or alternate collector—dynamically using the FILTER (PLF) and SUPPRESS (BDS) keyword parameters of the EMSCCTRL program New alternate collector—using the SUPPRESS and FILTER keyword parameters of the EMSACOLL program Using the appropriate collector command (ZCOM-CMD-ADD, ZCOM-CMDDELETE, ZEMS-CMD-REPLACE) to add, delete, or replace a pre-log filter or burst filter FILTER This attribute identifies the current state of pre-log filtration (PLF) for the collect
Configuring EMS Consumer, Forwarding, and Printing Distributors Consumer, Forwarding, and Printing Distributors Event-message distributors let you choose event messages from one or more log files by using a filter and route these messages to an appropriate destination.
Configuring EMS Consumer, Forwarding, and Printing Distributors Starting a Distributor You control whether a distributor runs as a process pair by specifying or omitting the BACKUP option when you issue the TACL command to start the distributor. When you start a distributor, you must specify the distributor type. You can also provide several additional items of information. The distributor startup parameters are: Distributor type.
Configuring EMS Compatibility Distributor ($Z0) specified. The value can include both the date and time or just the time. The time value is assumed to represent local civil time. If you do not specify a value for the TIME option, the effect depends on whether you have specified COLLECTOR or LOGFILE (that is, whether you are accessing the current collector log or a saved log file). If you specified COLLECTOR, eventmessage processing starts with the next incoming event message.
Configuring EMS Other EMS Components $Z0 writes event messages to a console in DSM display format. For D-series RVUs, you can use PUP LISTDEV and PUP PRIMARY; of the PUP CONSOLE commands, you can only use the CONSOLE device command. Note. Block mode applications cannot be started on the current $0 CONSOLE device. Attempting to start a block mode application, such as ViewSys or TEDIT, results in an error 549.
Configuring EMS Configuration Issues Configuration Issues One of the difficulties in configuring systems and networks is that each decision requires a balance between two system characteristics. For example, higher performance must often be weighed against its cost in resource consumption or in potential loss of data integrity. While not showing you how to avoid such trade-offs, this subsection describes some of the implications of decisions you might make in configuring EMS components.
Configuring EMS Logging Integrity efficiently, but they are logged on only one node (the local node), and they need not be processed by all the other distributors at the remote node. On the other hand, a remote management application communicating with a local consumer distributor must detect and recover from network errors, whereas a forwarding distributor transmitting event messages to the remote node would assume that burden.
Configuring EMS Logging Integrity The CPU in which the event message was generated fails before the message can be delivered to the appropriate collector. (EMS cannot prevent this.) A collector’s log-file space is inadequate. This occurs when a combination of these attribute settings causes log files to fill up too fast: ROTATEFILES is FALSE. MAXFILE is too small. PRIMARYEXTENT, SECONDARYEXTENT, or both are too small.
Configuring EMS Delivery Integrity collector cannot then keep up with the peak logging demand. Setting BLOCKING to ON increases the maximum sustained logging rate of the primary and alternate collectors by a factor of two.) Verify that subsystems are generating only the event messages they are supposed to generate (for example, check that no subsystem is in a loop). Verify that the filters used by forwarding distributors are selecting only the desired event messages.
Configuring EMS Reliability Reliability Almost all EMS processes run as process pairs, reducing the possibility that a singlecomponent failure can cause a process to fail. A primary collector always runs as a process pair; an alternate collector can run as a process pair; a compatibility distributor runs as a process pair if it is initiated by a system load or by a RUN command with the BACKUP parameter included.
Configuring EMS Installation and System Generation Considerations Installation and System Generation Considerations Only a few EMS components have operating characteristics you must consider during system generation: the primary collector, the compatibility distributor (optionally), and the template files. Other components such as code files and definition files only need to be copied to a convenient location. For more information about EMS system generation, see the System Generation Manual.
Configuring EMS The Compatibility Distributor ($Z0) If you omit the XPOOLPAGES parameter or the entire paragraph from the configuration file, the primary collector buffer has 50 pages of resident extended memory. If the file includes XPOOLPAGES, you can set n to any decimal numeral from 35 through 128; if you set n outside that range, the buffer has 128 pages. After system generation, the value of n does not change until someone changes it and another system generation takes place.
Configuring EMS Template Files If you omit the EMSFLAGS parameter or the entire paragraph from the configuration file, the default selection criterion for $Z0 is CRITICAL-ONLY ON.
Configuring EMS Collector Context The primary collector must have a default subvolume in which to log event messages when other subvolume information is not available or has not yet been provided. The default subvolume is $SYSTEM.ZLOGnn. The default subvolume is used to initialize the LOGSUBVOL attribute at system load; it is also used when the current log subvolume becomes inaccessible because of a disk problem.
Configuring EMS Primary Collector Logging After a System Load See the FILTER (PLF) and SUPPRESS (BDS) process attribute descriptions in Collector Process Attributes on page 12-10. Primary Collector Logging After a System Load When primary collector logging starts after a system load, the collector must determine where to start logging event messages. It continues logging in the previous log file, if one existed, or creates a new log file if it determines no previous logging took place.
Configuring EMS Primary Collector Logging After a System Load Figure 12-4. Determining Log-File Names After a System Load Cold Load Does file $SYSTEM.ZLOGnn.ZZEVCONF exist? Yes No Is first record a file switch event message? Yes No Assume no previous logging took place. Create $SYSTEM.ZLOGnn.ZZEV0000 and start logging in this file. Assume previous logging took place. Get previous log file name (for example, ZZEVnnnn). Is this name the same as the one in $SYSTEM.SYSTEM.
Configuring EMS Logging After a Subvolume Switch ROTATEFILES = TRUE MAXFILE = 4 PROTECTION = COOO DISCACCESSID = SUPER.SUPER BLOCKING = ON These attributes can be changed programmatically by sending a CONTROL command message, or interactively by using the EMSCCTRL utility program. The maximum number of extents is always 16.
Configuring EMS Switching Log Files Switching Log Files All tasks associated with log switches are performed when the collector is idle (that is, when there are no events to log). When a log file is full, or when you request a log-file switch by setting the NEXTLOGFILE option, the collector: Determines the name of the next log file. The name of the next file is derived by adding one to the integer portion of the file name of the current log file.
Configuring EMS Switching Log Files you need that specific file (for example, when you have a scheduled log-file archival routine or when a serious problem is detected and you want to isolate that log file).
Configuring EMS Switching Log Files EMS Manual—426909-005 12-30
13 EMS Programs This section describes the programs you can run to change the configuration of or display status information about various EMS components: Topic Page EMSACOLL—Alternate Collector Program 13-2 EMSCCTRL—Control Collector Utility 13-9 EMSCINFO—Collector Information Utility 13-18 EMSDINFO—Distributor Information Utility 13-29 EMSDIST—Distributor Program 13-34 To start and stop these EMS programs, use the TACL RUN and STOP commands. Table 13-1.
EMS Programs EMSACOLL—Alternate Collector Program EMSACOLL—Alternate Collector Program EMSACOLL is the object program for the alternate collector. The alternate collector provides an alternative to the primary collection point made available by the primary collector ($0). You can start an alternate collector by using the TACL RUN command. You can pass attribute information to the collector as startup text to define the operational characteristics of the collector.
EMS Programs EMSACOLL—Alternate Collector Program SUPPRESS [( suppression-parameters )] lets the default values for the burst detection and suppression parameters be overridden with user-specified values. Using the SUPPRESS keyword causes the alternate collector to start with BDS enabled. The absence of SUPPRESS causes BDS to be disabled at startup unless a burst filter is specified in the FILTER keyword.
EMS Programs EMSACOLL—Alternate Collector Program If any of the filters is bad or incorrectly identified, the alternate collector generates an appropriate error message and terminates. The error message specifies the first bad filter encountered. A bad filter is one that is not in the correct format or cannot be accessed. LOGPREFIX char lets the user specify a different prefix pattern for an alternate collector’s log files and the configuration file.
EMS Programs EMSACOLL—Alternate Collector Program If the oldest file is a valid file and not open to another process, the alternate collector either renames the file as the next in the sequence if it has the correct number of extents, or it purges and creates a new file if it does not have the correct number of extents. If ROTATEFILES is OFF (FALSE): The primary collector sends the event message ZEMS-EVT-LOGGINGSTOPPED (521) and stops logging. The alternate collector checks the oldest file.
EMS Programs Startup Error Messages SECURITY since the system load—which makes super-group membership a requirement for event-message retrieval. REPLYAFTERWRITE { ON | OFF} selects the value of the REPLYAFTERWRITE attribute. ALLOCATE causes the alternate collector to attempt to create and allocate MAXFILE files in the log subvolume.
EMS Programs Startup Error Messages Duplicate attribute Specification The named attribute has been specified more than once in the startup text. Extended Segment Allocation Error: file management error # The primary alternate collector process cannot allocate its extended data segment. Illegal BACKUP CPU The CPU specified as the backup does not exist or is the same CPU in which the primary process is running. Illegal Character - character The specified illegal character appeared in the startup text.
EMS Programs Startup Warning Messages Illegal Syntax - token The indicated token cannot legally appear where it does in the startup text. Startup Warning Messages If a warning condition is detected, the alternate collector issues a message on the home terminal and continues to run. It does not terminate abnormally as it does with startup error messages.
EMS Programs EMSCCTRL—Control Collector Utility EMSCCTRL—Control Collector Utility The EMSCCTRL utility lets you interactively manage the operation of the primary and alternate collectors and the operation of the compatibility distributor. EMSCCTRL supports a single input line from the TACL RUN command line. By supplying one or more parameters, you select the operational characteristics of the collector.
EMS Programs EMSCCTRL—Control Collector Utility col-options are one or more of these collector options, separated by commas: ALLOCATE (alternate collector only) if present, makes the alternate collector attempt to create or allocate MAXFILE files in the current log subvolume. The range of the log file numbers created or allocated is the same as that described in EMSACOLL—Alternate Collector Program on page 13-2. If ALLOCATE is specified with LOGSUBVOL, the allocation takes place in the new subvolume.
EMS Programs EMSCCTRL—Control Collector Utility CRITICAL-ONLY OFF $Z0 displays all messages. Note. Use the CDISTMODE option only with the primary collector. CDISTSTOP stops the compatibility distributor. Note. Use the CDISTSTOP option only with the primary collector. For more information about the CDISTSTOP option, see Installation and System Generation Considerations on page 12-21 and Compatibility Distributor ($Z0) on page 12-14. CDISTUSER usergroup.
EMS Programs EMSCCTRL—Control Collector Utility generates a “No Operation” message on its OUT file. If PLF is already enabled, FILTER ON has no effect on the collector. Specifying FILTER RESET disables PLF and causes the collector to delete any previously entered filters. If PLF is already disabled and the collector has no retained filters, FILTER RESET has no effect on the collector. The filter specified in the filter-name variable can be a compiled filter, a filter table, or a single burst filter.
EMS Programs EMSCCTRL—Control Collector Utility LOGUSERID usergroup.username specifies the user ID that the primary collector uses when it accesses its log files. The primary collector uses the super ID to access log files if you have never changed its user ID. If you change the user ID of the primary collector, use LOGUSERID to change the owner and/or security of the ZZEVCONF and log files so the new user ID has read/write/purge access to these files.
EMS Programs EMSCCTRL—Control Collector Utility REFRESH { ON | OFF } if ON, tells a primary or alternate collector to update the end-of-file pointer on disk for each block written. This is safer than REFRESH OFF, less efficient because it involves more writes to disk. ROTATEFILES { ON | OFF } tells the collector what action to take if the creation of a new log file causes the number of log files to exceed the MAXFILE limit by assigning the value of the ROTATEFILES attribute.
EMS Programs EMSCCTRL—Control Collector Utility retrieve event messages. If you have not specified SECURITY after a coldload, or if the collector does not find a ZZEVCONF file in the default or system subvolume, the system supplies “COOO” to make super-group membership a requirement for event-message retrieval.
EMS Programs EMSCCTRL—Control Collector Utility SWITCH { COLL cpu } { CDIST cpu } designates which process of a process pair is to become the primary process. You specify the process by its CPU number, which must designate the processor in which the backup process is currently running. (You specify cpu so two attempts to switch primary processes out of CPU 7, for example, do not cancel each other. The first attempt succeeds; the second attempt gets an error but is otherwise ignored.) Note.
EMS Programs Referencing Collector Attributes Referencing Collector Attributes Table 13-3.
EMS Programs EMSCINFO—Collector Information Utility EMSCINFO—Collector Information Utility The EMSCINFO utility returns status information about a primary or alternate collector. For a description of the command message that provides the same information, see STATUS Command (ZEMS-CMD-STATUS) on page 19-53. To change these attributes, see EMSCCTRL—Control Collector Utility on page 13-9.
EMS Programs Definition of Terms Example 13-2 shows the alternate collector status display produced by EMSCINFO in response to the command “EMSCINFO $ACOL,” without the DETAIL option specified. The EMSCINFO display for an alternate collector differs from the display for the primary collector in these ways: The values of POOLPAGES and REPLYAFTERWRITE are displayed. No compatibility distributor information is displayed. Example 13-2.
EMS Programs Definition of Terms Term Description (page 2 of 4) Current Record Record number (as received from the FILEINFO procedure) of the last record written to the log file if the collector is not switching log files. *** Switching to next file *** Displayed in place of the current record if the collector is in the process of switching log files. Default Log File File name of the last file in use in the default subvolume. Primary Extent Size of the primary extent used for log-file creation.
EMS Programs Definition of Terms Term Description (page 3 of 4) Unrcv Disk Errors Total number of unrecoverable disk errors returned to the collector by the disk process since the last system load. Operational errors are excluded from this total. These are operational errors: 010 MAXFILE files already exist 043 Unable to obtain disc space for file extent 044 Disc directory or DCT is full Invalid Events Total number of event messages that the collector discarded because of event-message format errors.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) Term Description (page 4 of 4) Console Name Name of the operator console to which the compatibility distributor sends event messages. If different from the default console name, the console was selected after SYSGEN using one of: The PUP CONSOLE command (on a D-series RVU). The EMSCCTRL utility (keyword TEXTOUT); see EMSCCTRL—Control Collector Utility on page 13-9.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) Example 13-3. EMSCINFO Detail Display (SUPPRESS ON, FILTER OFF) EMSCINFO - T9631D31 - (03APR95) Collector = $0, Priority Primary CPU = 1, Backup CPU Disk Logging Active Current Log File = $SYSTEM.ZLOG06.ZZEV0045 Current Record = %000005.050003 Default Log File = $SYSTEM.ZLOG06.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) The EMSCINFO detail display example in Example 13-3 provides this information about burst detection and suppression (BDS): The SUPPRESS function is set to ON for the primary collector through the SUPPRESS keyword of the EMSCCTRL command (SUPPRESS ON). Therefore, burst detection and suppression is currently enabled for the primary collector. The current BDS configuration values and their meanings are listed.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) Example 13-4. EMSCINFO Detail Display (SUPPRESS ON, FILTER ON) EMSCINFO - T9631D31 - (03APR95) Collector = $0, Priority Primary CPU = 1, Backup CPU Disk Logging Active Current Log File = $SYSTEM.ZLOG06.ZZEV0045 Current Record = %000005.050003 Default Log File = $SYSTEM.ZLOG06.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) The EMSCINFO detail display example in Example 13-4 provides this information about burst detection and suppression (BDS): The SUPPRESS function is set to ON for the primary collector through the SUPPRESS keyword of the EMSCCTRL command (SUPPRESS ON). Therefore, burst detection and suppression for the primary collector was enabled using the SUPPRESS ON command.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) Example 13-5. EMSCINFO Detail Display (SUPPRESS OFF, FILTER ON) EMSCINFO - T9631D31 - (03APR95) Collector = $0, Priority Primary CPU = 1, Backup CPU Disk Logging Active Current Log File = $SYSTEM.ZLOG06.ZZEV0045 Current Record = %000005.050003 Default Log File = $SYSTEM.ZLOG06.
EMS Programs EMSCINFO Display Examples (With DETAIL Option) The EMSCINFO detail display example in Example 13-5 provides this information about burst detection and suppression (BDS): The SUPPRESS function is set to OFF for the primary collector using the SUPPRESS keyword of the EMSCCTRL command (SUPPRESS OFF). Therefore, burst detection and suppression for the primary collector has not been enabled using the SUPPRESS ON command.
EMS Programs EMSDINFO—Distributor Information Utility EMSDINFO—Distributor Information Utility The EMSDINFO utility returns status information about a specified distributor. Example 13-6 shows the format used by EMSDINFO. EMSDINFO distributor-name Example 13-6.
EMS Programs EMSDINFO—Distributor Information Utility To learn about command messages that provide distributor status information, see Distributor Command Descriptions on page 17-12. Term Description (page 1 of 3) VERSION HP version number with the release date. NAME Name of the distributor process. TYPE Type of distributor: CONSUMER, FORWARDING, or PRINTING PRIMARY CPU Number of the CPU in which the primary process of the distributor is currently running.
EMS Programs Term EMSDINFO—Distributor Information Utility Description (page 2 of 3) STATE One of these collector states: DISCONNECTED, WRITE PENDING, IDLE, or RETRYING ON ERROR. LOGFILE If present, name of the log file that is currently the sole source of event messages examined by this distributor. EOFDELAY Amount of time delay (in seconds/100) after detection of end of file (EOF) before reading the log again.
EMS Programs EMSDINFO—Distributor Information Utility Term Description (page 3 of 3) STATE One of these distributor states, which are associated with the named source collector: UNUSED, IDLE, FETCHING EVENTS, PERFORMING STATUS, POSITIONING, MAKING LOGNAME LIST, or DELAYING AFTER EOF.
EMS Programs EMSDINFO—Distributor Information Utility LAST ERROR Distributor error number that was last returned to a process communicating with the distributor programmatically. This line occurs only if such an error occurred. EVENTS FILTERED Number of event messages from all sources that have passed the filter since the last filter load. EVENTS TOTAL Total number of event messages from all sources that have been processed by the filter since the last filter load.
EMS Programs EMSDIST—Distributor Program EMSDIST—Distributor Program The EMSDIST program is the object program for a printing, forwarding, or consumer distributor, any of which you can start with a TACL RUN command. To access log-file messages, the person or process that runs EMSDIST must have read access to the log files that EMSDIST accesses. Super-group privileges are required if the collector creates its log files with the protection string COOO, which is the system default.
EMS Programs EMSDIST—Distributor Program error messages are sent to the home terminal. If a DEFINE is not specified, all distributor generated events except ZEMS^EVT^BURST^START and ZEMS^EVT^BURST^END are written to $0. The burst start and burst end messages are written to the distributor's OUT file, as specified in the EMSDIST run option, OUT. If the EMSDIST run option, OUT, is specified but does not match the hometerm, burst start and burst end messages are written to the OUT file as a text error list.
EMS Programs EMSDIST—Distributor Program As the distributor examines event messages, the event messages from the log files of every collector name in the COLLECTOR option are merged by eventmessage generation time. LOGFILE name is the name of a log file to serve as the unique source of event messages for this distributor. The LOGFILE option excludes use of the COLLECTOR option. FILTER { file-name } { ( file-name [ , file-name ] ...
EMS Programs EMSDIST—Distributor Program maxextent of 16 pages. A page contains 2048 bytes. Therefore, the created file can only store 655,530 bytes, which can fill up quickly. WAIT n overrides the two minute default timeout for all textout destinations specified to a printing distributor. n is given in seconds. If WAIT is specified, the distributor retries every n seconds, even if there is only one destination. If the textout is a routing destination, the event is skipped.
EMS Programs EMSDIST—Distributor Program time The time parameter has the form: hour : minute [ : second ] hour is a one-digit or two-digit integer minute is a one-digit or two-digit integer second is a two-digit integer For example, you can specify the time of day as 11:05:59 or 23:05. The TIME option specifies values in local civil time. STOP { date } { [ date ] time | EOF } is a positioning parameter used with the TIME option to specify a range of values to be examined by the distributor.
EMS Programs EMSDIST—Distributor Program For example, you can specify the time of day as 11:05:59 or 23:05. If the TIME option is omitted and the STOP time is smaller than the most current event, the distributor terminates. The STOP feature is available only as an option for the EMSDIST program, and not as a programmatic option. It is available exclusively for the printing and forwarding distributors, and not for the consumer distributor.
EMS Programs Startup Error Messages The distributor resends the last event that the consumer has received; that is, it positions by the context that it recorded last. INDENT n overrides the default indentation (36) for a printing distributor. n is the number of indention spaces. n must not be larger than the record size of the destination. GMT ON converts the local time back to GMT (Greenwich mean time) for printing distributors. Time is displayed in GMT instead of LCT (local civil time).
EMS Programs Startup Error Messages Recovery. If the distributor fails to start up, fix the specified problem with the collector. Can’t open textout textout-name, error error-number Cause. The targeted textout destination cannot be opened by the distributor. Effect. The distributor fails to start up. Recovery. Fix the problem with the specified textout. Comma missing Cause. A comma required by syntax has been omitted. Effect. The distributor fails to startup. Recovery.
EMS Programs Startup Error Messages Effect. The distributor fails to start up. Recovery. Specify only one burst filter. Duplicate filterfile name Cause. Two filters with the same name are specified. Effect. The distributor fails to start up. Recovery. Check that each filter has a unique name. Duplicate key word Cause. The same key word has been detected twice. Effect. The distributor fails to start up. Recovery. Eliminate the duplicate keyword. Duplicate textout Cause.
EMS Programs Startup Error Messages Recovery. Specify STOP EOF. Filterfile problem. Error: error-number, File: file-name Cause. The specified filterfile cannot be accessed. Effect. The distributor fails to start up. Recovery. Check the specified filterfile error. Filterfile read error: error-number, File: file-name Cause. The specified filterfile cannot be read. Effect. The distributor fails to start up. Recovery. Check the specified filterfile error. Filter allocation problem. File: file-name Cause.
EMS Programs Startup Error Messages Effect. The distributor fails to start up. Recovery. Correct the specified syntax or range error. Filter version mismatch Cause. The distributor does not support the version of the specified file. Effect. The distributor fails to start up. Recovery. Recompile the filter or use a distributor of a matching version. Incompatible event destination for this type of distributor Cause. The destination specified is not compatible with this type of distributor. Effect.
EMS Programs Startup Error Messages Effect. The distributor fails to start up. Recovery. Specify a valid EOF delay value. Invalid file name Cause. The specified file name contains extraneous characters. Effect. The distributor fails to start up. Recovery. Verify that you have accurately entered the specified file name. Invalid filterfile name Cause. The specified filter file is either invalid or does not exist. Effect. The distributor fails to start up. Recovery.
EMS Programs Startup Error Messages Recovery. Verify that you have provided a valid source collector name. Invalid system name for source collector Cause. The specified system name for the source collector is invalid. Effect. The distributor fails to start up. Recovery. Verify that you have specified a valid system name for the source collector. Invalid system name for target collector Cause. The specified system name for the target collector is invalid. Effect. The distributor fails to start up.
EMS Programs Startup Error Messages Recovery. Specify a valid textout wait time. Keyword not found Select from: TYPE, BACKUP, COLLECTOR, FILTER, LOGFILE, TARGET, TEXTOUT, TIME, STOP, DELAY, SBUF, AUTOSTOP, DUMP, WAIT, INDENT, GMT, RETRY Cause. A necessary keyword is not supported. Effect. The distributor fails to start up. Recovery. Specify one of the provided keywords. LOGFILE and COLLECTOR cannot coexist Cause.
EMS Programs Startup Error Messages Cause. An incorrect value is specified for the SBUF, DUMP, or GMT option. Effect. The distributor fails to start up. Recovery. Specify ON or OFF for the necessary options. Name or value missing Cause. A required name or value is missing in the command. Effect. The distributor fails to start up. Recovery. Check that all required names and values are present in your command. No matching parenthesis Cause.
EMS Programs Startup Error Messages Recovery. None needed. Position time too late log file-name [ collector collector-name ] Continuing... Cause. The position time for the specified log file is too late. Effect. The distributor waits for the next event. Recovery. None needed. Pre-C00 collector not supported Cause. A collector was specified as an event source that is a pre-C00 version collector. Effect. The distributor fails to start up. Recovery. Use a post-C00 collector as an event source.
EMS Programs Startup Error Messages Effect. The distributor fails to start up. Recovery. Check that the STOP time is greater than the TIME parameter. TARGET and TEXTOUT can not coexist Cause. TARGET and TEXTOUT are mutually exclusive distributor options and cannot be designated together. Effect. The distributor fails to start up. Recovery. Designate either TARGET or TEXTOUT, but not both in the same context. TARGET can not be same as COLLECTOR Cause.
EMS Programs Translating an EMS Event Into an SNMP Trap Effect. The distributor fails to start up. Recovery. Specify no more than 10 source collectors. Too many textout devices Cause. More than the maximum allowable (10) TEXTOUT destinations have been specified. Effect. The distributor fails to start up. Recovery. Specify no more than 10 TEXTOUT destinations. Use C[ONSUMER], F[ORWARDING], or P[RINTING] Cause. An incorrect distributor type is specified. Effect. The distributor fails to start up. Recovery.
EMS Programs Translating an EMS Event Into an SNMP Trap EMS Manual—426909-005 13-52
14 EMS Definitions This section describes EMS tokens and values associated with event-message processing, and discusses conventions for their use, focusing on the reference needs of programmers who must retrieve information from event messages: Topic Page Event-Message Overview 14-1 Definitions of Event-Message Tokens 14-3 For information about writing a program to retrieve event information through a consumer distributor, see Section 4, Retrieving Event Messages Programmatically.
EMS Definitions Header Tokens Overview either header or data-portion tokens by calls to the EMSGET or EMSGETTKN procedures. For information, see EMSGET and EMSGETTKN Procedures on page 15-12. Header Tokens Overview Event-message header tokens represent values that occur in every event message. These tokens are prefixed by either ZEMS or ZSPI. Header tokens are shared by all subsystems.
EMS Definitions Event-Message Restrictions In an event message, the reporting subsystem can include error lists with errors it encountered itself and error lists with errors encountered by a lower-level subsystem that has a different subsystem ID. Error lists do not have subjects. Therefore, all event-message subjects are visible to EMSGET or EMSGETTKN without entering a list. Each event message has one or more subjects.
EMS Definitions Definitions of EMS Tokens in the Event Message Header Definitions of EMS Tokens in the Event Message Header The remainder of the event-message header tokens are EMS tokens: (type enum; shared) is a number that a particular subsystem assigns to an event to identify it. Event numbers represent unique events only for a particular subsystem because each subsystem can use event numbers in the same range.
EMS Definitions ZEMS-TKN-EMPHASIS Definitions of EMS Tokens in the Event Message Header (type Boolean; shared) is designed to convey—from the perspective of the reporting subsystem—whether an event message should be considered critical. Set this token to TRUE to emphasize the event, though its perceived degree of seriousness will depend on your operations environment and the current situation. For a pre-EMS message that can be critical, include this token in the tokenized event message.
EMS Definitions ZEMS-TKN-SUPPRESSDISPLAY Definitions of EMS Tokens in the Event Message Header (type Boolean; shared) if TRUE, tells the ViewPoint application not to display the event message; ViewPoint displays it if the token is either FALSE or missing. Use this token in messages that report status or history that is useful for analysis but normally meaningless to operators. The token is also useful for suppressing a message that reports only an action-completion event.
EMS Definitions ZEMS-TKN-CONTENT-USER Definitions of EMS Tokens in the Event Message Header (type enum; shared) identifies the type of a subsystemdefined event. Standard enumerated values are: ZEMS-VAL-NULL (default) ZEMS-VAL-DATA-TRACE ZEMS-VAL-DATA-DEBUG ZEMS-VAL-DATA-DIAGNOSTIC Subsystems can add their own values but they must be greater than or equal to ZEMS-VAL-MIN-USER-VALUE.
EMS Definitions Definitions of EMS Special Token Codes Definitions of EMS Special Token Codes These special token codes are defined for use with the EMSGET and EMSGETTKN procedures to request information. (shared), passed to EMSGET, gets the process ID, in fname32 format, of the process that reported the event. For more information, see the Guardian Programmer’s Guide. ZEMS-TKN-SENDERID The normal mechanism to report events is through the WRITEREAD procedure.
EMS Definitions Definitions of EMS Data-Portion Tokens Definitions of EMS Data-Portion Tokens These data-portion tokens occur frequently in event messages: ZEMS-TKN-SUBJECT-MARK (type mark; shared) marks the token that follows it in the event-message buffer as a subject of the event message. An event message can have several subjects but must have at least one. The token code of ZEMS-TKNSUBJECT-MARK is shared by all subsystems.
EMS Definitions SPI Data-Portion Tokens (D-series RVUs only) (type exioaddr; nonshared) is an extensible structured token. It can hold an extended physical address for the I/O device associated with the subject of the event message. Because current and future releases of some subsystems for the NonStop server require such addresses, this token replaces the smaller CU token. Use the EXIOADDR token, not the CU token, in all your new event messages that will carry physical I/O addresses.
EMS Definitions ZSPI-TKNMANAGER SPI Data-Portion Tokens (type fname32) is the process ID of a name manager. Certain subsystems, such as Pathway, create event messages that contain names that require qualification to be unique. For example, term6 might mean different things to different Pathway systems. A name manager (PATHMON for Pathway) specifies such names uniquely.
EMS Definitions SPI Data-Portion Tokens EMS Manual—426909-005 14-12
15 EMS Procedures EMS procedures help you process event messages. You can: Retrieve information from event messages Produce display text derived from event messages Create event messages These procedures work hand-in-hand with SPI procedures and are similar to them in many ways. Event messages, like command messages, are based on SPI tokens.
EMS Procedures Which Procedures to Use Which Procedures to Use Because of the way TAL handles procedure parameters, it is inconvenient to use one procedure to handle all types of tokens. To understand this issue, you must know about passing tokens as parameters to EMS and SPI procedures. Passing Token Parameters by Value or by Reference Some tokens are identified by token codes and other tokens by token maps.
EMS Procedures Procedure Summary Tables Table 15-2. EMS Procedures for Reporting Events Name Token-Parameter Type Description EMSINIT EMSINITMAP Value Reference Initializes an event-message buffer: first step in event message creation EMSADDTOKENS EMSADDTOKENMAPS Value Reference Adds one to four tokens to a buffer that has already been initialized by EMSINIT or EMSINITMAP EMSADDSUBJECT EMSADDSUBJECTMAP Value Reference Adds an additional subject to an event-message buffer Table 15-3.
EMS Procedures Examples Examples These examples show the use of the EMS procedures described in Table 15-3.
EMS Procedures Examples Example 3: Issuing a Text Message Using the WRITE Procedure To define a text message buffer and use the WRITE procedure to send it to a collector: LITERAL TEXT^SIZE = 12; INT COL^FNUM; !Initialized by OPEN INT .
EMS Procedures Examples Example 5: Sending an SPI Command To create an SPI command buffer and use the WRITEREAD procedure to send it to a collector: INT ALT^SPI^FNUM; !From OPEN INT .CMD^BUF[0:ZEMS^VAL^BUFSIZE - 1]; INT CMD^LEN; IF NOT (ERROR := SSINIT(CMD^BUF, .....)) THEN BEGIN !Buffer Initialized OK IF NOT (ERROR := SSPUT(CMD^BUF, .....)) THEN BEGIN !Token added OK . . .
EMS Procedures Required Declarations and Standard Definitions Required Declarations and Standard Definitions Whether you program in TAL, COBOL85, C, Pascal, FORTRAN, or HP Tandem Advanced Command Language (TACL), consult the appropriate sections of the SPI Programming Manual. These sections generally apply to token-based messages (that is, to event messages as well as command and response messages). This subsection is an overview. For more information, see the SPI Programming Manual.
EMS Procedures Procedure Descriptions For more information about using SPI in TAL programs, see the SPI Programming Manual. Procedure Descriptions This subsection describes the EMS procedures in alphabetical order. EMSADDSUBJECT and EMSADDSUBJECTMAP Procedures The EMSADDSUBJECT and EMSADDSUBJECTMAP procedures let you add a subject token to the event-message buffer. Either procedure places the token that you provide—preceded by a subject-mark token—in the buffer.
EMS Procedures EMSADDSUBJECT and EMSADDSUBJECTMAP Procedures is the value of the new subject token. Include this parameter if a value is associated with the subject token. subject-length INT:value is the length, in bytes, of the subject-value field. This parameter is ignored unless the subject-token-code is defined as a variable-length token. For alternative ways to specify the length of a variable-length token, see Considerations. ssid INT .EXT:ref:6 is a subsystem ID that qualifies the token code.
EMS Procedures EMSADDTOKENS and EMSADDTOKENMAPS Procedures buffer on that procedure call is in an extended form that includes the ssid that you specified. EMSADDTOKENS and EMSADDTOKENMAPS Procedures The EMSADDTOKENS and EMSADDTOKENMAPS procedures let you add one to four tokens to an event-message buffer. In TAL programs, use EMSADDTOKENS when supplying a token code for the subject-token-id parameter.
EMS Procedures EMSADDTOKENS and EMSADDTOKENMAPS Procedures tkn-triplet is the token code or token map of the token to be added to the buffer followed by the token value and the length of that value. tkn-triplet has the following syntax: token-id , [ data-buf ] , [ data-len ] token-id INT(32):value (EMSADDTOKENS) INT .EXT:ref:* (EMSADDTOKENMAPS) is the token code or token map of a token to be added to this event message. data-buf STRING .
EMS Procedures EMSGET and EMSGETTKN Procedures buffer on that procedure call is in an extended form that includes the ssid that you specified. EMSGET and EMSGETTKN Procedures The EMSGET and EMSGETTKN procedures extract tokens and related information from an event-message buffer.
EMS Procedures EMSGET and EMSGETTKN Procedures is the SPI buffer from which information is to be extracted. token-id input INT .EXT:ref:* (EMSGET) INT(32):value (EMSGETTKN) is a token code (EMSGETTKN) or else a pointer (EMSGET) to a token code or token map. This parameter normally identifies the token to be retrieved.
EMS Procedures count EMSGET and EMSGETTKN Procedures input, output INT .EXT:ref:1 is normally used as an input and output count parameter: On the call, it specifies the maximum number of token values to return. The token-value parameter is an array of count elements, each of which is described by the token-id. If not supplied, it defaults to 1. If less than zero, it causes an error. On return, it specifies the actual number of token values returned.
EMS Procedures EMSGET and EMSGETTKN Procedures Your program can exit the list by calling EMSGET to get the ZSPI^TKN^ENDLIST token. If you want the search for a token to start at the beginning of the buffer or current list, your program must do one of: Use EMSGET or EMSGETTKN, supplying a nonzero value for index. Use SSPUT or SSPUTTKN, first resetting the initial position with ZSPI^TKN^RESET^BUFFER or ZSPI^TKN^INITIAL^POSITION. For more information, see the SPI Programming Manual.
EMS Procedures EMSGET and EMSGETTKN Procedures ZEMS^TKN^XSENDERID Use this token code to get the node number, CPU, and PIN of the sender of the event: EMSGETTKN(buffer, ZEMS^TKN^XSENDERID, xsenderid ); ! output xsenderid is of token type ZSPI^TYP^STRUCT. ZEMS^TKN^XSENDERID-PD Use this token code to get the process descriptor of the process that generated the event: EMSGETTKN(buffer, ZEMS^TKN^XSENDERID-PD, xsenderidpd ); ! output xsenderidpd is of token type ZSPI^TYP^STRING.
EMS Procedures EMSINIT and EMSINITMAP Procedures RVUs or later, or it returns ZSPI^ERR^MISTKN if the event buffer contains an event preceding the D-series RVU: EMSGETTKN(buffer, ZEMS^TKN^D00, d00 ); ! output d00 is of token type ZSPI^TYP^BOOLEAN. Usage Restrictions for Special-Operation Tokens These restrictions apply to special-operation tokens: In general, special operations are not defined for header tokens.
EMS Procedures EMSINIT and EMSINITMAP Procedures In COBOL85 programs, use EMSINITMAP through ENTER TAL. { status := } { CALL } { EMSINIT } { EMSINITMAP } status ( , , , , , , , , buffer buffer-length generating-ssid event-number subject-token-id [ subject-value ] [ subject-length ] [ subject-ssid ] [ time-stamp ] ! ! ! ! ! ! ! ! ! i/o i i i i i i i i returned value INT:value is zero or an SPI error code. For a full list of SPI error numbers, see EMSGET and EMSGETTKN Procedures on page 15-12.
EMS Procedures EMSTEXT Procedure subject-value STRING .EXT:ref:* if present, is the value of the subject to be added to the event message. subject-length INT:value is the length, in bytes, of the subject-value field. This parameter is ignored unless the subject-token-code is defined as a variable-length token. For more information, see Considerations on page 15-19. subject-ssid INT .EXT:ref:6 is the subsystem ID of the subsystem to which the subject token belongs.
EMS Procedures EMSTEXT Procedure In a modified version of the display format in which the format of the message header and the indentation of the message body are specified by the EMSTEXT parameters header template key and indent For the steps to use EMSTEXT, and for error results, see Text Formatting Tools on page 2-12. For an explanation of the template compiler, see the DSM Template Services Manual.
EMS Procedures EMSTEXT Procedure n is the number of logical lines required to display the message text (the value of number-display-lines on page 15-21) Note. You must make the buffer size, d * n, large enough to hold the entire text, including trailing and indent blanks. You will probably set d to the standard line length for your output device—80 characters, for instance. Making the buffer large enough then depends directly on the value you choose for n.
EMS Procedures EMSTEXT Procedure if present, is the key of a format template. EMSTEXT uses the template to format the headers of all event messages for display as text. With the header template key, you can customize the header information for all the event messages of an application. The header is the first part of the event message. It includes such information as the ID of the process that gave rise to the event and the date and time when it occurred.
EMS Procedures EMSTEXT Procedure Considerations Because EMSTEXT requires extra data stack space, include this command or its equivalent in your TAL program: ?EXTENDSTACK 4 ! To ensure enough stack space for ! EMSTEXT Use the EMSGET procedure to extract information from event messages when it is feasible to do so, rather than scanning text produced by EMSTEXT. EMSTEXT is intended specifically for producing text for display purposes.
EMS Procedures EMSTEXT Procedure Table 15-5. EMSTEXT Extended Status Codes (page 1 of 2) Status Description 0 0 Normal return 1 x ALLOCATESEGMENT returned error x because it did not get the private segment for EMSTEXT 2 x Problem with the template file: x>0 A file-management error sent from the OPEN procedure. x = -1 The file code is not 839 or 844. x = -2 The file is not a disk file. x = -3 The file is not key-sequenced. x = -4 The file has the wrong record size.
EMS Procedures EMSTEXT Procedure Table 15-5.
EMS Procedures EMSTEXT Procedure EMS Manual—426909-005 15-26
16 Event Routing This section describes dynamic routing of events by the printing distributor to selected destinations: Topic Page Routing Capability 16-1 Launching of Destination Processes 16-1 Formatting Selection 16-2 Multiple Filters 16-2 User Interfaces 16-3 Selection of Collectors for Internal Events 16-3 Distributor Generated Messages 16-4 Routing Capability The printing distributor allows distribution of events to selected destinations.
Event Routing Formatting Selection The startup failed event contains a special token, ZEMS-TKN-STARTUP-LOGTIME, which is set to the log time retrieved from the event that the distributor could not send. When the next event trigger occurs for this destination, the distributor attempts to start the process again. If it fails, the event is skipped, but no messages are generated. If eventually the startup succeeds, a message is sent to the OUT device indicating that the process launched.
Event Routing User Interfaces User Interfaces This subsection describes the use of multiple filters and the filter PASS statement. Startup of Multiple Filters A routing distributor is started as a printing distributor: RUN EMSDIST TYPE P[rinting], FILTER f1 | (f1, f2, f3, ..fn), .... The filters can contain destination profiles to direct events to selected destinations. If the startup line contains a TEXTOUT parameter, specifying a filter with destination profiles results in an error.
Event Routing Distributor Generated Messages If a DEFINE is not specified, all distributor generated events except ZEMS^EVT^BURST^START and ZEMS^EVT^BURST^END are written to $0. The burst start and burst end messages are written to the OUT file of the distributor, as specified in the EMSDIST run option, OUT. If the EMSDIST run option OUT is specified but does not match the hometerm, burst start and burst end messages are written to the OUT file as a text error list.
Part V: Using EMS Distributors and Collectors This part of the manual describes the commands, responses, event messages, and errors for EMS collectors and distributors: Section 17, Distributor Commands and Responses Section 18, Distributor Event Messages Section 19, Collector Commands and Responses Section 20, Collector Event Messages Section 21, Distributor Errors Section 22, Collector Errors EMS Manual—426909-005
Part V: Using EMS Distributors and Collectors EMS Manual—426909-005
17 Distributor Commands and Responses This section describes the command and response messages for the consumer, printing, and forwarding distributors. For descriptions of commands for the compatibility distributor, which is controlled through the EMS collector, see Section 19, Collector Commands and Responses.
Distributor Commands and Responses Extended Programmatic Interface Table 17-1. Distributor Commands Summary (page 2 of 2) (continued) Command Name Description ZEMS-CMD-GETEVENT Gets the next event message to pass the current filter. GETEVENT applies only to consumer distributors. ZEMS-CMD-GETVERSION Gets the version number of the programmatic interface. ZEMS-CMD-REPLACE Replaces one configured filter in a distributor with another filter.
Distributor Commands and Responses Object Support Summary verb when the command is initialized by SSINIT, as well as a ZCOM-TKN-OBJNAME token. Distributor commands still supported by the original basic SPI interface are ZEMSCMD-CONTROL, ZEMS-CMD-GETEVENT, ZEMS-CMD-GETVERSION, and ZEMSCMD-REPLACE. While the ZEMS-CMD-REPLACE command requires an object name, the other ZEMS- commands do not.
Distributor Commands and Responses Object Support Summary Table 17-3. Distributor and Filter Object Support Distributor Command ZCOM-OBJ-DIST ZCOM-OBJ-FILTER ZCOM-CMD-ADD No Yes, >=1 ZCOM-CMD-ALTER Yes, Only 1 Yes, >=1, * ZCOM-CMD-DELETE No Yes, >=1, * ZEMS-CMD-REPLACE No Yes, Only 1 ZCOM-CMD-STATUS Yes, Only 1, * Yes, Only 1, * ZEMS-CMD-GETVERSION Yes, Only 1 No ZEMS-CMD-GETEVENT Yes, Only 1 No “Yes” signifies that the distributor command supports the object type.
Distributor Commands and Responses Common Definitions for ZCOM- Commands Table 17-5. Forwarding Target Object Support Distributor Command ZCOM-OBJ-TARGET ZCOM-CMD-ADD No ZCOM-CMD-ALTER Yes, Only 1 ZCOM-CMD-DELETE No ZEMS-CMD-REPLACE No ZCOM-CMD-STATUS Yes, Only 1, * ZEMS-CMD-GETVERSION No ZEMS-CMD-GETEVENT No “Yes” signifies that the distributor command supports the object type. “No” signifies that the distributor command does not support the object type.
Distributor Commands and Responses Common Command Tokens for ZCOM- Commands Basic SPI signifies that the presence of this token in the command is dictated by the basic SPI command language standards that govern multiple objects and responses.
Distributor Commands and Responses Common Response Tokens for ZCOM- Commands ZCOM-TKN-OBJNAME specifies the fully qualified name of the object to be selected for processing. At least one of these tokens must be in the command. Multiple occurrences of this token (with different object names) are allowed only for the ZCOM-CMD-ADD and ZCOM-CMD-DELETE commands. A ZCOM-CMD-STATUS command with a wildcard object name can have multiple responses.
Distributor Commands and Responses Common Response Tokens for ZCOM- Commands Response Token Usage Considerations SSINIT signifies that the value for this token must be supplied in the call to SSINIT to create the SPI command. Basic SPI signifies that the presence of this token in the command is dictated by the basic SPI command language standards that govern multiple objects and responses. The EMS distributor’s extended programmatic interface deviates from the SPI common extensions standard.
Distributor Commands and Responses Common Definitions for ZEMS- Commands it is non-zero, an error occurred, and the response record contains an error list that describes the error. ZSPI-TKN-ERRLIST indicates the beginning of an error list. ZSPI-TKN-ENDLIST indicates the end of the error list, and the error list can be nested. An error list is put in the response for each error or warning encountered during processing of the command. ZSPI-TKNERROR is the only required token for the error list.
Distributor Commands and Responses Distributor Errors ZSPI-TKN-SERVER-BANNER (type char50) contains the standard banner information. ZSPI-TKN-SERVER-VERSION (type uint) is the subsystem version number of the EMS distributor. ZSPI-TKN-SSID (type ssid) consists of ZSPI-VAL-TANDEM.ZSPI-SSN-ZEMS.ZSPI-VAL-VERSION, the subsystem ID for the Event Management Service. Distributor Errors Response messages to distributor commands, like responses to all command messages, contain the token ZSPI-TKN-RETCODE.
Distributor Commands and Responses Distributor Error Numbers Distributor Error Numbers Table 17-8 and Table 17-9 list distributor errors and separate the errors in interpreting a command message from the errors in carrying out a command. Table 17-8.
Distributor Commands and Responses Distributor Command Descriptions Distributor Command Descriptions This subsection describes the distributor commands, including both ZCOM- and ZEMS- types. Each command description includes a summary of the command and response tokens that are used. Many of these are common command and response tokens that are described in Common Definitions for ZCOM- Commands on page 17-5 and Common Definitions for ZEMS- Commands on page 17-9. Note.
Distributor Commands and Responses ALTER Command (ZCOM-CMD-ALTER) Required signifies that the token is required and must be supplied by the user. Filter signifies that the required filter parameter tokens are required only if they are defined as required parameter tokens in the filter. Unconditional signifies that the token always appears in the response. The data list (all tokens from -DATALIST to -ENDLIST) forms a single response record.
Distributor Commands and Responses ALTER Command (ZCOM-CMD-ALTER) When the object is an EMS filter, the additional tokens are filter parameter tokens when filter parameters are specified in the filter. Each ZCOM-CMD-ALTER command resets the filter parameters for the specified filters, so all required filter parameters must have tokens present in the command. The presence of tokens for the optional filter parameters is optional.
Distributor Commands and Responses ALTER Command (ZCOM-CMD-ALTER) For a detailed description of these command and response tokens, see Common Definitions for ZCOM- Commands on page 17-5. ZEMS-MAP-CONTROL-DIST Definitions Use this Data Definition Language (DDL) structure when configuring an EMS distributor attribute with the ZCOM-CMD-ALTER command. ZEMS-MAP-CONTROL-DIST DEF ZEMS-DDL-CONTROL-DIST. 02 ZDIST-GMTTIME TIMESTAMP. 02 ZDIST-LOGTIME TIMESTAMP.
Distributor Commands and Responses ALTER Command (ZCOM-CMD-ALTER) ZDIST-BLOCKING-PRESENT (Boolean field) must be set to true if the sequential blocking flag is allowed in ZDIST-SEQBLOCKING. ZDIST-SEQ-BLOCKING (Boolean field) indicates whether sequential blocking is selected for all log files except the current file associated with the collector.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) CONTROL Command (ZEMS-CMD-CONTROL) The ZEMS-CMD-CONTROL command directs a distributor to change its operational environment: to change its source of event messages (and the position within the source at which examination of event messages begins), to install or change a filter or filter parameters, and to change the destinations of event messages that pass the filter. Note.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) ZEMS-TKN-REPLACE-PARAM (type Boolean) if equal to ZSPI-VAL-TRUE, directs the distributor to replace the current parameter tokens with the parameter tokens supplied by this command message. parameter-tokens are one or more user-defined tokens: the parameter tokens for the event-message filter. See Passing Filter Parameters on page 17-21.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) ZEMS-TKN-DISCONNECT-SRC-COLL (type fname) is the name of a collector to be disconnected (from this distributor) as a source of event messages. The distributor continues to access event messages from any remaining source collectors. See also ZEMS-TKN-CONNECT-SRC-COLL.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) Error-Handling Notes Table 17-10 lists the name, number, and description of each ZEMS-CMD-CONTROL error message (or warning). The messages are grouped by the command features to which they are each related. Each name marked with an asterisk (*) is a warning—the value of the ZSPI-TKNRETCODE token is set to zero. The error list contains the ZSPI-TKN-ERROR token, which contains the number of the warning.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) messages. If you start a forwarding distributor without a filter, the distributor does not begin event-message processing until a filter is specified. To specify a single filter, use ZEMS-TKN-FILTERFILE, which contains the name of the filter object-file. Use ZEMS-TKN-FILTERFILE to provide a first filter or to replace a previously loaded filter.
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) Specifying Event-Message Sources At any particular time, the distributor gets event messages from either—but not both— of these event-message sources: Specified collectors. The distributor gets its messages from the current log files of one or more collectors that you specify (see ZEMS-TKN-CONNECT-SRC-COLL and ZEMS-TKN-DISCONNECT-SRC-COLL).
Distributor Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) examine event messages as they are logged by specifying a ZEMS-TKN-GMTTIME of -1F. Note. If a collector has received messages from a forwarding distributor, generation time and logging time can grow farther apart. The generation time depends on the system where the message was created. The logging time depends on the system where the message is logged.
Distributor Commands and Responses DELETE Command (ZCOM-CMD-DELETE) DELETE Command (ZCOM-CMD-DELETE) The ZCOM-CMD-DELETE command deletes objects from the EMS distributor. The supported objects are the EMS filter (ZCOM-OBJ-FILTER), event source (ZCOM-OBJSOURCE), and event destination (ZCOM-OBJ-TEXTOUT). At least one object name token is required. Use of the wild-card object name (*) is also supported.
Distributor Commands and Responses GETEVENT Command (ZEMS-CMD-GETEVENT) GETEVENT Command (ZEMS-CMD-GETEVENT) The ZEMS-CMD-GETEVENT command gets the next event message to pass the current filter. GETEVENT applies only to consumer distributors. Command ZEMS-CMD-GETEVENT Tokens in Command Buffer ZSPI-TKN-CONTEXT ZEMS-TKN-EOFSTOP token-type ZSPI-TYP-BYTESTRING token-type ZSPI-TYP-BOOLEAN Tokens in Response Buffer ZEMS-TKN-EVENT ZEMS-TKN-PASSVAL ZSPI-TKN-CONTEXT ZSPI-TKN-RETCODE ZSPI-TKN-ERRLIST . . .
Distributor Commands and Responses GETEVENT Command (ZEMS-CMD-GETEVENT) Tokens in Response Buffer ZEMS-TKN-EVENT (type bytestring) is the actual event message. ZEMS-TKN-PASSVAL (type int) if present, is the number following PASS in the PASS statement executed by the current filter. If you omit the number on the PASS statement, the distributor omits the ZEMS-TKN-PASSVAL token. ZSPI-TKN-CONTEXT (type bytestring) is the new context block for the event message just returned.
Distributor Commands and Responses GETEVENT Command (ZEMS-CMD-GETEVENT) Error-Handling Notes Table 17-11. GETEVENT Command Errors Name (ZEMS-ERR-) Number Description EOF* 501 End-of-file indication sent because requested by a ZEMS-TKN-EOFSTOP token. LOG-ACCESS 1031 The distributor cannot access an event-message log file. EOF 1032 GETEVENT called past the end-of-file position. CONTEXT 1039 Mismatch between context token submitted and context token saved.
Distributor Commands and Responses GETVERSION Command (ZEMS-CMDGETVERSION) GETVERSION Command (ZEMS-CMD-GETVERSION) The ZEMS-CMD-GETVERSION command displays the version number and banner of the EMS programmatic interface. Command ZEMS-CMD-GETVERSION Tokens in Command Buffer None Tokens in Response Buffer ZSPI-TKN-SERVER-BANNER ZSPI-TKN-SERVER-VERSION ZSPI-TKN-RETCODE ZSPI-TKN-ERRLIST . . .
Distributor Commands and Responses REPLACE Command (ZEMS-CMD-REPLACE) REPLACE Command (ZEMS-CMD-REPLACE) The ZEMS-CMD-REPLACE command replaces a configured object in the EMS distributor with another object. The only supported object is an EMS filter (ZCOM-OBJFILTER). The filter can be a compiled filter, a filter table, or a burst filter. Only one filter at a time can be replaced using this command.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) STATUS Command (ZCOM-CMD-STATUS) The ZCOM-CMD-STATUS command requests both configuration and status information from the EMS distributor. The supported object types are the EMS distributor (ZCOM-OBJ-DIST), EMS filters (ZCOM-OBJ-FILTER), event source (ZCOM-OBJ-SOURCE), event destination (ZCOM-OBJ-TEXTOUT), and forwarding target (ZCOM-OJB-TARGET). The basic SPI-compliant ZEMS-CMD-STATUS command does not support object types.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) For a detailed description of these command tokens, see Common Definitions for ZCOM- Commands on page 17-5.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) Response Tokens When Object Type Is ZCOM-OBJTEXTOUT Token Type Usage ZSPI-TKN-DATALIST ZSPI-TKN-RETCODE ZEMS-MAP-STATUSTEXTOUT ZSPI-TYP-LIST ZSPI-TYP-ENUM ZEMS-DDL-STATUSTEXTOUT ZSPI-TYP-LIST ZSPI-TYP-ERROR ZSPI-TYP-SSCTL ZSPI-TYP-SSCTL Basic SPI Unconditional Unconditional Error only Error only Error only Basic SPI Token Type Usage ZSPI-TYP-LIST ZSPI-TYP-ENUM ZEMS-DDL-STATUSTARGET ZSPI-TYP-LIST ZSPI-TYP-ERROR ZSPI-TYP-SSCTL ZSPI-
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) and object occurrences is returned. If the name is set to the name of the distributor, only distributor attributes are returned. If the object type is ZCOM-OBJ-SOURCE, ZCOM-OBJ-TEXTOUT, ZCOM-OBJFILTER, or ZCOM-OBJ-TARGET, and the object name is either omitted or set to (*), an asterisk, information about all object instances is returned. To receive only information for a particular object instance, set the object name accordingly.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) STATUS Data Structure Details The data definition lists for the five token maps returned by the ZCOM-CMD-STATUS command are shown in this table: Token Maps in ZCOM-CMD-STATUS Response Buffer (Page 1 of 2) ZEMS-MAP-STATUS-DIST DEF ZEMS-DDL-STATUS-DIST.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) Token Maps in ZCOM-CMD-STATUS Response Buffer (Page 2 of 2) ZEMS-MAP-STATUS-TARGET DEF ZEMS-DDL-STATUS-TARGET. 02 ZDIST-TARGET-NAME 02 ZDIST-TARGET-EVENTSPER-BLOCK 02 ZDIST-TARGET-STATE END ZEMS-MAP-STATUS-TEXTOUT DEF ZEMS-DDL-STATUS-TEXTOUT. 02 ZDIST-TEXTOUT-NAME 02 ZDIST-TEXTOUT-TYPE 02 ZDIST-TEXTOUT-STATE 02 ZDIST-TEXTOUT-RECLEN END token-type ZSPI-DDL-FNAME. token-type ZSPI-DDL-UINT. token-type ZSPI-DDL-UINT.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) ZDIST-BACKUP-CPU (int field) is the number of the CPU in which the backup process of the distributor is currently running if a backup exists. This field is set to -1 if a backup does not exist. ZDIST-PRIORITY (int field) is the current execution priority of the distributor. ZDIST-FILTERFILE (fname field) is the name of the object filter file if the filter was loaded from a disk file. This is a 24-byte internal file name.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) ZDIST-EOFDELAY (uint field) is the time that the distributor delays after end of file (EOF) before rereading the log. This value is given in sec/100. ZDIST-SEQ-BLOCKING (Boolean field) indicates if sequential blocking is selected for all log files except the current file associated with the collector.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) ZEMS-MAP-STATUS-SOURCE is an extensible structured token that gives information about each source collector (DEF: ZEMS-DDL-STATUS-SOURCE). The fields of ZEMS-MAP-STATUSSOURCE are defined as: ZDIST-COLL-NAME (procname field) is the name of the collector process if the distributor is in collector mode. Otherwise, the field is blank. ZDIST-COLL-LOGNAME (discname field) is the name of a collector log file.
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) ZDIST-CUR-RECORD-ADDRESS (int2 field) is the record address, an entry-sequenced file address within the current log file (in ZDIST-CUR-LOGNAME), of the event message last examined by the distributor. Assume that blknum is the block number (numbering from zero), blklen is the block length (in bytes), and recnum is the record number (within the block).
Distributor Commands and Responses STATUS Command (ZCOM-CMD-STATUS) ZDIST-TEXTOUT-STATE (uint field) is the state of this TEXTOUT destination, which can have these values: ZEMS-VAL-NO-TEXTOUT ZEMS-VAL-TXT-IDLE ZEMS-VAL-TXT-WAIT-ERROR ZEMS-VAL-TXT-WAIT-TIMEDOUT ZEMS-VAL-TXT-PRINTING 0 1 2 3 4 Removed (after error) Idle Waiting (after error) Waiting (timed out) Printing ZDIST-TEXTOUT-RECLEN (uint field) is the record length in bytes of the TEXTOUT destination.
Distributor Commands and Responses STATUS Command (ZEMS-CMD-STATUS) STATUS Command (ZEMS-CMD-STATUS) The ZEMS-CMD-STATUS command gets information about several topics, each of which the distributor represents as one or more of the same extensible structured tokens that are described in STATUS Data Structure Details on page 17-34 for ZCOMCMD-STATUS. Command ZEMS-CMD-STATUS Tokens in Command Buffer None Tokens in Response Buffer ZEMS-MAP-STATUS-DIST DEF ZEMS-DDL-STATUS-DIST.
Distributor Commands and Responses STATUS Command (ZEMS-CMD-STATUS) EMS Manual—426909-005 17-42
18 Distributor Event Messages This section describes event messages generated by printing or forwarding distributors and are related to their operation. (Consumer distributors do not generate event messages.) Distributor event messages help you monitor and manage network resources from a ViewPoint console or through an application. Two examples of distributor events that require operational attention are a bad log file or a bad printer destination (for a print distributor).
Distributor Event Messages Table 18-1.
Distributor Event Messages Event Message Descriptions Event Message Descriptions Every event-message description in this section contains: The event-message display text—the text that the EMSTEXT procedure generates if you select normal text style (For more information, see EMSTEXT Procedure on page 15-19) A list of unconditional tokens—tokens that are always in the message A list of conditional tokens, if any, that are present under certain conditions The cause of the event The effect that
Distributor Event Messages EMS Token Codes ZEMS-VAL-FILTER-VERIFY ZEMS-VAL-EMSADDBUFFER ZEMS-VAL-EMSADDSUBJECT ZEMS-VAL-EMSADDTOKENS ZEMS-VAL-EMSGET ZEMS-VAL-EMSINIT ZEMS-VAL-EMSSEND ZEMS-VAL-CHECKOPEN ZEMS-VAL-NEWPROCESS ZEMS-VAL-CHECKPOINT ZEMS-VAL-CHECKMONITOR 28 29 30 31 32 33 34 35 36 37 38 EMS Token Codes These are definitions of the EMS tokens used in distributor event messages (EMS tokens common to event messages from all subsystems are excluded): ZEMS-MAP-STATUS-DIST (DEF: ZEMS-DDL-STATUS-DIST)
Distributor Event Messages EMS Token Codes ZEMS-TKN-FAILFILENAME (type: ZSPI-TYP-FNAME; nonshared) is the file name of a bad log file. ZEMS-TKN-FILECODE (type: ZSPI-TYP-INT; nonshared) is the file code of a log file. ZEMS-TKN-FILTER-ERROR (type: ZSPI-TYP-ENUM; nonshared) is a token, private to HP, that might be useful to your HP representative. ZEMS-TKN-FILTERNAME (type: ZEMS-TYP-CHAR30; nonshared) is the name of the filter given in the filter specification at compilation time.
Distributor Event Messages EMS Token Codes ZEMS-VAL-PROGRAMFILE-ERROR ZEMS-VAL-NO-MAP ZEMS-VAL-BAD-SWAPFILE ZEMS-VAL-BAD-FILE-FORMAT ZEMS-VAL-UNLICENSED ZEMS-VAL-BAD-PROCESS-NAME ZEMS-VAL-LIBRARY-CONFLICT ZEMS-VAL-MONITOR-COMM ZEMS-VAL-LIBRARY-FILE ZEMS-VAL-PROGRAM-FILE ZEMS-VAL-NO-EXT-SEGMENT ZEMS-VAL-EXT-SEGMENT-SWAP ZEMS-VAL-BAD-HOMETERM 3 4 5 6 7 8 9 10 11 12 13 14 15 ZEMS-TKN-NEWPROCESS-PRIORITY (type: ZSPI-TYP-INT; nonshared) is the new process priority in a NEWPROCESS command.
Distributor Event Messages 538: ZEMS-EVT-BURST-START 538: ZEMS-EVT-BURST-START Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-BURST-EVT-NUM ZEMS-TKN-BURST-SSID ZEMS-TKN-BURST-SUBJ-CODE ZEMS-TKN-BURST-SUBJ-VALUE ZEMS-TKN-BURST-SUBJ-SSID ZEMS-TKN-BURST-TIME-START ZEMS-MAP-BDS-INFO toke
Distributor Event Messages 538: ZEMS-EVT-BURST-START ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR is the EMS process type. Value 1 is for the primary collector, 2 for an alternate collector, and 3 for a distributor.
Distributor Event Messages 538: ZEMS-EVT-BURST-START proc-desc is from ZEMS-TKN-BURST-PROC-DESC. Cause. An event burst was detected. In terms of BDS configuration parameters, N similar events have occurred within the T1 time interval. Similar events are those that have the same SSID, event number, and subject. The L burst parameter defines what “same subject” means. For a detailed description of BDS configuration parameters and their default values, see Section 7, Burst Detection and Suppression. Effect.
Distributor Event Messages 539: ZEMS-EVT-BURST-END 539: ZEMS-EVT-BURST-END Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-BURST-EVT-NUM ZEMS-TKN-BURST-SSID ZEMS-TKN-BURST-SUBJ-CODE ZEMS-TKN-BURST-SUBJ-VALUE ZEMS-TKN-BURST-SUBJ-SSID ZEMS-TKN-BURST-TIME-START ZEMS-TKN-BURST-TIME-END ZEM
Distributor Event Messages 539: ZEMS-EVT-BURST-END ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-BURST-END (539). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE.
Distributor Event Messages 539: ZEMS-EVT-BURST-END ZEMS-TKN-BURST-TIME-END is the Julian timestamp of the burst end time. ZEMS-TKN-BURST-EVTS-DELETED are occurrences of the bursting event that were not logged during the event burst. ZEMS-TKN-BURST-END-REASON is the reason for the event burst end. A value of ZEMS-VAL-BDS-DISABLED means the burst ended because BDS was terminated by the operator.
Distributor Event Messages 1000: ZEMS-EVT-LOG-ACCESS 1000: ZEMS-EVT-LOG-ACCESS Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-LOGNAME ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST ZEMS-TKN-ZFILERR ZEMS-TKN-COLNAME-ENUM ZEMS-TKN-COLNAME token-type token-type token-type token-type token-type token-type token-type token-type
Distributor Event Messages 1000: ZEMS-EVT-LOG-ACCESS ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-LOGNAME (nonshared) is the file name of a log file. Here it is the log file in use when the event occurred.
Distributor Event Messages 1001: ZEMS-EVT-COLL-ACCESS 1001: ZEMS-EVT-COLL-ACCESS Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLNAME ZEMS-TKN-COLNAME-ENUM ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST ZEMS-TKN-ZFILERR token-type token-type token-type token-type token-type token-type token-type token-type token-type tok
Distributor Event Messages 1001: ZEMS-EVT-COLL-ACCESS ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLNAME (nonshared) is the name of a collector. Here, it is a collector that the distributor cannot access.
Distributor Event Messages 1002: ZEMS-EVT-DEST-ACCESS 1002: ZEMS-EVT-DEST-ACCESS Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST ZEMS-TKN-ZFILERR token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-typ
Distributor Event Messages 1002: ZEMS-EVT-DEST-ACCESS ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-FAILFILENAME (nonshared) is the file name of a bad file. Here it is the name of a destination device or process that the distributor could not access. ZSPI-TKN-PROC-ERR (nonshared) specifies a procedure associated with the event.
Distributor Event Messages 1003: ZEMS-EVT-LOGFILE-EOF 1003: ZEMS-EVT-LOGFILE-EOF Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-LOGNAME ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type ZSPI
Distributor Event Messages 1003: ZEMS-EVT-LOGFILE-EOF ZEMS-TKN-LOGNAME (nonshared) is the file name of a log file. Here, it is the log file in use when the end-of-file was encountered. ZEMS-MAP-STATUS-DIST is an extensible structured token described in Token and Data Type Definitions on page 18-3. Cause. The distributor reached an end-of-file while using a specified log file as its event-message source.
Distributor Event Messages 1005: ZEMS-EVT-BAD-FILTER 1005: ZEMS-EVT-BAD-FILTER Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FILTERNAME ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST ZEMS-TKN-RECORD-ADDRESS ZEMS-TKN-FILTER-ERROR ZEMS-TKN-LOGNAME ZEMS-TKN-COLNAME-ENUM ZEMS-TKN-COLNAME token-type token-type token-type token
Distributor Event Messages 1005: ZEMS-EVT-BAD-FILTER ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-FILTERNAME (nonshared) is the name of the filter given in the filter specification at compilation time.
Distributor Event Messages 1006: ZEMS-EVT-COLL-PROTOCOL 1006: ZEMS-EVT-COLL-PROTOCOL Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLNAME ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token
Distributor Event Messages 1006: ZEMS-EVT-COLL-PROTOCOL ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLNAME (nonshared) is the name of a collector. Here it is the collector that responded to the distributor with an invalid SPI response. ZSPI-TKN-PROC-ERR (nonshared) specifies a procedure associated with the event. Here EMS assigns the value of ZSPI-VAL-SSGET to 2.
Distributor Event Messages 1007: ZEMS-EVT-BAD-EVENT 1007: ZEMS-EVT-BAD-EVENT Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-LOGNAME ZSPI-TKN-PROC-ERR ZEMS-MAP-STATUS-DIST ZEMS-TKN-RECORD-ADDRESS ZEMS-TKN-COLNAME-ENUM ZEMS-TKN-COLNAME token-type token-type token-type token-type token-type token-type token-type token
Distributor Event Messages 1007: ZEMS-EVT-BAD-EVENT ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-LOGNAME (nonshared) is the file name of a log file. Here it is the log file in use when the distributor read the bad event message.
Distributor Event Messages 1008: ZEMS-EVT-DEVTYPE 1008: ZEMS-EVT-DEVTYPE Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZEMS-MAP-STATUS-DIST ZEMS-TKN-DEVTYPE-ENUM token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-ty
Distributor Event Messages 1008: ZEMS-EVT-DEVTYPE ZEMS-TKN-EMPHASIS (shared) is a standard EMS token; for more information, see Section 14, EMS Definitions. Its value here is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token; for more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions.
Distributor Event Messages 1009: ZEMS-EVT-INTERNAL-ERROR 1009: ZEMS-EVT-INTERNAL-ERROR Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-SUBJECT-MARK ZSPI-TKN-ERROR ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type to
Distributor Event Messages 1010: ZEMS-EVT-CHECKOPEN-FAILED ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has two subject tokens: ZEMS-TKN-PROGRAMFILE and ZSPITKN-ERROR. ZEMS-TKN-PROGRAMFILE (nonshared) is the file name of the distributor object program. For descriptions of the extensible structured token ZEMS-MAP-STATUS-DIST and the token ZSPI-TKN-ERROR, see Token and Data Type Definitions on page 18-3. Cause.
Distributor Event Messages 1010: ZEMS-EVT-CHECKOPEN-FAILED ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-CHECKOPEN-FAILED (1010). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token; for more information, see Section 14, EMS Definitions. Its value here is TRUE.
Distributor Event Messages 1011: ZEMS-EVT-TAKEOVER 1011: ZEMS-EVT-TAKEOVER Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZSPI-TKN-PROC-ERR ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-DIST-NAME ZEMS-TKN-TAKEOVER-REASON token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-typ
Distributor Event Messages 1011: ZEMS-EVT-TAKEOVER ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZSPI-TKN-PROC-ERR (nonshared) specifies a procedure associated with the event. Here EMS assigns the value of ZEMS-VAL-CHECKPOINT to 37. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Distributor Event Messages 1012: ZEMS-EVT-CREATEBACKUP-FAILED 1012: ZEMS-EVT-CREATEBACKUP-FAILED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-DIST-NAME ZSPI-TKN-PROC-ERR ZEMS-TKN-NEWPROCESS-CPU ZEMS-TKN-NEWPROCESS-PRIORITY ZEMS-TKN-PROCCREATE-ERROR token-type token-type
Distributor Event Messages 1012: ZEMS-EVT-CREATEBACKUP-FAILED Unconditional Tokens ZSPI-TKN-SSID is the subsystem ID for EMS, as described in the SPI Programming Manual. ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-CREATEBACKUP-FAILED (1012). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token.
Distributor Event Messages 1012: ZEMS-EVT-CREATEBACKUP-FAILED Cause. The distributor cannot create a backup due to a PROCESS_CREATE_ error. The event message is issued only if the initial attempt to create a backup fails; unsuccessful retries are not reported. Effect. The primary distributor process retries this error unless the PROCESS_CREATE_ error indicates that the backup CPU is down.
Distributor Event Messages 1013: ZEMS-EVT-BACKUP-CREATED 1013: ZEMS-EVT-BACKUP-CREATED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-DIST-NAME ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-NEWPROCESS-CPU ZEMS-TKN-NEWPROCESS-PRIORITY ZEMS-TKN-PROCCREATE-ERROR ZSPI-TKN-PROC-ERR token-type token-type token-type
Distributor Event Messages 1013: ZEMS-EVT-BACKUP-CREATED ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has two subject tokens: ZEMS-TKN-DIST-NAME (nonshared) is the name of the distributor process. Here it is the name of the new distributor process.
Distributor Event Messages 1014: ZEMS-EVT-BACKUP-ABENDED 1014: ZEMS-EVT-BACKUP-ABENDED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-DIST-NAME token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type ZSPI-TYP-SSID. ZSPI-TYP-INT.
Distributor Event Messages 1014: ZEMS-EVT-BACKUP-ABENDED ZEMS-TKN-DIST-NAME (nonshared) is the name of the distributor process. Cause. The distributor’s backup process terminated abnormally. Effect. The primary distributor process attempts to create a new backup after a 30second delay. Recovery. Contact your service provider. Provide your provider with the SAVEABEND file from the backup.
Distributor Event Messages 1015: ZEMS-EVT-BACKUP-DELETED 1015: ZEMS-EVT-BACKUP-DELETED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-DIST-NAME token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type ZSPI-TYP-SSID. ZSPI-TYP-INT.
Distributor Event Messages 1016: ZEMS-EVT-CHECKPOINT-FAILED ZEMS-TKN-DIST-NAME (nonshared) is the name of the distributor process. Cause. The CPU in which the distributor’s backup process was running failed. Effect. The primary distributor process does not attempt to create a backup until 30 seconds after receiving a CPU RELOADED system message for its backup CPU. Recovery. Follow the recommended procedure for CPU failure.
Distributor Event Messages 1016: ZEMS-EVT-CHECKPOINT-FAILED ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Distributor Event Messages 1017: ZEMS-EVT-BAD-LOG 1017: ZEMS-EVT-BAD-LOG Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-LOGNAME ZEMS-MAP-STATUS-DIST ZEMS-TKN-COLNAME-ENUM ZEMS-TKN-COLNAME token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-t
Distributor Event Messages 1017: ZEMS-EVT-BAD-LOG ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-LOGNAME (nonshared) is the file name of a log file. Here, it is the log file that the distributor has declared invalid. For descriptions of the extensible structured token ZEMS-MAP-STATUS-DIST and the tokens ZEMS-TKN-COLNAME-ENUM and -COLNAME, see Token and Data Type Definitions on page 18-3. Cause.
Distributor Event Messages 1018: ZEMS-EVT-FILES-LOST 1018: ZEMS-EVT-FILES-LOST Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLNAME ZEMS-TKN-LASTLOGFILE ZEMS-TKN-FAIL-REASON ZEMS-TKN-RECOVERY-ENUM token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-t
Distributor Event Messages 1018: ZEMS-EVT-FILES-LOST ZEMS-TKN-EMPHASIS (shared) is a standard EMS token; for more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token; for more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions.
Distributor Event Messages 1018: ZEMS-EVT-FILES-LOST Conditional Tokens ZEMS-TKN-NEWLOGFILE (nonshared) is the name of the log file, later in sequence than the inaccessible file, that the distributor was able to access. This token is included only if the value of ZEMSTKN-RECOVERY-ENUM is ZEMS-VAL-RECOVERY-OK; that is, only if the distributor could access a later file. Cause. The distributor could not access one or more collector log files older than the current one.
Distributor Event Messages 1019: ZEMS-EVT-COL-DISCONNECT 1019: ZEMS-EVT-COL-DISCONNECT Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLNAME ZEMS-MAP-STATUS-DIST ZEMS-TKN-COLNAME-ENUM token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type
Distributor Event Messages 1019: ZEMS-EVT-COL-DISCONNECT ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLNAME (nonshared) is the name of a collector. Here, it is the collector that the distributor is disconnecting. The extensible structured token ZEMS-MAP-STATUS-DIST and the token ZEMS-TKNCOLNAME-ENUM are described in Token and Data Type Definitions on page 18-3. Cause.
Distributor Event Messages 1020: ZEMS-EVT-STARTUP-FAILED 1020: ZEMS-EVT-STARTUP-FAILED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROC-ERR ZEMS-TKN-NEWPROCESS-CPU ZEMS-TKN-NEWPROCESS-PRIORITY ZEMS-TKN-NEWPROCESS-ERROR ZEMS-TKN-STARTUP-LOGTIME ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type t
Distributor Event Messages 1020: ZEMS-EVT-STARTUP-FAILED ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions.
Distributor Event Messages 1020: ZEMS-EVT-STARTUP-FAILED ZEMS-VAL-MONITOR-COMM ZEMS-VAL-LIBRARY-FILE ZEMS-VAL-PROGRAM-FILE ZEMS-VAL-NO-EXT-SEGMENT ZEMS-VAL-EXT-SEGMENT-SWAP ZEMS-VAL-BAD-HOMETERM ZEMS-TKN-STARTUP-LOGTIME (type: ZSPI-TYP-TIMESTAMP; nonshared) is the log time of the event that triggered the startup. For a description of the extensible structured token ZEMS-MAP-STATUS-DIST, see Token and Data Type Definitions on page 18-3.
Distributor Event Messages 1021: ZEMS-EVT-STARTUP-OK 1021: ZEMS-EVT-STARTUP-OK Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROC-ERR ZEMS-TKN-NEWPROCESS-CPU ZEMS-TKN-NEWPROCESS-PRIORITY ZEMS-TKN-NEWPROCESS-ERROR ZEMS-TKN-STARTUP-LOGTIME ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type token-typ
Distributor Event Messages 1021: ZEMS-EVT-STARTUP-OK ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens described in Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has two subject tokens: ZEMS-TKN-PROGRAMFILE (type: ZSPI-TYP-FNAME; nonshared) is the file name of a program file.
Distributor Event Messages 1022: ZEMS-EVT-WRITE-FAILED 1022: ZEMS-EVT-WRITE-FAILED Unconditional Tokens ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROC-ERR ZSPI-TKN-WRITE-FAIL-COUNT ZEMS-MAP-STATUS-DIST token-type token-type token-type token-type token-type token-type token-type token-type token-type token-type ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP.
Distributor Event Messages 1022: ZEMS-EVT-WRITE-FAILED ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-FAILFILENAME (type: ZSPI-TYP-FNAME; nonshared) is the destination name. ZSPI-TKN-PROC-ERR (type: ZSPI-TYP-ENUM; nonshared) is an ordinal identifying the failing procedure. Here EMS assigns the value ZEMSVAL-ZFILWRITEREAD.
Distributor Event Messages 1022: ZEMS-EVT-WRITE-FAILED EMS Manual—426909-005 18-58
19 Collector Commands and Responses Both the basic and extended SPI interfaces support commands that let you manage and monitor the operational environment of the primary and alternate collectors and the compatibility distributor. These interfaces let your application program send a command to or request information from a primary or alternate collector. The interfaces also let you interact indirectly (through $0) with the compatibility distributor.
Collector Commands and Responses Sending a SPI Command A command buffer always contains a command token named ZSPI-TKN-COMMAND, which specifies the command to be carried out. A command buffer can also contain additional tokens that define parameters unique to the command being sent. A response buffer is a group of tokens containing all the information that results when a command is performed. These tokens are: A return token. A response buffer always contains a token named ZSPI-TKNRETCODE.
Collector Commands and Responses Summary of EMS Collector Commands Table 19-1. Collector Commands Command Name Description ZCOM-CMD-ADD Lets you add objects to the collector. The only supported object is the EMS filter (ZCOM-OBJ-FILTER), which can be a compiled filter, a filter table, or a burst filter. You can add a maximum of 10 filters to a single collector. ZCOM-CMD-ALTER Alters objects in the collector. Supported objects are EMS collectors (ZCOM-OBJ-COLL) and EMS filters (ZCOMOBJ-FILTER).
Collector Commands and Responses Common Definitions of ZCOM- Commands Common Definitions of ZCOM- Commands This subsection defines the tokens and error numbers common to the ZCOM-collector commands and the ZEMS-CMD-REPLACE command. While the REPLACE command is not extended SPI compliant, it supports filter objects (ZCOM-OBJ-FILTER) and you can use it to replace a configured filter in an EMS collector with another filter.
Collector Commands and Responses Common Command Tokens for ZCOM- Commands These collector commands do not accommodate pre-D00 tokens that do not support a high PIN or a string file name. Such tokens generate a ZCOM-ERR-TKN-CODE-INV error. Note. These commands are sent directly from the requestor to the EMS collector. An SCP process is not used.
Collector Commands and Responses Common Command Tokens for ZCOM- Commands Basic SPI signifies that the presence of this token in the command is dictated by the basic SPI command language standards that govern multiple objects and responses. Optional signifies that the token is optional and need not be supplied by the user. Ignored signifies that this token is tolerated in the command and ignored.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands ZCOM-TKN-OBJNAME specifies the fully qualified name of the object to be selected for processing. At least one of these tokens must be in the command. If there are multiple occurrences of this token, the collector returns a response record for each OBJNAME token.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands Table 19-4.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands ZSPI-TKN-OBJECT-TYPE contains the type of object from the request to which this is the reply. This value is specified in the call to SSINIT. Its value is of the form ZCOM-OBJ-objtype. ZSPI-TKN-SSID identifies the subsystem that processes the command. In the following response tokens, the subsystem is always defined as ZSPI-VAL-TANDEM.ZSPI-SSNZEMS.ZEMS-VAL-VERSION. This value is specified in the call to SSINIT.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands each error or warning encountered during processing of the command. The following are the required tokens for the error list. Other standard or subsystemspecific tokens can also be in the error list, depending on the type of error. ZSPI-TKN-ERROR specifies the error and identifies the subsystem that prepared the error list. ZCOM-TKN-OBJTYPE specifies the object type of the object in error.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zbds-flags is a field that contains several bit fields that further describe the particular BDS configuration. These bits fields are: zbds-f.enabled is set to 1 if BDS is enabled and set to 0 if BDS is disabled. zbds-f.tmds in the EMS alternate collector, this bit is set to 1 if it is running in TMDS mode; otherwise, it is set to 0. The EMS primary collector always sets this bit to 0. zbds-f.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zbds-num-sim-burst indicates the maximum number of simultaneous event bursts that can be detected. This is the same as the S parameter in EMSACOLL and EMSCCTRL. zbds-num-subj-bytes indicates the maximum number of bytes of the first subject value that are used in determining same events for burst detection and suppression. A length of 0 signifies that the subject value is not used in determining same events.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zbds-f.use-subj is set to 1 if the subject token code is used to determine similar events. This bit is set to 0 if the subject token code is ignored in determining similar events. zbds-f.process-type indicates the process type of the process performing BDS. The alternate collector stores ZEMS-SUBJ-ACOLL in this field; the primary collector stores ZEMS-SUBJ-PCOLL.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands ZEMS-MAP-BDS-STATS is a token map returned in the ZEMS-CMD-STATUS command when the object type is ZCOM-OBJ-COLL (an EMS collector). The fields in this token contain various BDS statistics that are accumulated by the collector.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zbds-numberburstendevts is the number of BURST-END events that have been generated by the collector since BDS was enabled. This count is reset whenever BDS is enabled. ZEMS-MAP-PLF-STATS is the token map returned in the ZCOM-CMD-STATUS command when the object type is ZCOM-OBJ-COLL (an EMS collector). The fields in this token contain various PLF statistics accumulated by the collector.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zburst-state is the state of the event burst. The legal values are: ZEMS-VAL-BSTATE-AVAILABLE ZEMS-VAL-BSTATE-PASS ZEMS-VAL-BSTATE-WATCH ZEMS-VAL-BSTATE-BURST ZEMS-VAL-BSTATE-AVAILABLE signifies that the burst table entry is not in use. ZEMS-VAL-BSTATE-PASS signifies that the burst table entry contains data on a particular event but that no more than one has been encountered in the last zbds-start-interval (T1) seconds.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zburst-subj-ssid is the SSID of the first subject of the event that this entry is monitoring. zburst-subj-tkncode is the token code of the first subject of the event that this entry is monitoring. zburst-subj-length is the byte length of the value of the first subject of the event that this entry is monitoring.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-maxfilennn is the maximum number of log files that are allowed in the current subvolume. zcol-primaryextent is the primary extent of the next log file that is created. zcol-secondaryextent is the secondary extent of the next log file that is created. zcol-writethrucache a value of TRUE (ZSPI-VAL-TRUE) indicates that BUFFERED is off. A value of FALSE (ZSPI-VAL-FALSE) indicates that BUFFERED is on.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands ZEMS-MAP-COL-STATUS is a token map returned in the ZCOM-CMD-STATUS command when the object type is ZCOM-OBJ-COLL (a collector).
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-currentfilename This is the file name of the current log file for the collector responding to the command. zcol-currentrecord is the record number (as received from the FILEINFO procedure) of the last record written to the log file of the collector responding to the command. If the collector is currently switching log files, ZCOL-CURRENTRECORD is -1.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-eventslogged is the total number of event messages an alternate collector has received or a primary collector logged to disk log files since the last system load. zcol-eventsdiscarded is the number of event messages that a collector had to discard because of event message flooding or because BDS or PLF was enabled.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-currentbursts is the number of the currently detected event bursts. ZEMS-MAP-COL-INFO is the token map returned in the ZCOM-CMD-INFO command when the object type is ZCOM-OBJ-COLL (a collector). This contains all the configuration information common to both EMS collectors. The information returned is similar to what is returned in the -COL-STATUS structure of the ZCOM-CMD-STATUS command.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-rotatefiles this value of TRUE (ZSPI-VAL-TRUE) indicates that ROTATEFILES is on. A value of FALSE (ZSPI-VAL-FALSE) indicates that ROTATEFILES is off. zcol-maxfilennnn is the maximum number of log files that are allowed in the current subvolume. zcol-eofrefresh this value of TRUE (ZSPI-VAL-TRUE) indicates that EOFREFRESH is on. A value of FALSE (ZSPI-VAL-FALSE) indicates that EOFFRESH is off.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands collector. The information returned is similar to that returned in the -ACOL-STATUS structure of the ZCOM-CMD-STATUS command. DEFINITION zems-ddl-acol-info12345 02 zcol-poolpages TYPE zspi-ddl-uint. 02 zcol-replyafterwrite TYPE zspi-ddl-boolean. END zcol-poolpages indicates the number of 2-KB pages that the alternate collector has available for buffering events before logging them to disk.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands zcol-cdist-textout is the current textout device of the compatibility distributor. zcol-cdist-user is the current userid employed by the compatibility distributor when writing to the textout device. zcol-cdist-def-textout is the default textout device of the compatibility distributor. Currently, this configuration attribute cannot be altered after the primary collector has started.
Collector Commands and Responses Common Response Tokens for ZCOM- Commands ZEMS-TKN-BURST-SSID is a token of the type ZSPI-TYP-SSID that contains the subsystem ID (SSID) of a bursting event. ZEMS-TKN-BURST-SUBJ-CODE is a token of the type ZSPI-TYP-TOKENCODE that contains the first subject token code of a bursting event. ZEMS-TKN-BURST-SUBJ-VALUE is a token of the type ZSPI-TYP-STRING that contains the value of the first subject token of a bursting event.
Collector Commands and Responses Common Definitions of ZEMS- Commands ZEMS-TKN-EVT-GENTIME is a token of the type ZSPI-TYP-TIMESTAMP that contains the generation timestamp of the event being examined when a PLF error occurred. This token is stored in the ZEMS-TKN-FILTER-ERROR event. ZEMS-TKN-NEW-OBJNAME is a token of the type ZSPI-TYP-STRING that contains the fully qualified name of a new object.
Collector Commands and Responses Common ZSPI-TKN-RETCODE Values ZSPI-TKN-SERVER-VERSION (type uint) is the subsystem version number of the EMS collector. It is contained in a response buffer. ZSPI-TKN-SSID (type ssid) contains ZSPI-SSN-ZEMS, the subsystem ID for the Event Management Service. It is contained in a response buffer.
Collector Commands and Responses Collector Command Descriptions Collector Command Descriptions Each command description in this subsection contains: A brief summary of what the command does Information about command tokens—tokens placed in the command buffer when building a command message Information about response tokens—tokens returned in the buffer as a response message When appropriate, this additional information: Token usage considerations Operational notes Programming notes Err
Collector Commands and Responses ADD Command (ZCOM-CMD-ADD) ADD Command (ZCOM-CMD-ADD) The ZCOM-CMD-ADD command adds one or more filter objects (ZCOM-OBJ-FILTER) to a collector. The filter can be a compiled filter, a filter table, or a burst filter. A maximum of ten filters can be added to a collector, including any combination of compiled filters, filter tables, and one burst filter.
Collector Commands and Responses ALTER Command (ZCOM-CMD-ALTER) The data list (all tokens from -DATALIST to -ENDLIST) forms a single response record. There can be multiple data lists (response records) in a response. Error only signifies that this token is present only when an error or warning is reported in the response record (ZSPI-TKN-RETCODE contains a nonzero value). For a detailed description of these command and response tokens, see Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses ALTER Command (ZCOM-CMD-ALTER) Command Tokens (-OBJ-FILTER) Token Type Usage ZSPI-TKN-MAXRESP ZCOM-TKN-XMGR ZCOM-TKN-REQID-xxxx ZCOM-TKN-OBJNAME ZSPI-TKN-CONTEXT ZSPI-TYP-INT ZSPI-TYP-STRING Basic SPI Optional Optional Required Filter ZSPI-TYPBYTESTRING Basic SPI Response Tokens Token Type Usage ZSPI-TKN-DATALIST ZCOM-TKN-XMGR ZCOM-TKN-RETCODE ZCOM-TKN-OBJTYPE ZCOM-TKN-OBJNAME ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJTYPE ZCOM-TKN-
Collector Commands and Responses ALTER Command (ZCOM-CMD-ALTER) Error only signifies that this token is present only when an error or warning is reported in the response record (ZSPI-TKN-RETCODE contains a nonzero value). For a detailed description of these command and response tokens, see Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) CONTROL Command (ZEMS-CMD-CONTROL) The ZEMS-CMD-CONTROL command lets you programmatically manage the operation of the primary and alternate collectors and the compatibility distributor. You do this by changing the settings of one or more operational attributes for the appropriate process. Table 19-6 shows the attributes you can set when you use the CONTROL command and the EMS process controlled by each attribute. Table 19-6.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) This is detailed information about the tokens and token maps in a CONTROL command buffer: Command ZEMS-CMD-CONTROL Required Tokens or Token Maps Primary Collector Alternate Collector Compatibility Distributor ZEMS-MAP-COL-CONTROL ZEMS-MAP-COL-CONTROL or ZEMS-MAP-ACOL-CONTROL ZEMS-TKN-CDISTPRICPU or ZEMS-MAP-COL-CONTROL-CDIST Tokens in Command Buffer ZEMS-MAP-COL-CONTROL DEF ZEMS-DDL-COL-CONTROL.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) Tokens in Response Buffer ZSPI-TKN-RETCODE ZSPI-TKN-SERVER-VERSION ZSPI-TKN-SSID ZSPI-TKN-COMMAND token-type token-type token-type token-type ZSPI-TYP-ENUM. ZSPI-TYP-UINT. ZSPI-TYP-SSID. ZSPI-TYP-ENUM. Tokens in Command Buffer ZEMS-MAP-COL-CONTROL is an extensible structured token that lets you change collector attributes or give commands to a primary or alternate collector.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) ZCOL-MAXFILENNNN (uint field) specifies the maximum number of files that can exist at one time in the log subvolume. Allowed values for this field are 2 through 1000; the default is 4. ZCOL-PRIMARYEXTENT (uint field) selects the value for the primary extent size used when a collector creates a log file. The value must be expressed as an even number of pages. The default value for this attribute is 20.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) ZCOL-PROTECTION (uint field) defines the read, write, execute, and purge security used when creating disk log files.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) allocated is the same as that described in EMSACOLL—Alternate Collector Program on page 13-2. Note. You must include the ZEMS-MAP-ACOL-CONTROL or ZEMS-MAP-COLCONTROL token in the command buffer when you use the CONTROL command to manage the alternate collector. You can include both tokens in the command buffer if you want to both change alternate collector attributes and allocate MAXFILE log files.
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) ZCOL-CDIST-MODE-SET (enum field) indicates that $Z0 displays only critical events if ON, or all events if OFF. ZCOL-CDIST-USER-SET (userid field) specifies the user ID that the compatibility distributor must use when forwarding event messages to the console from a remote collector (one on another node). You can perform the same operation using the EMSCCTRL command (or the PUP CONSOLE command on systems running the D-series).
Collector Commands and Responses CONTROL Command (ZEMS-CMD-CONTROL) Table 19-7. Values of ZSPI-TKN-RETCODE Specific to CONTROL Command (page 2 of 2) (continued) Name (ZEMS-ERR-) Number Description REQ-TKN 1015 Collector CONTROL command needs ZEMS-TKNCDISTPRICPU, ZEMS-MAP-COL-CONTROL, ZEMS-MAPCOL-CONTROL-CDIST, or ZEMS-MAP-ACOL-CONTROL. LOG-ACCESS 1031 Command could not be completed because an I/O error occurred while the collector was accessing a log file or a ZZEVCONF file.
Collector Commands and Responses DELETE Command (ZCOM-CMD-DELETE) DELETE Command (ZCOM-CMD-DELETE) The ZCOM-CMD-DELETE command deletes objects from the EMS collector. The only supported object is the EMS filter (ZCOM-OBJ-FILTER). At least one object name token is required. Use of the wild-card object name (*) is also supported.
Collector Commands and Responses GETVERSION Command (ZCOM-CMDGETVERSION) GETVERSION Command (ZCOM-CMD-GETVERSION) The ZCOM-CMD-GETVERSION command returns the EMS collector version information and optional supplemental information. Because the values of ZCOMCMD-GETVERSION and ZEMS-CMD-GETVERSION are equal (=0), the basic form of this command is identical to ZEMS-CMD-GETVERSION. However, the newer ZCOMCMD-GETVERSION also returns the ZCOM-TKN-GETVSN-LVL token. The -OBJTYPE token in the command is ignored.
Collector Commands and Responses GETVERSION Command (ZCOM-CMDGETVERSION) Token Usage Considerations Basic SPI signifies that the presence of this token in the command is dictated by the basic SPI command language standards that govern multiple objects and responses. Optional signifies that the token is optional and need not be supplied by the user. Required signifies that the token is required and must be supplied by the user.
Collector Commands and Responses GETVERSION Command (ZEMS-CMDGETVERSION) GETVERSION Command (ZEMS-CMD-GETVERSION) The ZEMS-CMD-GETVERSION command returns the version number of the programmatic interface to the primary or alternate collector. Command ZEMS-CMD-GETVERSION Tokens in Command Buffer None Tokens in Response Buffer ZSPI-TKN-SERVER-BANNER ZSPI-TKN-SERVER-VERSION ZSPI-TKN-RETCODE ZSPI-TKN-SSID ZSPI-TKN-COMMAND ZEMS-TKN-COLLECTOR token-type ZSPI-TYP-CHAR50. token-type ZSPI-TYP-UINT.
Collector Commands and Responses INFO Command (ZCOM-CMD-INFO) INFO Command (ZCOM-CMD-INFO) The ZCOM-CMD-INFO command requests the configuration values of the specified object. These values are initially set at collector startup (performed by SYSGEN or by the TACL RUN command) and might have been modified by ZCOM-CMD-ALTER or ZEMS-CMD-CONTROL. All the configuration attributes are returned in an extensible INFO structure (see EMS-Specific Tokens on page 19-10).
Collector Commands and Responses INFO Command (ZCOM-CMD-INFO) For a detailed description of these command tokens, refer to Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses LISTOBJECTS Command (ZCOM-CMDLISTOBJECTS) Table 19-8.
Collector Commands and Responses LISTOBJECTS Command (ZCOM-CMDLISTOBJECTS) For a detailed description of these command tokens, see Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses REPLACE Command (ZEMS-CMD-REPLACE) REPLACE Command (ZEMS-CMD-REPLACE) The ZEMS-CMD-REPLACE command replaces a configured object in the EMS collector with another object. The only supported object is an EMS filter (ZCOM-OBJFILTER). The filter can be a compiled filter, a filter table, or a burst filter. Only one filter at a time can be replaced in this command.
Collector Commands and Responses STATUS Command (ZCOM-CMD-STATUS) Unconditional signifies that the token always appears in the response. Error only signifies that this token is present only when an error or warning is reported in the response record. If the REPLACE command was successful, the value in the ZCOM-TKNOBJNAME token is the name of the new filter file.
Collector Commands and Responses STATUS Command (ZCOM-CMD-STATUS) For a detailed description of these command tokens, see Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) Response Token Usage Considerations Basic SPI signifies that the presence of this token in the command is dictated by the basic SPI command language standards that govern multiple objects and responses. Unconditional signifies that the token always appears in the response. AC only signifies that the item is returned only by the alternate collector. PC only signifies that the item is returned only by the primary collector.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) Tokens in Response Buffer ZEMS-MAP-COL-STATUS DEF ZEMS-DDL-COL-STATUS.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) Tokens in Response Buffer ZEMS-MAP-COL-STATUS is an extensible structured token that gives you the current values of a collector’s operational attributes and some event-message statistics. For a more detailed description of the collector attribute fields, see CONTROL Command (ZEMS-CMD-CONTROL) on page 19-34. ZCOL-PRIMARYCPU (uint field) is the primary CPU number of the collector responding to the STATUS command.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) ZCOL-SECONDARYEXTENT (uint field) is the current setting of the SECONDARYEXTENT attribute. ZCOL-ROTATEFILES (Boolean field) is the current setting of the ROTATEFILES attribute. ZCOL-MAXFILENNNN (uint field) is the (current) maximum number of log files that the responding collector can create in this log subvolume.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) ZCOL-FILESWITCHES (uint field) is the total number of times a collector has switched log files. This total includes both requested switches and switches triggered by log files becoming full. ZCOL-DISCERRORS (uint field) is the total number of disk errors returned to a collector by the disk process. ZCOL-INVALIDEVENTS (uint field) is the total number of event messages a collector discarded because of eventmessage format errors.
Collector Commands and Responses STATUS Command (ZEMS-CMD-STATUS) ZEMS-MAP-COL-CDIST-STATUS is an extensible structured token that gives you the current values of the operational environment of $Z0 and some event-message statistics. ZCOL-CDISTPRICPU (uint field) is the number of the CPU in which the primary process of the compatibility distributor is running. ZCOL-CDISTBKUPCPU (uint field) is the number of the CPU in which the backup process of the compatibility distributor is running.
Collector Commands and Responses STOP Command (ZCOM-CMD-STOP) ZSPI-TKN-SERVER-VERSION (type uint) is the subsystem version number of the EMS collector. ZSPI-TKN-SSID (type ssid) contains ZSPI-SSN-ZEMS, the subsystem ID for the Event Management Service. ZSPI-TKN-COMMAND (type enum) is the original command. STOP Command (ZCOM-CMD-STOP) The command ZCOM-CMD-STOP is the extended SPI-compliant counterpart to the SPI-basic compliant ZEMS-CMD-STOP and is its functional equivalent.
Collector Commands and Responses STOP Command (ZEMS-CMD-STOP) For a detailed description of these command tokens, see Common Definitions of ZCOM- Commands on page 19-4.
Collector Commands and Responses STOP Command (ZEMS-CMD-STOP) Tokens in Response Buffer ZSPI-TKN-SERVER-VERSION ZSPI-TKN-COMMAND ZSPI-TKN-SSID ZSPI-TKN-RETCODE token-type token-type token-type token-type ZSPI-TYP-UINT. ZSPI-TYP-ENUM. ZSPI-TYP-SSID. ZSPI-TYP-ENUM. Tokens in Response Buffer ZSPI-TKN-SERVER-VERSION (type uint) is the subsystem version number of the EMS collector. ZSPI-TKN-COMMAND (type enum) is the original command.
Collector Commands and Responses STOP Command (ZEMS-CMD-STOP) EMS Manual—426909-005 19-62
20 Collector Event Messages Primary and alternate collectors receive and log event messages sent to them by subsystems. Collectors also generate event messages for their own log files. In general, these event messages report events occurring in the collector environment. The subsystem ID (ZSPI-TKN-SSID) for collector-generated messages is EMS (Event Management Service). Each message has an event number that uniquely identifies it within the group of EMS event messages.
Collector Event Messages Alternate Collector Event Messages The start of event message logging after a system load A log file switch because the current log file was full Alternate Collector Event Messages The alternate collector generates event messages to describe occurrences in the alternate collector environment. The collector writes all these messages to the primary collector log file. It also writes most of the messages to the alternate collector log file.
Collector Event Messages Summary of Collector-Generated Messages Table 20-1. Primary Collector Event Messages (page 2 of 2) (continued) Event Number Symbolic Name (ZEMS-EVT-) Description Critical 520 FILE-ROTATE-PURGE Automatic file purge Y 521 LOGGING-STOPPED Logging has stopped Y 524 LOGTIME-DECREASE Log time decreased Y 525 INVALIDEVENT Invalid event message N 538 BURST-START An event burst, as defined by the BDS configuration parameters, was detected.
Collector Event Messages Tokenized Operator Console Messages (1–511) Table 20-2. Alternate Collector Event Messages (page 2 of 2) (continued) Event Number Symbolic Name (ZEMS-EVT-) Description Critical 533 ACOL-BACKUP-ABENDED Backup process abnormally ended Y 534 ACOL-BACKUP-DELETED CPU failure of backup process Y 535 ACOL-CHECKPOINT-ERROR I/O error during checkpoint Y 536 COL-PURGETABLE-OVRFLO Log file could not be purged automatically.
Collector Event Messages Tokenized Operator Console Messages (1–511) Because these event messages all have the same format—differing only in the ZEMSTKN-EVENTNUMBER and ZEMS-TKN-EMPHASIS flags—after this syntax box is a description of the general format rather than the individual event message.
Collector Event Messages Tokenized Operator Console Messages (1–511) ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, -USERID, and -OPMSG are all standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. Event messages 1 through 511 each have one subject token: ZEMS-TKN-XSYSPID. ZEMS-TKN-XSYSPID is private to HP.
Collector Event Messages Tokenized Text Messages (512) Tokenized Text Messages (512) These tokenized text messages are generated by the primary and alternate collectors. Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-XSYSPID ZEMS-TKN-TEXT ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN.
Collector Event Messages Tokenized Text Messages (512) ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-XSYSPID is private to HP. It contains the system number and PID of some process associated with the event message. ZEMS-TKN-TEXT (nonshared) is the text that was sent to the collector through the call to the WRITE procedure. If the original text is more than 102 bytes, it is truncated to 102 bytes.
Collector Event Messages Collector-Specific Event Messages The ZEMS-TKN-TEXT token holds 102 bytes or fewer of text. If the original text was longer, it is truncated. Collector-Specific Event Messages These event messages describe events associated with the primary and alternate collectors and their environments. The event-message text for each message describes events occurring in each collector’s environment.
Collector Event Messages 513: ZEMS-EVT-COLD-LOAD ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions.
Collector Event Messages 514: ZEMS-EVT-FILESWITCH 514: ZEMS-EVT-FILESWITCH Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-SYSTEM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-LASTLOGFILE ZEMS-TKN-NEWLOGFILE ZEMS-TKN-LOGSWITCHREASON ZEMS-MAP-COL-STATUS ZEMS-TKN-LCT-LOGTIME ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN.
Collector Event Messages 514: ZEMS-EVT-FILESWITCH ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions.
Collector Event Messages ZEMS-TKN-LCT-LOGTIME 514: ZEMS-EVT-FILESWITCH (nonshared) (G-series RVUs only) contains the LCT (local civil time) logtime of the event. Conditional Tokens ZEMS-TKN-ACTION-NEEDED (nonshared) tells whether some action is required (in this case, because the collector stopped logging). The token value is FALSE because logging already resumed with a logfile switch. ZEMS-TKN-ACTION-ID (nonshared) has the value 0.
Collector Event Messages 515: ZEMS-EVT-COLL-DISC-FAILED 515: ZEMS-EVT-COLL-DISC-FAILED Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-ZFILERR ZEMS-TKN-FAILFILENAME ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT.
Collector Event Messages 515: ZEMS-EVT-COLL-DISC-FAILED ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJPCOLL (or 1). ZEMS-TKN-ZFILERR (nonshared) is the error code associated with the event. For an explanation of this error code, see the Operator Messages Manual.
Collector Event Messages 517: ZEMS-EVT-COMPAT-DISTR-STOPPED 517: ZEMS-EVT-COMPAT-DISTR-STOPPED Unconditional Token Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-ZFILERR ZEMS-TKN-COMPATDISTCRTPID ZEMS-TKN-CDIST-CPU-PIN ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 517: ZEMS-EVT-COMPAT-DISTR-STOPPED ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has the value ZEMS-SUBJ-PCOLL (or 1). ZEMS-TKN-ZFILERR (nonshared) is the error code associated with this event. For an explanation of this error code, see the Operator Messages Manual.
Collector Event Messages 518: ZEMS-EVT-COL-EVENT-DISCARDS 518: ZEMS-EVT-COL-EVENT-DISCARDS Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-COL-EVENT-DISCARDS ZEMS-TKN-OPMSG ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 518: ZEMS-EVT-COL-EVENT-DISCARDS ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has the value ZEMS-SUBJ-PCOLL (or 1). ZEMS-TKN-COL-EVENT-DISCARDS (nonshared) is an array of four integers with this DDL definition: DEFINITION ZEMS-DDL-COL-EVENT-DISCARDS. 02 zsendopmsg TYPE zspi-ddl-uint.
Collector Event Messages 519: ZEMS-EVT-MSGR-EVENTS-DISCARDED WRITETHRUCACHE. By using EMSCCTRL with the BUFFERED ON option, you are selecting a buffering mode used by the disk process. When buffering, event messages accumulate in the disk cache-buffer before they are written to disk. This mode of operation involves significantly fewer writes to disk and provides substantial gains in efficiency. Note. The buffering, however, involves a slight risk.
Collector Event Messages 519: ZEMS-EVT-MSGR-EVENTS-DISCARDED ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-MSGR-EVENTS-DISCARDED (519). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE.
Collector Event Messages 520: ZEMS-EVT-FILE-ROTATE-PURGE Changing collector attributes cannot help this problem because messages are discarded before they reach the collector. Event Notes At any time, ZEMS-TKN-MSGR-EVENTS-DISCARDED does not exceed 32767 although more events might have already been discarded.
Collector Event Messages 520: ZEMS-EVT-FILE-ROTATE-PURGE ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions.
Collector Event Messages 521: ZEMS-EVT-LOGGING-STOPPED 521: ZEMS-EVT-LOGGING-STOPPED Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-LOGSTOPREASON ZEMS-TKN-ACTION-NEEDED ZEMS-TKN-ACTION-ID ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 521: ZEMS-EVT-LOGGING-STOPPED ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type.
Collector Event Messages 522: ZEMS-EVT-COLLECTOR-RUN Change ZCOL-ROTATEFILES to TRUE using the CONTROL command or the ROTATEFILES parameter of EMSCCTRL. Purge the oldest file. Change the logging volume or subvolume using the LOGSUBVOL parameter of EMSCCTRL. If a disk fails, locate space for new log files on another volume. You can change the logging volume using the LOGSUBVOL parameter of EMSCCTRL.
Collector Event Messages 522: ZEMS-EVT-COLLECTOR-RUN ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Collector Event Messages 523: ZEMS-EVT-ACOL-EVENT-DISCARDS 523: ZEMS-EVT-ACOL-EVENT-DISCARDS Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-ACOL-EVENTS-DISCARDS ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT.
Collector Event Messages 523: ZEMS-EVT-ACOL-EVENT-DISCARDS ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2). ZEMS-TKN-ACOL-EVENTS-DISCARDS (nonshared) contains a count of the number of events discarded by the alternate collector. Cause.
Collector Event Messages 524: ZEMS-EVT-LOGTIME-DECREASE 524: ZEMS-EVT-LOGTIME-DECREASE Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-OLD-LOGTIME ZEMS-TKN-NEW-LOGTIME ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 524: ZEMS-EVT-LOGTIME-DECREASE ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has one of two values: ZEMS-SUBJPCOLL (or 1) for the primary collector, or ZEMS-SUBJ-ACOLL (or 2) for the alternate collector.
Collector Event Messages 524: ZEMS-EVT-LOGTIME-DECREASE 6. The collector issues a LOGTIME-DECREASE event message, with a log timestamp later than that of event C: Event C (18:58) ... Event L-D (18:59) (At least one event message, C, necessarily has a log timestamp that is out of sequence. In this example, there are two or more such messages: C, L-D, and so on.) 7. One of the distributors issues a positioning command to the collector, requesting all event messages with log timestamps of 19:00 and later.
Collector Event Messages 525: ZEMS-EVT-INVALIDEVENT 525: ZEMS-EVT-INVALIDEVENT Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-XSYSPID ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT. ZSPI-TYP-STRING. ZSPI-TYP-INT.
Collector Event Messages 525: ZEMS-EVT-INVALIDEVENT ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has one of two values: ZEMS-SUBJPCOLL (or 1) for the primary collector, or ZEMS-SUBJ-ACOLL (or 2) for the alternate collector. ZEMS-TKN-XSYSPID (nonshared) is private to HP. It contains the system number and PID of the process that sent the invalid message. Cause.
Collector Event Messages 526: ZEMS-EVT-ACOL-INTERNAL-ERR 526: ZEMS-EVT-ACOL-INTERNAL-ERR Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-CODESEG ZEMS-TKN-PREG ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT.
Collector Event Messages 527: ZEMS-EVT-ACOL-SHUTDOWN ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2). ZEMS-TKN-CODESEG (nonshared) is the code segment number where the error is detected. ZEMS-TKN-PREG (nonshared) is the P register contents where the error is detected. Cause. The alternate collector has encountered an internal error. This event message should never occur.
Collector Event Messages 527: ZEMS-EVT-ACOL-SHUTDOWN ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-ACOL-SHUTDOWN (527). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE.
Collector Event Messages 528: ZEMS-EVT-ACOL-ALLOCATESEG-ERR 528: ZEMS-EVT-ACOL-ALLOCATESEG-ERR Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZEMS-TKN-ZFILERR ZEMS-TKN-SEGALLOC-ERROR ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN.
Collector Event Messages 528: ZEMS-EVT-ACOL-ALLOCATESEG-ERR ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Collector Event Messages 529: ZEMS-EVT-ACOL-CHECKOPEN-FAILED 529: ZEMS-EVT-ACOL-CHECKOPEN-FAILED Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-FAILFILENAME ZEMS-TKN-ZFILERR ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 529: ZEMS-EVT-ACOL-CHECKOPEN-FAILED ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has two subject tokens: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2). ZEMS-TKN-FAILFILENAME (nonshared) is the name of the file that could not be opened by the backup alternate collector.
Collector Event Messages 530: ZEMS-EVT-ACOL-TAKEOVER 530: ZEMS-EVT-ACOL-TAKEOVER Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-TAKEOVER-REASON ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT. ZSPI-TYP-STRING.
Collector Event Messages 530: ZEMS-EVT-ACOL-TAKEOVER ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2).
Collector Event Messages 531: ZEMS-EVT-ACOL-CREATEBACKUP-ERR 531: ZEMS-EVT-ACOL-CREATEBACKUP-ERR Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PROGRAMFILE ZEMS-TKN-NEWPROCESS-CPU ZEMS-TKN-NEWPROCESS-PRIORITY ZEMS-TKN-PROCCREATE-ERROR ZSPI-TYP-SSID.
Collector Event Messages 531: ZEMS-EVT-ACOL-CREATEBACKUP-ERR ZEMS-TKN-EVENTNUMBER (shared) is the event number. Its value is ZEMS-EVT-ACOL-CREATEBACKUP-ERR (531). ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE.
Collector Event Messages 532: ZEMS-EVT-ACOL-BACKUP-CREATED Effect. The primary alternate collector process tries to create the backup again, unless the PROCESS_CREATE_ error indicates that the backup CPU is down. If the backup CPU is not down, the primary alternate collector tries to create a new backup 30 seconds after it receives a CPU RELOADED system message for the backup CPU.
Collector Event Messages 532: ZEMS-EVT-ACOL-BACKUP-CREATED ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is FALSE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions.
Collector Event Messages 533: ZEMS-EVT-ACOL-BACKUP-ABENDED 533: ZEMS-EVT-ACOL-BACKUP-ABENDED Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT. ZSPI-TYP-STRING. ZSPI-TYP-INT.
Collector Event Messages 534: ZEMS-EVT-ACOL-BACKUP-DELETED ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2). Cause. The alternate collector’s backup process has terminated abnormally. Effect. The primary alternate collector process attempts to create a new backup after a 30-second delay. Recovery. Contact your HP representative for assistance; provide the SAVEABEND file from the backup.
Collector Event Messages 534: ZEMS-EVT-ACOL-BACKUP-DELETED ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Here, its value is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Collector Event Messages 535: ZEMS-EVT-ACOL-CHECKPOINT-ERR 535: ZEMS-EVT-ACOL-CHECKPOINT-ERR Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-ZFILERR ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT. ZSPI-TYP-STRING.
Collector Event Messages 535: ZEMS-EVT-ACOL-CHECKPOINT-ERR ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token can have only one value: ZEMS-SUBJACOLL (or 2). Cause. The alternate collector’s backup process received an I/O error during a checkpoint operation. Effect.
Collector Event Messages 536: ZEMS-EVT-COL-PURGETABLE-OVRFLO 536: ZEMS-EVT-COL-PURGETABLE-OVRFLO Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PIN ZEMS-TKN-PROC-DESC ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-PURGEDLOGFILE ZSPI-TYP-SSID. ZSPI-TYP-ENUM. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-UINT.
Collector Event Messages 536: ZEMS-EVT-COL-PURGETABLE-OVRFLO ZEMS-TKN-SUBJECT-MARK (shared) is, for this message, a valueless token. ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has the value 1. ZEMS-TKN-PURGEDLOGFILE (nonshared) is the file name of the file that needs to be purged manually. Cause. The primary collector, $0, is creating log files much faster than the distributors can read them.
Collector Event Messages 537: ZEMS-EVT-COL-CONFIG-WARNING (D-series Only) 537: ZEMS-EVT-COL-CONFIG-WARNING (D-series Only) Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PIN ZEMS-TKN-PROC-DESC ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-CONFIG-ITEM ZEMS-TKN-SPEC-CONFIG-VALUE ZEMS-TKN-USED-CONFIG-VALUE ZSPI-TYP-SSID. ZSPI-TYP-ENUM. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP.
Collector Event Messages 537: ZEMS-EVT-COL-CONFIG-WARNING (D-series Only) ZEMS-TKN-CONFIG-ITEM has the value: ZEMS-VAL-CONFIG-EMSFLAGS. ZEMS-TKN-SPEC-CONFIG-VALUE has the value specified by SYSGEN. ZEMS-TKN-USED-CONFIG-VALUE is the actual value used by $0. Cause. Bit 15 of the EMSFLAGS word in $0 has been set to 1 by SYSGEN during process initialization, just after system load. The configuration file is specifying EMS display format, which is no longer necessary. Effect. None. Recovery.
Collector Event Messages 538: ZEMS-EVT-BURST-START 538: ZEMS-EVT-BURST-START Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-BURST-EVT-NUM ZEMS-TKN-BURST-SSID ZEMS-TKN-BURST-SUBJ-CODE ZEMS-TKN-BURST-SUBJ-VALUE ZEMS-TKN-BURST-SUBJ-SSID ZEMS-TKN-BURST-TIME-START ZEMS-MAP-BDS-INFO token-
Collector Event Messages 538: ZEMS-EVT-BURST-START ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR is the EMS process type (value 1 for the primary collector; value 2 for an alternate collector).
Collector Event Messages 538: ZEMS-EVT-BURST-START proc-desc is from ZEMS-TKN-BURST-PROC-DESC. Cause. An event burst was detected. In BDS configuration parameters terminology, a number (N) of similar events occurred within the T1 time interval. Similar events are those that have the same SSID, event number, and subject. The L burst parameter defines what same subject means. Effect.
Collector Event Messages 539: ZEMS-EVT-BURST-END 539: ZEMS-EVT-BURST-END Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-BURST-EVT-NUM ZEMS-TKN-BURST-SSID ZEMS-TKN-BURST-SUBJ-CODE ZEMS-TKN-BURST-SUBJ-VALUE ZEMS-TKN-BURST-SUBJ-SSID ZEMS-TKN-BURST-TIME-START ZEMS-TKN-BURST-TIME-END ZEMS-
Collector Event Messages 539: ZEMS-EVT-BURST-END ZEMS-TKN-EMPHASIS (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. Its value here is TRUE. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions.
Collector Event Messages 539: ZEMS-EVT-BURST-END ZEMS-TKN-BURST-EVTS-DELETED are occurrences of the bursting event that were not logged during the event burst. ZEMS-TKN-BURST-END-REASON is the reason for the event burst end. A value of ZEMS-VAL-BDS-DISABLED means that the burst ended because BDS was terminated by the operator. A value of ZEMS-VAL-NO-EVENTS means that the burst ended because no further events were detected during the last T2 time units. Text Values eventno is from ZEMS-TKN-BURST-EVT-NUM.
Collector Event Messages 540: ZEMS-EVT-PLF-ERROR 540: ZEMS-EVT-PLF-ERROR Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-COLLECTOR ZEMS-TKN-FILTER-ERROR ZEMS-TKN-FILTERNAME ZEMS-TKN-EVT-EVTNUM ZEMS-TKN-EVT-GENTIME token-type ZSPI-TYP-SSID. token-type ZSPI-TYP-INT. token-type ZSPI-TYP-BOOLEAN.
Collector Event Messages 540: ZEMS-EVT-PLF-ERROR ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token. This event message has one subject token: ZEMS-TKN-COLLECTOR is the EMS process type (value 1 for the primary collector and value 2 for an alternate collector). ZEMS-TKN-FILTER-ERROR is the filter evaluation error. The actual error code denotes a specific problem in interpreting the filter (most likely a compiled filter).
Collector Event Messages 541: ZEMS-EVT-PLF-RELOAD-ERROR Effect. The collector deletes the filter and generates this event. The event is examined by any subsequent filters in the collector and logged if the event passes all the filters. Recovery. This condition can be caused by a corrupted filter (most likely) or event.
Collector Event Messages 541: ZEMS-EVT-PLF-RELOAD-ERROR ZEMS-TKN-CONSOLE-PRINT (shared) is a standard EMS token. For more information, see Section 14, EMS Definitions. ZEMS-TKN-GENTIME, -LOGTIME, -CPU, -PROC-DESC, -PIN, -NODENUM, and -USERID are standard EMS tokens. For more information, see Section 14, EMS Definitions. ZEMS-TKN-SUBJECT-MARK (shared) is the standard EMS token that immediately precedes each subject token.
Collector Event Messages 542: ZEMS^EVT^FILE^UNPURGED 542: ZEMS^EVT^FILE^UNPURGED Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-PURGEDLOGFILE ZEMS-TKN-PROC-DESC ZEMS-TKN-CRTPID ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT.
Collector Event Messages 542: ZEMS^EVT^FILE^UNPURGED ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has one of two values: ZEMS-SUBJPCOLL (or 1) for the primary collector or ZEMS-SUBJ-ACOLL (or 2) for the alternate collector. ZEMS-TKN-PURGEDLOGFILE (nonshared) is the purged log file. Text Values filename is the name of the unpurged log file. proc-desc is the system name of the EMS collector process. Cause. The collector did not purge the log files with the ROTATEFILE option set.
Collector Event Messages 543: ZEMS-EVT-ZLOGBURST 543: ZEMS-EVT-ZLOGBURST Unconditional Tokens Token Type ZSPI-TKN-SSID ZSPI-TYP-SSID. ZEMS-TKN-EVENTNUMBER ZSPI-TYP-INT. ZEMS-TKN-EMPHASIS ZSPI-TYP-BOOLEAN. ZEMS-TKN-CONSOLE-PRINT ZSPI-TYP-BOOLEAN. ZEMS-TKN-GENTIME ZSPI-TYP-TIMESTAMP. ZEMS-TKN-LOGTIME ZSPI-TYP-TIMESTAMP. ZEMS-TKN-CPU ZSPI-TYP-INT. ZEMS-TKN-PROC-DESC ZSPI-TYP-STRING. ZEMS-TKN-PIN ZSPI-TYP-INT. ZEMS-TKN-NODENUM ZSPI-TYP-INT2. ZEMS-TKN-USERID ZSPI-TYP-UINT.
Collector Event Messages 543: ZEMS-EVT-ZLOGBURST ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has one value: ZEMS-SUBJ-ACOLL (or 2) for the alternate collector. ZEMS-TKN-ZLOGFILTERDELETED (nonshared) is the number of events that are deleted. ZEMS-TKN-ZLOGEVENT (nonshared) is the filter event number. ZEMS-TKN-ZLOGFILTERSTART (nonshared) is the filter start date. ZEMS-TKN-ZLOGFILTERDELETED (nonshared) is the number of events that are deleted.
Collector Event Messages 544: ZEMS-EVT-ZLOGLOSTEVENT 544: ZEMS-EVT-ZLOGLOSTEVENT Unconditional Tokens Token Type ZSPI-TKN-SSID ZEMS-TKN-EVENTNUMBER ZEMS-TKN-EMPHASIS ZEMS-TKN-CONSOLE-PRINT ZEMS-TKN-GENTIME ZEMS-TKN-LOGTIME ZEMS-TKN-CPU ZEMS-TKN-PROC-DESC ZEMS-TKN-PIN ZEMS-TKN-NODENUM ZEMS-TKN-USERID ZEMS-TKN-SUBJECT-MARK ZEMS-TKN-ZLOGREASON ZEMS-TKN-ZLOGNUMBERLOSS ZEMS-TKN-ZLOGLOSSCPU ZSPI-TYP-SSID. ZSPI-TYP-INT. ZSPI-TYP-BOOLEAN. ZSPI-TYP-BOOLEAN. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-TIMESTAMP. ZSPI-TYP-INT.
Collector Event Messages 544: ZEMS-EVT-ZLOGLOSTEVENT ZEMS-TKN-COLLECTOR (nonshared) specifies the collector type. This token has one value: ZEMS-SUBJ-ACOLL (or 2) for the alternate collector. ZEMS-TKN-ZLOGREASON (nonshared) states the reason for the loss of the event messages. ZEMS-TKN-ZLOGNUMBERLOSS (nonshared) is the number of events lost. ZEMS-TKN-ZLOGLOSSCPU (nonshared) is the CPU that lost the events. Text Values reason states why the events were not logged. count1 is the number of lost events.
21 Distributor Errors This section lists error codes and warning codes returned by the distributor: Topic Page Token and Data Type Definitions 21-1 Distributor Warning Codes 21-4 Distributor Error Codes 21-6 Following the code of each error or warning is a box with the name and type of tokens that constitute the related error list. Following the box a description of the error’s cause, effect, and recovery actions that can be taken.
Distributor Errors SPI Token Codes ZSPI-TKN-ERRLIST (type list) is the SPI token that begins an error list. ZSPI-TKN-ERROR (type error) is the standard SPI error token. The DDL for ZSPI-TKN-ERROR is: DEFINITION ZSPI-DDL-ERROR. 02 Z-SSID TYPE ZSPI-DDL-SSID. 02 Z-ERROR TYPE ZSPI-DDL-ENUM. END ZSPI-TKN-PARM-ERR is the standard SPI error token. The DDL for ZSPI-TKN-PARM-ERR is: DEF ZSPI-DDL-PARM-ERR. 02 Z-TOKENCODE TYPE ZSPI-DDL-TOKENCODE. 02 Z-INDEX TYPE ZSPI-DDL-UINT. 02 Z-OFFSET TYPE ZSPI-DDL-UINT.
Distributor Errors EMS Token Codes EMS Token Codes These EMS tokens occur in distributor error lists: ZEMS-TKN-BLOCKLENGTH (type int; nonshared) is the block length of a log file. ZEMS-TKN-COLNAME (type fname; nonshared) if specified, is the name of a collector associated with the distributor reporting the error; otherwise it is set to blanks. See ZEMS-TKN-COLNAME-ENUM.
Distributor Errors Distributor Warning Codes ZEMS-TKN-FILTER-ERROR (type nonshared) is private to HP. ZEMS-TKN-LOGNAME (type fname; nonshared) is the file name of the log file in use when the error occurred. ZEMS-TKN-RECORD-ADDRESS (type int2; nonshared) is an entry-sequenced file address. Suppose blknum is the block number (numbering from zero), blklen is the block length (in bytes), and recnum is the record number (within the block).
Distributor Errors 503: ZEMS-WRN-TOO-LATE Effect. The distributor starts event retrieval with the first event in the oldest log in the log chain attached to a collector. Recovery. Ignore this warning, or specify a time that falls within the range of the log chain. 503: ZEMS-WRN-TOO-LATE ZSPI-TKN-ERRLIST ZEMS-TKN-COLNAME ZEMS-TKN-LOGNAME ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause.
Distributor Errors Distributor Error Codes Distributor Error Codes These distributor errors vary in seriousness, depending on the context in which they occur: 1001: ZEMS-ERR-VERSION ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The distributor does not support the version you supplied in the command message. Effect. The command is not executed. Recovery.
Distributor Errors 1004: ZEMS-ERR-INV-TKN 1004: ZEMS-ERR-INV-TKN ZSPI-TKN-ERRLIST ZSPI-TKN-PARM-ERR ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The distributor received a command message with an unnecessary or unrecognized token. Effect. The command is not executed. Recovery. Check that you specify only needed and recognizable tokens in your command.
Distributor Errors 1007: ZEMS-ERR-MODE-CONFLICT 1007: ZEMS-ERR-MODE-CONFLICT ZSPI-TKN-ERRLIST ZSPI-TKN-PARM-ERR ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The distributor received a command message that is inappropriate for this type of distributor. Effect. The command is not executed. Recovery. Make sure your command is appropriate for this type of distributor.
Distributor Errors 1016: ZEMS-ERR-INV-HEADERTYPE Recovery. Make sure you provide all tokens required in the specified command. 1016: ZEMS-ERR-INV-HEADERTYPE ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-COMMAND ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL Cause. The distributor received a command message with an invalid header type. Effect. The command is not executed. Recovery. Use a valid header type in the command.
Distributor Errors 1020: ZEMS-ERR-FLT-LOAD -1 Filter too big to fit into supplied buffer. -2 Filter format invalid. -3 Version incompatibility. Cause. The distributor received a command message for processing a filter that is not in the expected format. Either the filter is too big to fit in the supplied buffer, the filter format is invalid, or a version incompatibility was detected. The filter possibly was compiled with a version newer than the version supported by the distributor. Effect.
Distributor Errors 1024: ZEMS-ERR-HIST-MODE 1024: ZEMS-ERR-HIST-MODE ZSPI-TKN-ERRLIST ZSPI-TKN-PARM-ERR ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The distributor cannot perform this operation in log file mode. An attempt was made to add or delete a source collector while the distributor is currently connected to a log file source. Effect. The operation is not performed. Recovery.
Distributor Errors 1027: ZEMS-ERR-COLL-NOT-FOUND 1027: ZEMS-ERR-COLL-NOT-FOUND ZSPI-TKN-ERRLIST ZSPI-TKN-PARM-ERR ZEMS-DISCONNECT-SRC-COLL ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL ZSPI-TKN-PARM-ERR gives the token code and index (but not the value) of the ZEMS-TKNDISCONNECT-SRC-COLL token, which caused the error.
Distributor Errors 1032: ZEMS-ERR-EOF 1032: ZEMS-ERR-EOF ZSPI-TKN-ERRLIST ZEMS-TKN-LOGNAME ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The distributor is in log file mode, and you requested a log file position that is past the end-of-file position on the log file. The distributor reached an end-of-file while using the specified log file as its event message source. Effect.
Distributor Errors 1036: ZEMS-ERR-DEST-ACCESS Recovery. Remove another TEXTOUT destination first, or use another printing distributor.
Distributor Errors 1038: ZEMS-ERR-DEST-NOT-FOUND 1038: ZEMS-ERR-DEST-NOT-FOUND ZSPI-TKN-ERRLIST ZSPI-TKN-PARM-ERR ZEMS-TKN-DELETE-TEXTOUT ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL ZSPI-TKN-PARM-ERR gives the token code and index (but not the value) of the token that caused the error (ZEMS-TKN-DELETE-TEXTOUT).
Distributor Errors 1042: ZEMS-ERR-BAD-FILTER ZSPI-VAL-SSGETTKN ZSPI-VAL-SSGET ZSPI-VAL-SSPUTTKN ZSPI-VAL-SSMOVE 3 2 8 4 Cause. The distributor detected a SPI error while processing a command or control buffer. Effect. The command is not executed. Recovery. This is an internal error. Report it to your service provider.
Distributor Errors 1045: ZEMS-ERR-DEVTYPE Effect. The event cannot be retrieved, or positioning cannot be done. Recovery. Add an event source.
Distributor Errors 1047: ZEMS-ERR-BAD-EVENT ZEMS-VAL-EMSGET 32 Cause. The distributor cannot interpret the reply from a collector following a status request because the collector malfunctioned or aborted. This can occur when adding an event source collector or a process that is not a collector, or during event processing after end-of-file detection. Effect. The distributor disconnects the failing collector but continues to run. Recovery.
Distributor Errors 1050: ZEMS-ERR-COLL-DISCONNECT source collector is disconnected. The distributor continues to run. The application may reconnect the source after the problem is identified and corrected. Recovery. Try to determine the nature of the invalid events and where they came from. An application might have generated the log file, which HP does not recommend.
Distributor Errors 1052: ZEMS-ERR-STATUS-ONLY 1052: ZEMS-ERR-STATUS-ONLY ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. An application issued a CONTROL command, or an ADD, ALTER, GETEVENT, or DELETE command to a consumer, printing, or forwarding distributor for which it did not have permission or is in use by another user. Only info or status commands are allowed for a secondary opener.
Distributor Errors 1061: ZEMS-ERR-DIST-ALLOC 1061: ZEMS-ERR-DIST-ALLOC ZSPI-TKN-ERRLIST ZEMS-TKN-FAILFILENAME ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. An ADD FILTER command was issued to allocate a routing distributor destination, such as a print buffer, but the combined resources for event source, destination, and filter parameter buffers exceed the available buffer pool size. Effect.
Distributor Errors 1064: ZEMS-ERR-STARTUP-FAILED 1064: ZEMS-ERR-STARTUP-FAILED ZSPI-TKN-ERRLIST ZSPI-TKN-PROC-ERR ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROGRAMFILE ZSPI-TKN-ZFILERR ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-UINT token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL ZSPI-TKN-PROC-ERR can have the values: ZEMS-VAL-NEWPROCESS ZEMS-VAL-ZFILOPEN ZEMS-VAL-ZFILWRITE Cause.
22 Collector Errors This section lists the error codes returned by the primary and alternate EMS collectors in their three categories: Topic Page ZCOM- Errors (Over Extended SPI Interface) 22-2 ZEMS- Errors (Over Extended SPI Interface) 22-10 ZEMS- Errors (Over Basic SPI Interface) 22-19 These categories are based on the type of SPI-compliant collector commands to which the collectors send the errors in response.
Collector Errors ZCOM- Errors (Over Extended SPI Interface) ZCOM- Errors (Over Extended SPI Interface) These errors can be returned by a collector through the SPI common extension interface in response to extended SPI-compliant (ZCOM-) collector commands documented in Section 19, Collector Commands and Responses. Token and Data Type Definitions for ZCOM- Errors Collector error lists returned in response to extended SPI-compliant ZCOM- commands include tokens and values defined by SPI (prefixed by ZSPI).
Collector Errors Token and Data Type Definitions for ZCOM- Errors ZSPI-TKN-PARM-ERR is the standard SPI error token and identifies the token used to establish context. The ZSPI-TKN-PARM-ERR token gives the token code and index (but not the value) of a command parameter token used in error. ZSPI-TKN-PROC-ERR (type enum) specifies a procedure associated with the error. (The exact association depends on the particular error and is described with the related ZSPI-TKN-ERROR value.
Collector Errors -3: ZCOM-ERR-CMD-INV-IN-SUMSTATE ZSPI-TKN-ERROR.Z-ERROR (type enum) contains the SPI error number (ZSPI-ERROR-error). ZSPI-TKN-ERROR.PROC-ERROR (type int) identifies the SPI procedure that encountered the error (ZSPI-VAL-proc). ZSPI-TKN-ENDLIST (type ssctl) marks the end of the nested file-system error list. ZSPI-TKN-ENDLIST (type ssctl) is the SPI token that ends a list—an error list in this section.
Collector Errors -5: ZCOM-ERR-CMD-NOT-SUPP -5: ZCOM-ERR-CMD-NOT-SUPP ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL Cause. The request specifies a command that is the EMS collector does not support. Effect. The request is not executed. Recovery. Make sure to specify commands supported by the EMS collector.
Collector Errors -22: ZCOM-ERR-SECUR-VIOL -22: ZCOM-ERR-SECUR-VIOL ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL Cause. An unauthorized user issued a sensitive command. The command requires that the requester have a super ID access privilege in the case of a primary collector, or have the same access ID as the alternate collector process.
Collector Errors -25: ZCOM-ERR-SUB-NOT-FOUND -25: ZCOM-ERR-SUB-NOT-FOUND ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL Cause. The command contained the ZCOM-TKN-SUB token, but no subordinate objects of the specified type were found. Effect. The command is not executed. Recovery.
Collector Errors -28: ZCOM-ERR-TKN-LEN-INV -28: ZCOM-ERR-TKN-LEN-INV ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The specified variable length token is too large. The collector fully resolves object name token values.
Collector Errors -32: ZCOM-ERR-VSN-INCOMP -32: ZCOM-ERR-VSN-INCOMP ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-SERVER-VERSION ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-VERSION token-type ZSPI-TYP-SSCTL Cause. The command contains token maps with a higher version number than this collector can support. Effect. The command is not executed. Recovery.
Collector Errors ZEMS- Errors (Over Extended SPI Interface) ZEMS- Errors (Over Extended SPI Interface) These errors can be returned by EMS collectors through the extended SPI-compliant interface in response to ZCOM- command. Token and Data Type Definitions for ZEMS- Errors Collector error lists returned in response to extended SPI-compliant ZCOM- collector commands include tokens and values defined by SPI (prefixed by ZSPI).
Collector Errors Token and Data Type Definitions for ZEMS- Errors ZSPI-TKN-PROC-ERR (type enum) specifies a procedure associated with the error. (The exact association depends on the particular error and is described with the related ZSPI-TKN-ERROR value.
Collector Errors 1008: ZEMS-ERR-INV-OBJECT ZEMS-TKN-FAILFILENAME (type fname; nonshared) is the file name of a bad log file. ZEMS-TKN-FAIL-REASON (type enum) if caused by a filter table that would not convert to the object form, then the value of this token contains the row and column of the first syntax error in the filter table. The column is in the upper six bits; the row is in the lower ten bits. ZEMS-TKN-FILTER-ERROR (type enum; nonshared) is internal and private to HP.
Collector Errors 1010: ZEMS-ERR-CPU-RANGE 1010: ZEMS-ERR-CPU-RANGE ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. A switch CPU command was issued, but the collector received a command message with an invalid CPU number (that is, not in the range 0 through 15). Effect.
Collector Errors 1020: ZEMS-ERR-FLT-LOAD Cause. The collector received a command message for processing a filter that is not in the expected format. The filter might be too big to fit in the supplied buffer, the filter format is invalid, or a version incompatibility was detected. The filter might have been compiled with a version newer than the version supported by the collector. If the specified filter is a burst filter or filter table edit file, it cannot be converted to an object form. Effect.
Collector Errors 1034: ZEMS-ERR-OPEN-LOG 1034: ZEMS-ERR-OPEN-LOG ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-ZFILERR ZEMS-TKN-FAILFILENAME ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-UINT token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-SSCTL Cause. An ALTER collector (or CONTROL) command has been received to change the current logging subvolume.
Collector Errors 1040: ZEMS-ERR-ZFIL 1040: ZEMS-ERR-ZFIL ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZEMS-TKN-ZFILERR ZEMS-TKN-FAILFILENAME ZSPI-TKN-PROC-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-UINT token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-???? token-type ZSPI-TYP-SSCTL ZSPI-ERR-PROC-ERR can have the values: ZEMS-VAL-FILNM-RESOLVE ZEMS-VAL-FILNM-TO-OFILNM ZEMS-VAL-OFILNM-T
Collector Errors 1054: ZEMS-ERR-CDIST-DOWN 1054: ZEMS-ERR-CDIST-DOWN ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The primary collector received a CONTROL or ALTER command for the compatibility distributor, but the distributor is not running. Effect.
Collector Errors 1067: ZEMS-ERR-ZOPR-SEND 1067: ZEMS-ERR-ZOPR-SEND ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZCOM-TKN-OBJNAME ZCOM-TKN-OBJTYPE ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-STRING token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL Cause. A communication error occurred between $0 and $ZOPR. This error might be the result of a command that involves file system IO, such as ADD FILTER. Effect. The command fails. Recovery. Retry the command.
Collector Errors ZEMS- Errors (Over Basic SPI Interface) ZEMS- Errors (Over Basic SPI Interface) These errors can be returned by EMS collectors through the basic SPI-compliant interface in response to ZEMS- collector command. Token and Data Type Definitions Collector error lists include some tokens and values defined by SPI (prefixed by ZSPI) as well as those defined by EMS (prefixed by ZEMS).
Collector Errors 1001: ZEMS-ERR-VERSION ZSPI-TKN-PROC-ERR can have these values for EMS collectors using the basic SPI interface: ZEMS-VAL-FILTER-EVAL ZEMS-VAL-ZFILAWAITIO ZEMS-VAL-ZFILOPEN ZEMS-VAL-ZFILPOSITION ZEMS-VAL-ZFILREAD ZEMS-VAL-ZFILWRITE ZEMS-VAL-ZFILWRITEREAD ZEMS-VAL-FILTER-READ ZEMS-VAL-FILTER-VERIFY ZEMS-VAL-EMSADDBUFFER ZEMS-VAL-EMSADDSUBJECT ZEMS-VAL-EMSADDTOKENS ZEMS-VAL-EMSGET ZEMS-VAL-EMSINIT ZEMS-VAL-EMSSEND ZEMS-VAL-CHECKOPEN ZEMS-VAL-NEWPROCESS ZEMS-VAL-CHECKPOINT ZEMS-VAL-CHECKMONI
Collector Errors 1002: ZEMS-ERR-INV-CMD Recovery. Check that you use versions of the collector and operating system that are compatible with each other. 1002: ZEMS-ERR-INV-CMD ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The collector has received an invalid command message. Effect. The command is not executed. Recovery.
Collector Errors 1005: ZEMS-ERR-INV-VALUE 1005: ZEMS-ERR-INV-VALUE ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The collector received a command message with a bad token; the token value is invalid. Effect. The command is not executed. Recovery. Check that you specify valid token values.
Collector Errors 1009: ZEMS-ERR-INV-CPU 1009: ZEMS-ERR-INV-CPU ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The ZCOL-PRIMARYCPU DDL definition contains an invalid CPU number. Because ZCOL-PRIMARYCPU directs the collector to operate in its backup CPU, ZCOL-PRIMARYCPU must contain the CPU number of the current backup CPU. Effect. The command is not executed. Recovery.
Collector Errors 1015: ZEMS-ERR-REQ-TKN 1015: ZEMS-ERR-REQ-TKN ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-SSCTL Cause. The collector received a collector CONTROL command message that is missing a required token. You must include at least one of these tokens: ZEMS-MAPCOL-CONTROL-CDIST, ZEMS-MAP-COL-CONTROL, or ZEMS-TKN-CDISTPRICPU. (ZEMS-MAP-COL-CONTROL-CDIST and ZEMS-TKN-CDISTPRICPU are mutually exclusive; do not include both.
Collector Errors 1034: ZEMS-ERR-OPEN-LOG 1034: ZEMS-ERR-OPEN-LOG ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-ZFILERR ZEMS-TKN-FAILFILENAME ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-UINT token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-SSCTL Cause. The collector has received a collector CONTROL command message that contains a ZEMS-TKN-LOGSUBVOL token, but the collector cannot access the specified volume or subvolume.
Collector Errors 1041: ZEMS-ERR-ZSPI 1041: ZEMS-ERR-ZSPI ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-PROC-ERR ZSPI-TKN-ENDLIST ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-ENUM token-type ZSPI-TYP-SSCTL token-type ZSPI-TYP-SSCTL ZSPI-TKN-PROC-ERR (in the second (nested) ZEMS-ERR-ZSPI error
Collector Errors 1053: ZEMS-ERR-INV-MODE 1053: ZEMS-ERR-INV-MODE ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZSPI-TKN-PARM-ERR ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-DDL-PARM-ERR token-type ZSPI-TYP-SSCTL Cause. The primary collector received a command message with an invalid mode for the compatibility distributor: the field ZCOL-CDIST-MODE-SET, in the token map ZEMS-MAP-COL-CONTROL-CDIST, contained an invalid value.
Collector Errors 1056: ZEMS-ERR-ALLOC-LOG 1056: ZEMS-ERR-ALLOC-LOG ZSPI-TKN-ERRLIST ZSPI-TKN-ERROR ZEMS-TKN-ZFILERR ZEMS-TKN-FAILFILENAME ZSPI-TKN-ENDLIST token-type ZSPI-TYP-LIST token-type ZSPI-TYP-ERROR token-type ZSPI-TYP-UINT token-type ZSPI-TYP-FNAME token-type ZSPI-TYP-SSCTL Cause. An alternate collector log file could not be allocated. Effect. The command is not executed. Recovery. Make more space in the LOGSUBVOL.
Part VI: EMS Example Files This part of the manual contains sample code and source files for many of the EMS procedures discussed throughout this manual: Appendix A, Example of Retrieving Event Messages Appendix B, Example of Reporting Events Appendix C, Standard Event Sample Files EMS Manual—426909-005
Part VI: EMS Example Files EMS Manual—426909-005
A Example of Retrieving Event Messages This appendix presents a complete working example of a management application in four versions: a TAL version, a TACL version, a COBOL version, and a C version. The example includes a filter specification and a DDL file.
Example of Retrieving Event Messages Running the TAL Version Running the TAL Version To run the TAL version of this application: 1. Load the TACL macro LDQ (load quietly), which is defined as: ?SECTION LDQ MACRO #PUSH:DUMMY #LOAD /KEEP 1, LOADED:DUMMY/ %1% #POP:DUMMY 2. Load the definition files for the programmatic interface, the EMS subsystem, and MYAP by entering these TACL commands at your terminal: DDL LDQ LDQ LDQ EMF TAL RUN /IN MYAPDDL/ $SYSTEM.ZSPIDEF.ZSPITACL $SYSTEM.ZSPIDEF.
Example of Retrieving Event Messages Overview of Application Logic Overview of Application Logic The example application in this appendix: 1. Starts a consumer distributor 2. Prompts the user for a CPU number 3.
Example of Retrieving Event Messages DDL Source File DDL Source File A DDL file is necessary to event-message retrieval only for passing parameters to an event-message filter. This file contains DDL source statements to pass a CPU parameter to the filter: ! File name: MYAPDDL ?DICT ! ?NOLIST ?SOURCE $SYSTEM.ZSPIDEF.
Example of Retrieving Event Messages Filter Source File Filter Source File This file contains filter source statements: == File name: MYAPFSRC [#SET myap^val^ssid [myap^val^owner].[myap^ssn^myap].
Example of Retrieving Event Messages TAL Source File ?NOLIST, SOURCE MYAPTAL ?LIST LITERAL true = 1; LITERAL false = 0; INT .term^name[0:11], term, .rcv^name[0:11] := ["$RECEIVE",8*[" "]], rcv, ct^rd, error; INT .distr^name[0:11] := [12*[" "]], distr, .distr^prog^file[0:11] := ["$SYSTEM SYSTEM EMSDIST "], cpu^num, .
Example of Retrieving Event Messages TAL Source File ! ************* SPI Definitions ****************** ! Declare SSIDs STRUCT .zems^val^ssid(zems^val^ssid^def); STRUCT .myap^val^ssid(myap^val^ssid^def); INT .coll^name[0:11] := ["$0",11*[" "]], .filt^name[0:11] := ["$SYSTEM FILT MYAPFOBJ"]; ?NOLIST ?SOURCE $SYSTEM.SYSTEM.
Example of Retrieving Event Messages TAL Source File IF ( ( ERROR = 0 ) AND ( CPU^NUM >= 0 ) ) THEN got^it := true; END; ! WHILE END; ?PAGE PROC send^spi^cmd; BEGIN ! ! ! ! ! This procedure accepts, in spi^buf, a command message prepared by another procedure, such as the spi^cmd^set^source procedure, below. The send^spi^cmd procedure sends the command message to the distributor and checks the response message.
Example of Retrieving Event Messages TAL Source File ZSPI^VAL^CMDHDR, ZEMS^CMD^CONTROL); IF spi^err <> ZSPI^ERR^OK THEN CALL DEBUG; ! Place the connect-source-collector token in buffer spi^err := SSPUTTKN(spi^buf, ZEMS^TKN^CONNECT^SRC^COLL, coll^name); IF spi^err <> ZSPI^ERR^OK THEN CALL DEBUG; ! Send the command message to the distributor CALL send^spi^cmd; END; ?PAGE PROC spi^cmd^load^filter; BEGIN ! This proc builds a command message that loads a filter ! into the distributor and passes one filter para
Example of Retrieving Event Messages TAL Source File etxt^stat := EMSTEXT(event^buf, EVT^TEXT^BUF, evt^text^len, num^evt^lines, actual^len, , , 1); ! ! ! ! ! ! Displayable line length Number of display lines Line lens stored here Reserved Indent default Console compatible ! Check for EMSTEXT calling errors IF $HIGH (etxt^stat) = 0 and $INT (etxt^stat) <> 0 THEN CALL DEBUG; ! Display the text FOR i := 0 TO num^evt^lines-1 DO BEGIN IF (actual^len[i] <> -1) THEN BEGIN retry1: CALL WRITE (term, evt^text^bu
Example of Retrieving Event Messages TAL Source File WHILE msgcount < msglimit OR msglimit = 0 DO BEGIN msgcount := msgcount + 1; ! Send GETEVENT command message to the distributor CALL send^spi^cmd; ! Find the event message within the GETEVENT response tkn := ZEMS^TKN^EVENT; spi^err := SSGETTKN ( spi^buf, ZSPI^TKN^ADDR, tkn, 1, @event^buf); IF spi^err <> ZSPI^ERR^OK THEN CALL DEBUG; ! Move past the length part (variable length token) @event^buf := @event^buf + 2D; ! Display the event message at your term
Example of Retrieving Event Messages TAL Source File CALL MYTERM ( term^name ); CALL OPEN ( term^name, term ); ! OPEN $RECEIVE file CALL OPEN ( rcv^name, rcv, , 1 ); IF <> THEN CALL DEBUG; ! Read startup message from $RECEIVE CALL READUPDATE ( rcv, startup^msg, $LEN(startup^msg), ct^rd ); IF <> THEN CALL DEBUG; CALL REPLY ( , , , , 0 ); IF <> THEN CALL DEBUG; ! Create a name for the distributor process CALL CREATEPROCESSNAME ( distr^name ); IF <> THEN CALL DEBUG; ! Set up the startup message - distributor
Example of Retrieving Event Messages TAL Source File CALL DEBUG; ! Tell distributor to use collector log files as ! the source of event messages CALL spi^cmd^set^source; ! Load the filter and filter parameter(s) ! into the distributor CALL spi^cmd^load^filter; ! Retrieve and display event messages CALL getevent^loop; CALL STOP; END; EMS Manual—426909-005 A-13
Example of Retrieving Event Messages TACL Source File TACL Source File This file contains the main TACL source: ?TACL MACRO == File name: MYAPMAIN == == MYAPMAIN == - Starts and opens a consumer distributor == - Gets a CPU number from the user == - Issues an SPI CONTROL command message to == connect collector $0 == load a filter file == load a filter param == (cpu-number from user) == - Performs the following steps in a loop: == -- Issue SPI GETEVENT command message == -- Display event on home terminal ==
Example of Retrieving Event Messages TACL Source File ] == Initialize SSID for MYAP [#IF [#MATCH [myap^val^ssid] 0.0.0] |THEN| #SET myap^val^ssid & [MYAP^VAL^OWNER].[MYAP^SSN^MYAP].[MYAP^VAL^VERSION] ] #PUSH distr_request distr_reply distr_error #DEF bell STRUCT BEGIN CHAR c; BYTE b REDEFINES c; END; #SET bell:b 7 == ASCII value for BEL character. #PUSH emphasis == Tells if event should be emphasized.
Example of Retrieving Event Messages TACL Source File spi^buf MYAP^TKN^PARAM^CPU [cpu^num]] [#IF spi^err |THEN| *** [spi^err] on #SSPUT of CONNECT^SRC^COLL] == Send the entire buffer to the distributor. #APPENDV distr_request spi^buf #EXTRACTV distr_reply spi^buf [#IF distr_error |THEN| *** [distr_error] sending CONTROL command] == Change buffer length to what was declared.
Example of Retrieving Event Messages TACL Source File == Save the original command #SETBYTES sav^buf spi^buf == Begin loop that gets and displays event messages [#LOOP |WHILE| -1 |DO| == Send GETEVENT command message to the distributor.
Example of Retrieving Event Messages TACL Source File ZSPI^TKN^CONTEXT] == If no CONTEXT token, we are at end [#IF spi^err = ZSPI^ERR^MISTKN |THEN| #UNFRAME #RETURN ] [#IF spi^err |THEN| *** [spi^err] on #SSMOVE of CONTEXT] == Move updated command to spi^buf for next time == through loop #SETBYTES spi^buf sav^buf ] == WHILE #UNFRAME ] {getevent^loop} == End of getevent^loop ----------------------------------== This is the main program ------------------------------== Start the distributor process $SYSTEM.
Example of Retrieving Event Messages COBOL Source File COBOL Source File This file contains the main COBOL source: * File name: MYAPMAIN ------------------------------------* * The MYAP application does the following: * * - Starts and opens a consumer distributor * * - Prompts you at your terminal for a CPU number * * - Issues SPI CONTROL command messages to * * connect the collector $0 * load a filter file * load a filter param * (cpu-number from user) * * - Performs the following steps in a loop: * -- I
Example of Retrieving Event Messages COBOL Source File RECORD IS VARYING. COPY zems-ddl-msg-buffer OF $system.zspidef.zemscob REPLACING ==ZEMS-DDL-MSG-BUFFER== BY ==distr-rec==. WORKING-STORAGE SECTION. 01 actual-len-g. 02 actual-len NATIVE-2 OCCURS num-evt-lines TIMES. 01 coll-name. 02 PIC X(8) VALUE "$0". 02 PIC X(8) VALUE SPACES. 02 PIC X(8) VALUE SPACES. 01 cpu-num NATIVE-2. 01 distr-name PIC X(24) VALUE SPACES. 01 distr-name-qual PIC X(24) VALUE SPACES. 01 distr-prog-file PIC X(30) VALUE "$SYSTEM.
Example of Retrieving Event Messages COBOL Source File * * Prepare the startup message with "TYPE" parameter for distributor (CONSUMER).
Example of Retrieving Event Messages COBOL Source File * Place the filter-parameter token in the buffer ENTER "SSPUT" USING distr-rec, myap-tkn-param-cpu cpu-num, OMITTED, myap-val-ssid GIVING error-flag IF error-flag NOT = ZERO ENTER "DEBUG" END-IF * Send command message to distributor and get response READ distr-process WITH PROMPT distr-rec AT END ENTER "DEBUG" END-READ * Protect against a longer buffer in the distributor ENTER "SSPUT" USING distr-rec, zspi-tkn-reset-buffer, zems-val-buflen GIVING
Example of Retrieving Event Messages COBOL Source File * Protect against a longer buffer in the distributor ENTER "SSPUT" USING distr-rec, zspi-tkn-reset-buffer, zems-val-buflen GIVING error-flag IF error-flag NOT = ZERO ENTER "DEBUG" END-IF * Check return code in GETEVENT command response ENTER "SSGET" USING distr-rec, zspi-tkn-retcode, ems-err GIVING error-flag IF error-flag NOT = ZERO ENTER "DEBUG" END-IF IF ems-err NOT = ZERO ENTER "DEBUG" END-IF * * Get the offset of the event-message in the res
Example of Retrieving Event Messages C Source File DISPLAY evt-text-line (ind) (1: actual-len (ind)) END-PERFORM * * * * * Move context token from the reply into the copy of the orig.
Example of Retrieving Event Messages #pragma #pragma #pragma #pragma #pragma #pragma C Source File INSPECT,SYMBOLS NOMAP NOLMAP RUNNABLE NOXMEM HEAP 20 pages #include #include #include #include #include #include nolist nolist nolist nolist nolist /* CCG, etc.
Example of Retrieving Event Messages C Source File error; /* install loc */ char distr_prog_file[25] = "$SYSTEM SYSTEM /* starts blank */ char distr_proc_name[25] = " char *distr_qual = &distr_proc_name[8]; */ EMSDIST "; "; /* for #zspi int cpu_num, used_len, ems_err; /* spi buffers and such */ int spi_err; EMSBUFDEF *spi_buf; EMSBUFDEF *sav_buf; SPIERRDEF *err_buf; int ibuflen = ZEMS_VAL_BUFLEN; int msgcount = 0; int msglimit = 0; /* 0 represents no limit.
Example of Retrieving Event Messages C Source File /* Note that the following code is order-dependent since using FNAMEEXPAND to directly set the 'defaults' field overwrites the front of 'infile' */ strcpy((char *)TempDefaults, "$SYSTEM SYSTEM "); strcpy(ExternFile, (char *)getenv("DEFAULTS")); strcat(ExternFile, ".
Example of Retrieving Event Messages C Source File /* Determine how much buffer was used */ spi_err = SSGETTKN( (int *)spi_buf, ZSPI_TKN_USEDLEN, (char *)&used_len ); if (spi_err != ZSPI_ERR_OK) DEBUG(); /* Send the used part to the distributor */ ccval = WRITEREAD( distr, (int *)spi_buf, used_len, ZEMS_VAL_BUFLEN ); if (ccval != CCE) DEBUG(); /* reset the buffer length to what was declared for spi_buf */ spi_err = SSPUTTKN( (int *)spi_buf, ZSPI_TKN_RESET_BUFFER, (char *)ibuflen ); if (spi_err != ZSPI_ERR
Example of Retrieving Event Messages C Source File send_spi_cmd(); } #pragma PAGE "spi_cmd_load_filter()" /* ---------- spi_cmd_load_filter -----------------* Builds an SPI command that loads a filter into the * distributor and passes one filter parameter.
Example of Retrieving Event Messages C Source File lines */ actual_len,0,0, /* actual line length */ 1); /* consolecompatible */ /* check for EMSTEXT calling errors */ if ( (high(etxt_stat) == 0) && (low(etxt_stat) != 0) ) DEBUG(); for(i=0; i < NUM_EVT_LINES; i++) { if( actual_len[i] != -1 ) { movmem(&evt_text_buf[i*EVT_TEXT_LEN], text, actual_len[i]); /* add null to conform to C convention */ text[ actual_len[i] ] = 0; printf("%s\n", text); } } } #pragma PAGE "getevent_loop()" /* ---------- getevent_loop
Example of Retrieving Event Messages C Source File send_spi_cmd(); /* Find the event message within the GETEVENT response */ tkn = ZEMS_TKN_EVENT; /* Returns the offset of the event in the */ /* spi buffer via event_buf_loc.
Example of Retrieving Event Messages C Source File zems_val_ssid.z_version = ZEMS_VAL_VERSION; cptr = strncpy(myssid.u_z_filler.z_filler, MYAP_VAL_OWNER, 8); myssid.z_number = MYAP_SSN_MYAP; myssid.
Example of Retrieving Event Messages C Source File if ( !(error == 0 || error == 70) ) { printf(" Write returned error: %d.\n",error); DEBUG(); } /* We can now close the "standard" interface to distributor */ CLOSE(distr); /* Prompt user for the cpu number */ get_cpu_num(); /* prepare to re-open the distributor spi interface */ movmem( zspi_name, distr_qual, 5 ); ccval = OPEN( (int *)distr_proc_name, (int *)&distr ); if (ccval != CCE) { printf(" Open of %s returned non-zero ccval: %d.
Example of Retrieving Event Messages Program Modifications Program Modifications This subsection suggests how you can modify this example application to demonstrate different aspects of the programmatic interface. You might need to change the example by easy stages into a practical application. Modifications—shown in TAL—can be used literally if your program is in TAL, or as a guide to program logic if your program is in TACL, COBOL, or C.
Example of Retrieving Event Messages Tracking Earlier Events FIXED time; BEGIN ! ! ! ! ! This procedure builds a command message that sets the position within the log file at which the distributor will start to retrieve event messages. The calling procedure specifies the position by the time parameter, which is in Julian-time-stamp format.
Example of Retrieving Event Messages Stopping at the End of the Logged Messages Stopping at the End of the Logged Messages In the modifications discussed so far, the distributor waits for more event messages when it has read all the messages logged so far. The distributor has an option to stop when it reaches the end of the logged messages. The application must do two things to select this option: Request the distributor to send an end-of-log-file warning. Check whether it has received the warning.
Example of Retrieving Event Messages Using PASS Values ! Read ENDLIST token to pop out of error list spi^err := EMSGETTKN(spi^buf, ZSPI^TKN^ENDLIST, , 1 ); IF spi^err <> ZSPI^ERR^OK THEN CALL DEBUG; RETURN(warning); END; Insert a call to get^warning in the getevent^loop procedure, just before the comment “Find the event message within the GETEVENT response”: ! Check for EOF warning IF get^warning THEN RETURN; You can use the techniques shown in get^warning whenever you must search an error list for a cert
Example of Retrieving Event Messages Using PASS Values Both the value zero and the decision to stop are arbitrary conventions used between filter and application.
B Example of Reporting Events This appendix presents a working example of a subsystem like one you might write. The programs in this example generate event messages when subsystem-defined events occur. This example outlines the programming structure that your subsystems will require to report events. The example demonstrates how to use EMS procedures to build event messages and how to send those messages to the collector ($0) through use of the OPEN, CLOSE, and WRITEREAD procedures.
Example of Reporting Events Testing the Program 4. Run the C test program, COBJ, entering input with pauses greater than 10 seconds and greater than 30 seconds between lines. Terminate the program by entering "quit". See below: $NSKOS KMZEMSEX 31> cobj 1stMessage 2ndMessage 3rdMessage quit $NSKOS KMZEMSEX 32> 5. Execute the following TACL statement. Adding the DEFINE, _EMS_TEMPLATES, effectively "installs" in your TACL session the TEMPNR template you created in the TEMPLI step above.
Example of Reporting Events The MAKE TACL Macro File The MAKE TACL Macro File This MAKE TACL macro file compiles the DDL and the TAL source. The ERRORFILE option is included to help you make corrections if your TAL program does not compile successfully. ?tacl MACRO #FRAME #PUSH tools #SET tools $BFS001.B9FSNJA0 == MAKE file == Event Generator DDL and TAL Compile OBEY command file == compile the DDL [tools].DDL /IN cxourddl, OUT $s.#ddl/ [tools].TEMPL /IN sourtmpl, OUT $s.
Example of Reporting Events The DDL Source File The DDL Source File These statements are in the DDL source file: !FILE xourDDL ?SECTION structs !--------------------------------------! ! Data Definitions for Token Types ! !--------------------------------------! DEF xour-ddl-too-long-stats. 02 occurrences TYPE ZSPI-DDL-UINT. 02 subsys-process-type TYPE ZSPI-DDL-ENUM. 02 ios TYPE ZSPI-DDL-INT2.
Example of Reporting Events 02 Z-NUMBER The SOURTMPL File TYPE ZSPI-DDL-INT VALUE IS xour-SSN-xour. 02 Z-VERSION TYPE ZSPI-DDL-UINT VALUE IS xour-VAL-VERSION. END * DEFINES OUR SUBSYSTEM MAXIMUM BUFFER SIZES CONSTANT xour-val-evt-buflen VALUE IS 1000. !-------------------! ! OUR Token Maps ! !-------------------! TOKEN-MAP xour-map-too-long-stats VALUE IS xour-tnm-too-long-stats DEF IS xour-ddl-too-long-stats. VERSION 1 FOR occurrences THRU subsys-process-type. VERSION 2 FOR ios.
Example of Reporting Events The C Source File 2: XOUR-TKN-IO-FILE 3: XOUR-TKN-IO-MSG 4: XOUR-TKN-IO-TIME,I10 The C Source File This file contains the C source code. The program decides an event has occurred if you take more than 10 seconds to give it data. If you take more than a half a minute, the program decides the event is critical.
Example of Reporting Events The C Source File /* * The EMS Collector name and file number when OPEN'ed */ char coll_name[] = "$ACOL"; /* Name of the collector process */ short coll_filenum; char in_msg[132]; short in_msg_len = sizeof(in_msg); /* * SS or EMS PUT of values can't be literals */ short true_val = ZSPI_VAL_TRUE; short false_val = ZSPI_VAL_FALSE; /* * PROCESS_LAUNCH_ variables */ process_launch_parms_def paramList = P_L_DEFAULT_PARMS_; zsys_ddl_smsg_proccreate_def outputList; short error, errorD
Example of Reporting Events The C Source File if (spi_error = EMSINIT( (short *)event_buf, /* Event build buffer */ XOUR_VAL_EVT_BUFLEN, /* total buffer length in bytes*/ (short *)&our_ssid, /* ssid of reporting subsystem*/ XOUR_EVT_TIME_TOO_LONG, /* event number */ XOUR_TKN_IO_FILE, /* subject token code */ file_name)) /* event subject value */ { printf("*** EMSINIT error = %d\n", spi_error); DEBUG(); } /* If more than 1/2 minute, then critical */ if (io_time > 30000000) emphasis = ZSPI_VAL_TRUE; /* Add
Example of Reporting Events The C Source File /* * Send the event. Note 0 read count */ if (WRITEREADX(coll_filenum, (char *)event_buf, size, 0)) DEBUG(); FILE_CLOSE_(coll_filenum); /* close the collector */ } /* end too_long */ #pragma PAGE "main program code" /* * This procedure represents a subsystem doing work. * It generates an event for an exceptional condition.
Example of Reporting Events The TACL Source File too_long((char *)in_fname, io_time, in_msg, strlen (in_msg), io_calls); /* .... Do subsystem processing on input .........*/ if (strcmp (in_msg, "quit") == 0) bQuit = true; /* Get next input */ start_io = end_io; } PROCESS_STOP_( (short *) &outputList.
Example of Reporting Events The TACL Source File END; ] == Define other variables #PUSH in^msg start^io end^io io^time emphasis io^calls evt^calls evt^txt ============================================================= == Build XOUR^EVT^TIME^TOO^LONG event and send it to the collector. == [#DEF too^long TEXT |BODY| == Set up XOUR^TKN^IO^FILE token value. This token is the subject == of the event number XOUR^EVT^TIME^TOO^LONG.
Example of Reporting Events The TACL Source File *** #SSPUTV error: [ems^err] ] == Add a "ZEMS^TKN^TEXT" token in the buffer. == The format is the string length followed by the actual string. == Since the first character in evt^txt is not numeric, we can use == [#CHARCOUNT evt^txt][evt^txt] for the ZEMS^TKN^TEXT token value.
C Standard Event Sample Files This appendix provides three sample files, formerly available in InfoWay, that you can copy and use on your system when creating standard events: Topic Page Event External Specification Sample File C-1 DDL Definitions Sample File C-20 EMS Templates Sample File C-30 When viewing this appendix using the NonStop Technical Library (NTL), you can select and copy the text of any of these sample files and paste it into a text editor.
Standard Event Sample Files Event External Specification Sample File entered them, that is, the TFORM commands "\SET JOIN OFF;SET JUSTIFY OFF" are specified inside the box. So use the text editor to explicitly format your text. Make sure you set the "join width" in your editor to 70 characters or less; otherwise you will get the TFORM error message "LINE WAS LONGER THAN ..." 7.
Standard Event Sample Files Event External Specification Sample File [] Brackets indicate document referenced. For example, [EMS] refers to the "EMS Manual". {} Braces indicate section in the document referenced. Braces are always preceded by the document referenced notation []. <> Document History Edition Date Version Comments -------------------------------------------------------------------1st July 1993 1.
Standard Event Sample Files Event External Specification Sample File Describe what your subsystem does, how it generates EMS events, the subsystems it depends on in the definition of its event messages, and the subsystem (or program code) it depends on in generating its events messages. Refer to Section 10, Generating Standard Events, in the EMS Manual, for a detailed list of topics to be included here.
Standard Event Sample Files Event External Specification Sample File It lists the standard management functions, as defined in Requirements for Standard Events on page 9-3, in the EMS Manual, supported by this subsystem. It describes in detail the private management functions, if any, supported by this subsystem. It lists the EMS event subjects -- in DDL names -- for all the events generated by this subsystem.
Standard Event Sample Files Event External Specification Sample File \new \level 3 "name of your mgmt func as listed in table" >> The "Event Subjects Definition Table" below lists all the objects that EMS events of this subsystem are generated for. These objects are the event subjects and they follow ZEMS-TKNSUBJECT-MARK, the subject marker, in every event message. The event subjects are listed in alphabetical order by their DDL names.
Standard Event Sample Files * * * * * Event External Specification Sample File Standard event type (ZEMS-TKN-CONTENT-STANDARD) Brief description ZEMS-VAL-ATTN-COMPLETED ZEMS-VAL-ATTN-NEEDED ZEMS-VAL-OBJECT-AVAILABLE ZEMS-VAL-OBJECT-UNAVAILABLE ZEMS-VAL-OTHER-STATE-CHANGE Operator attention completed Operator attention needed Object available Object unavailable State change other than available/unavailable Transient fault Usage threshold Brief description * ZEMS-VAL-TRANSIENT-FAULT * ZEMS-VAL-USAGE-TH
Standard Event Sample Files Event External Specification Sample File "-" event does not have a manager process heading T value meaning token not present ZEMS-TKN-CONTENTSTANDARD token USER token "S" event is a standard event non-null value null value defined in Section 9, Standard Events, in the EMS Manual "P" event is a private event null value non-null value defined by this or other subsystem "B" event was a private event non-null value non-null value and now also a standard event <
Standard Event Sample Files Event External Specification Sample File one subsystem. The tokens of a subsystem are listed, in alphabetical order of token name, under one of these headings in the table: Tokens under "Common ... tokens" heading Tokens listed under this heading are defined for all event messages of this subsystem. A token listed here does not mean that the token must always be present in an event message.
Standard Event Sample Files * * * * * * * * * * * CPU EMPHASIS EVENTNUMBER GENTIME LOGTIME NAME-MANAGER NODENUM PIN SUBJECT-MARK SUPPRESS-DISPLAY USERID Event External Specification Sample File CPU no. of event sender critical event? event number event generation time event log time manager process name system no. of event sender PIN of event sender event subject marker display event? user ID of event sender <
Standard Event Sample Files Event External Specification Sample File \level 3 "name of subsystem tokens like Standard INTERPOL Tokens" State where one find the definitions listed below \my_box_on List the common tokens List the event-specific tokens \my_box_off "??? Tokens Definition Table" The example below illustrates the description of defining INTERPOL tokens here. The "INTERPOL Tokens Definition Table" below lists all the INTERPOL defined tokens that are used by this subsystem.
Standard Event Sample Files Event External Specification Sample File Critical ZEMS-TKN-EMPHASIS (ZSPI-TYP-BOOLEAN,C) Indicator Indicates the critical nature of the condition reported in the event. Standard values are: ZSPI-VAL-TRUE ZSPI-VAL-FALSE indicates event is critical indicates event is not critical (default) An event is critical if it reports ...
Standard Event Sample Files Event External Specification Sample File each event message under the "Event Numbers Definition Table": ZEMS-TKN-NAME-MANAGER ZEMS-TKN-SUPPRESS-DISPLAY ZEMS-TKN-EMPHASIS identifies the manager process name indicates if event is to be displayed indicates if event is critical Every event message also contains one or more event-specific tokens listed under the heading "Event-specific ... tokens" of the "Description of EMS event tokens" section earlier.
Standard Event Sample Files Event External Specification Sample File A number of "templates" are provided to help you describe your events, as follows: 1) Create a new subsection to describe each of your event messages. The subsections should be ordered in alphabetical order by the symbolic event names.
Standard Event Sample Files Event External Specification Sample File <> <
Standard Event Sample Files Event External Specification Sample File ZEMS-TKN-CONTENT-USER <2> <> <> Conditional Tokens Value <> Internal Tokens Value <> Event-Message Text <
Standard Event Sample Files Event External Specification Sample File <> <> <
Standard Event Sample Files Event External Specification Sample File ZEMS-TKN-CONTENT-STANDARD ZEMS-VAL-TRANSIENT-FAULT ZEMS-TKN-CONTENT-USER <> <
Standard Event Sample Files Event External Specification Sample File <> <> <> <> The "Obsoleted Events and Tokens Table" below lists the event messages and tokens that this subsystem has obsoleted.
Standard Event Sample Files DDL Definitions Sample File DDL Definitions Sample File This file was stored in InfoWay as ddltxt.txt: !==============================================================! ! ! !This is the DDL definitions file for the fictitious ! !subsystem "SAMPLER" described in the EMS Manual in ! !Example of a Fictitious NonStop Kernel Subsystem on page 10-31. ! ! !Purpose of this file is to illustrate some commonly used ! !ways to define tokens and events in a subsystem.
Standard Event Sample Files * SAMPLER DDL Definitions Sample File T9999D99^9SEP99 (09SEP99) !*************************************************************** ! Subsystem ID (SSID) definition (ZSAM-VAL-SSID) * ! * ! ZSAM-VAL-VERSION reflects the release version of the * ! subsystem, not the version of its SPI/EMS interface. It * ! is changed whenever release version of the subsystem is * ! changed.
Standard Event Sample Files DDL Definitions Sample File ! * !*************************************************************** ! ! ! ! ! ! ! ! event subject event number range ZSAM-TKN-tp 001 - 100 ZSAM-TKN-netx25 101 - 200 ZSAM-TKN-tape 201 - 300 CONSTANT ZSAM-EVT-tp-disconnected UNAVAIL CONSTANT ZSAM-EVT-tp-connected AVAIL CONSTANT ZSAM-EVT-tp-x-conntime STATE CHANGE CONSTANT ZSAM-EVT-tp-x-resets !TRANSIENT FAULT CONSTANT ZSAM-EVT-tp-usage-data usage data description application transport connec
Standard Event Sample Files DDL Definitions Sample File data". 89 ZSAM-ENM-netx25-down 89 ZSAM-ENM-netx25-up 89 ZSAM-ENM-netx25-dataloss dataloss VALUE ZSAM-EVT-netx25-down AS "X25 net down". VALUE ZSAM-EVT-netx25-up AS "X25 net up". VALUE ZSAM-EVT-netx25AS "too much data loss for X25 net". 89 ZSAM-ENM-netx25-util-req req VALUE ZSAM-EVT-netx25-utilAS "no. requests queued for X25 net". 89 ZSAM-ENM-tape-mount-needed needed VALUE ZSAM-EVT-tape-mountAS "mount user profile tape".
Standard Event Sample Files DDL Definitions Sample File ! * ! * ZEMS-TKN-STATE-CURRENT * ! * ZEMS-TKN-STATE-PREVIOUS * ! * ZEMS-TKN-CHANGE-REASON * ! * ZEMS-TKN-TXFAULT-TYPE * ! * ! Naming convention: ZSAM-VAL-enumname * ! ZSAM-ENM-enumname for 89 enumeration * ! clause * ! Valid range: ZEMS-VAL-MIN-USER-VAL (1024) to ???? * ! for each standard token.
Standard Event Sample Files ! ! ! DDL Definitions Sample File ---------------------ZEMS-TKN-CHANGE-REASON ---------------------- CONSTANT CONSTANT CONSTANT ZSAM-VAL-cr-tp-applreq ZSAM-VAL-cr-tp-xconntime ZSAM-VAL-cr-netx25-online VALUE IS 1024. VALUE IS 1025. VALUE IS 1027. DEFINITION ZSAM-DDL-CHANGEREASON-ENUM TYPE ENUM TACL ENUM !*do not specify the "AS clause" BEGIN. 89 ZSAM-ENM-cr-tp-applreq VALUE ZSAM-VAL-cr-tp-applreq AS "requested by local appln".
Standard Event Sample Files ! ! DDL Definitions Sample File Provide "89 enumeration clause" if token has "89" (see above) !*************************************************************** ! Private enumerations of this subsystem's tokens * ! * ! Naming convention: ZSAM-VAL-enumname * ! ZSAM-ENM-enumname for 89 enumeration * ! clause * !*************************************************************** CONSTANT CONSTANT CONSTANT CONSTANT ZSAM-VAL-appl-remote-rej ZSAM-VAL-net-unavail ZSAM-VAL-tp-remote-rej Z
Standard Event Sample Files CONSTANT CONSTANT CONSTANT CONSTANT ! ! ! DDL Definitions Sample File ZSAM-TNM-tp-diagcode ZSAM-TNM-data-usage ZSAM-TNM-netx25-error ZSAM-TNM-pdnx25-error VALUE VALUE VALUE VALUE IS IS IS IS 4. 5. 6. 7. -------------------------------Common DDL structure definitions -------------------------------- DEFINITION ZSAM-DDL-tp-diagcode-ENUM TYPE ENUM TACL ENUM !*do not specify the "AS clause" BEGIN.
Standard Event Sample Files DDL Definitions Sample File TOKEN-TYPE ZSAM-TYP-tp-diagcode VALUE IS ZSPI-TDT-ENUM DEFINITION IS ZSAM-DDL-tp-diagcode-ENUM. TOKEN-TYPE ZSAM-TYP-data-usage VALUE IS ZSPI-TDT-STRUCT DEFINITION IS ZSAM-DDL-data-usage.
Standard Event Sample Files ! netx25-error net ! ! (ZSAM-MAP-) ! ! netx25-info X.25 PDN TOKEN-CODE DDL Definitions Sample File int error (File Sys) returned from Xstruct error information returned by ZSAM-TKN-tp-diagcode VALUE IS ZSAM-TNM-tp-diagcode TOKEN-TYPE ZSAM-TYP-tp-diagcode !allow "89" DEF's SSID HEADING ZSAM-VAL-EXTERNAL-SSID "appl transport disconnect diagnostic code".
Standard Event Sample Files EMS Templates Sample File EMS Templates Sample File This file was stored in InfoWay as templat.txt: **************************************************************** == This is the sample EMS Templates file for the fictitious == == subsystem "SAMPLER" described in the EMS Manual in Example of a Fictitious NonStop Kernel Subsystem on page 10-31.
Standard Event Sample Files EMS Templates Sample File ================================================================ == if you have defined your private enumerations to a token from == another subsystem, assign them here (see above) == (none in this example) ================================================================ == Templates for subsystem standard events == ================================================================ == == == == == == == == == == == == == == == == == == == == == The follo
Standard Event Sample Files EMS Templates Sample File 33:ZSPI-TKN-NEXTTOKEN, TOKENVALUE MSG: ZEMS-TKN-EVENTNUMBER, ZSAM-EVT-netx25-down == changed "Object unavailable <31><32> - <31><33>" ", event number: <1>" ", cause: <2>" "<*IF 24>, underlying object: <14><*ENDIF>" "<*IF 21>, manager: <11><*ENDIF>" "<*IF 22>, batch ID: <12><*ENDIF>" "<*IF 23>, user content: <13><*ENDIF>" "<*IF 25>, net svc err: <15><*ENDIF>" == added "<*IF 26>" == added ", PDN-level: <16>" == added ", PDN-err: <17>" == added ", PDN-di
Standard Event Sample Files EMS Templates Sample File ", event number: <1>" ", # minutes conn time: <2>" ", # bytes sent: <3>" ", # bytes recv: <4>" ", # pkts sent: <5>" ", # pkts recv: <6>" "<*IF 21>, manager: <11><*ENDIF>" "<*IF 22>, batch ID: <12><*ENDIF>" 1:ZEMS-TKN-EVENTNUMBER, ENUM 2:ZSAM-TKN-DATA-USAGE.ZSAM-DDL-DATA-USAGE.time-connect 3:ZSAM-TKN-DATA-USAGE.ZSAM-DDL-DATA-USAGE.bytes-send 4:ZSAM-TKN-DATA-USAGE.ZSAM-DDL-DATA-USAGE.bytes-recv 5:ZSAM-TKN-DATA-USAGE.ZSAM-DDL-DATA-USAGE.
Standard Event Sample Files EMS Templates Sample File EMS Manual—426909-005 C-34
D EMS Usage Best Practices and Recommendations Introduction EMS (Event Management System) is a key component in the management of HP NonStop Systems. It is used by HP NonStop subsystems to create, manage, and display events that are used in the management of the software and hardware components of NonStop Systems. It is also used by third parties and customers in the management of their software and hardware components.
EMS Usage Best Practices and Recommendations Event Content Guidelines System configuration changes; e.g., path switches, takeovers, capacity changes, threshold changes. Threshold crossings; e.g., usage of a resource crossed a 70% threshold, capacity of a device exceeded 1000 transfers per second. Other conditions that could affect the stability or performance of your system; e.g.
EMS Usage Best Practices and Recommendations Event Destination Guidelines Event Destination Guidelines There are two primary event destinations: your EMS Collector and $0. The following guidelines should be used in deciding where the events should be reported: EMS-DST-101: Events should never to logged to $ZLOG (the OSM Collector). This collector is reserved for events from NonStop subsystems. EMS-DST-111: In general, avoid using $0 (the Primary Collector). Most HP System events go into that log.
EMS Usage Best Practices and Recommendations Event Emphasis Guidelines EMS-SEV-111: ZEMS-TKN-ISO-SEVERITY should be used according to the following guidelines: Token value ZEMS-VAL-SEVERITY-CRITICAL ZEMS-VAL-SEVERITY-MAJOR ZEMS-VAL-SEVERITY-MINOR ZEMS-VAL-SEVERITY-WARNING ZEMS-VAL-SEVERITY-CLEARED When to use Critical condition that indicates a service affecting condition has occurred, requiring an immediate corrective action (e.g.
EMS Usage Best Practices and Recommendations Event Frequency Guidelines Event Frequency Guidelines EMS-FRQ-101: Events should not be repeated if the same problem persists or the same condition exists. See EMS-CON-121.
EMS Usage Best Practices and Recommendations EMS Manual—426909-005 D-6 Event Sustaining Guidelines
Index Numbers 89 enumeration clause 10-22 A A 12-5 Action events 2-4, 8-3 Action tokens 8-9 ALLOCATE keyword EMSACOLL 13-6 EMSCCTRL 13-10 ALLPROCESSORS section of SYSGEN 12-22 Alternate collector 2-7 See also EMSACOLL BACKUP 12-6 configuring 12-2 context 12-24 DEFAULTSUBVOL 12-7 definition of 1-2 log files 12-4 POOLPAGES 12-8 REPLYAFTERWRITE 12-9 Application interface to EMS 8-12 Applications of EMS 1-8 AS clause 10-22 Assignments, filter language 5-30 AUTOSTOP keyword, EMSDIST 13-39 B BACKUP keyword EMSA
detecting and suppressing event bursts 6-8 directives 6-9 example of 6-11 function of 6-7 used for BDS 6-7 used with PLF 2-8 C CDIST option of SWITCH keyword, EMSCCTRL 13-16 CDISTMODE keyword of EMSCCTRL 13-10 CDISTSTOP keyword of EMSCCTRL 13-11 CDISTSTOP keyword, EMSCCTRL 12-14 CDISTUSER keyword, EMSCCTRL 13-11 Changing the distributor environment 4-4 Clock reset 20-31 CLOSE procedure 15-3 Closing collector 8-14 COBOL85 15-3 Collector alternate 2-7 closing 8-14 commands 19-1/19-61 common ZSPI-TKN-RETCODE
ZEMS-CMD-REPLACE, distributor 17-29 ZEMS-CMD-STATUS, collector 19-53 ZEMS-CMD-STATUS, distributor 17-41 ZEMS-CMD-STOP, collector 19-60 Comments, filter language 5-9 Common definitions ZCOM- commands collector 19-4 distributor 17-5 ZEMS- commands collector 19-27 distributor 17-9 Compatibility distributor characteristics 2-11 default mode 12-15, 12-22 defined 2-9 EMSTEXT and 2-14 mode changing 12-22 default 12-15, 12-22 selecting 12-22 object file 12-22 primary process of, switching 12-14 purpose of 2-10 reas
Data definition file (DDL), creating 8-11 Declarations, filter language 5-26 DEFAULTSUBVOL attribute 12-7 Definition files 2-14 Definitions, EMS 14-1 DELAY keyword, EMSDIST 13-39 DESTINATION statement, filter language 5-33 Directives burst filters 6-9 filter table 6-3 DISCACCESSID attribute 12-7 DISCARDEVENT statement, filter language 5-35 Display format EMSTEXT and 2-12, 15-19 event-message headers in 15-19, 15-22 Display text buffer 15-20 generating 2-12, 4-18, 15-19 Displaying event messages 3-2 Distribu
sending a command 15-6 sending an event 15-4 overview of 2-15 passing tokens by reference or value 15-2 summary of 15-2 programs 13-1/13-51 system environment of 1-2 EMS filter 5-3 EMSACOLL RUN command 13-2 run-time parameters ALLOCATE 13-6 BACKUP 13-4 BUFFERED 13-5 CPU 13-2 DEFAULTSUBVOL 13-4 EXT 13-5 FILTER 13-3 LOGPREFIX 13-4 LOGSUBVOL 13-4 MAXFILE 13-5 NAME 13-2 NOWAIT 13-2 POOLPAGES 13-6 PRI 13-2 REFRESH 13-5 REPLYAFTERWRITE 13-6 ROTATEFILES 13-4 SECURITY 13-5 SUPPRESS 13-3 startup error messages 13-6
FILTER 13-36 FORWARDING 13-35 GMT ON 13-40 INDENT 13-40 LOGFILE 13-36 PRINTING 13-35 SBUF 13-39 STOP 13-38 TARGET 13-36 TEXTOUT 13-36 TIME 13-37 TYPE 13-35 WAIT 13-37 EMSDIST program 13-34 EMSFLAGS parameter 12-22 EMSINIT procedure 15-17 EMSINITMAP procedure 15-17 EMSTEXT procedure command 15-19 error messages 2-13 introduced 2-12 numbered console messages and 15-22 using 4-18 EMSTEXTMATCH function, filter language 5-39 EMSTEXTV command 15-19 EOFREFRESH attribute 12-7 Error codes, distributor 21-6 Error lis
BAD-FILTER 21-16 COLLECTOR-EXISTS 21-11 COLL-ACCESS 21-9 COLL-DISCONNECT 21-19 COLL-NOT-FOUND 21-12 COLL-PROTOCOL 21-17 CONTEXT 21-15 DEST-ACCESS 21-14 DEST-CONFLICT 21-21 DEST-EXISTS 21-14 DEST-NOT-FOUND 21-15 DEVTYPE 21-17 DIST-ALLOC 21-21 DUP-TKN 21-7 EOF 21-13 FLT-ALLOC 21-20 FLT-FORM 21-9 FORWARD-SEARCH 21-13 HIST-MODE 21-11 INV-CMD 21-6 INV-HEADERTYPE 21-9 INV-OBJECT 21-8 INV-OP 21-8 INV-PROFILE 21-21 INV-SSID 21-6 INV-TKN 21-7 INV-VALUE 21-7 LOG-ACCESS 21-12 MAX-COLLECTOR 21-11 MAX-DEST 21-13 MODE-CO
ACOL-SHUTDOWN 20-36 ACOL-TAKEOVER 20-42 BURST-END 20-60 BURST-START 20-57 COLD-LOAD 20-9 COLL-DISC-FAILED 20-14 COL-EVENT-DISCARDS 20-18 COMPAT-DISTR-STOPPED 20-16 FILESWITCH 20-11 FILE-ROTATE-PURGE 20-22 INVALIDEVENT 20-33 LOGGING-STOPPED 20-24 LOGTIME-DECREASE 20-30 MSGR-EVENTSDISCARDED 20-20 PLF-ERROR 20-63, 20-65, 20-67, 20-69, 20-71 WRITE-TO-0 20-7 Event messages, distributor 18-1/18-57 ZEMS-EVTBACKUP-ABENDED 18-39 BACKUP-CREATED 18-37 BACKUP-DELETED 18-41 BAD-EVENT 18-25 BAD-FILTER 18-21 BAD-LOG 18-44
Fields, filter language 5-14 Files compatibility-distributor object 12-22 CONFAUX 12-21, 12-22 configuration 12-21, 12-22 definition 2-14 SYSGEN auxiliary 12-22 template 12-23 installed at SYSGEN 2-12 Filter collector, purpose of 2-11 creating 3-3, 5-3 distributor, purpose of 2-11 EMS 5-3 installing 17-20 loading and replacing a 4-4 multiple filters 6-6, 16-2 operating environment 5-1 sample specification 5-3 specification, compiling for 5-4 types of 2-11 writing compatibility 5-6 correctness 5-7 efficiency
IF statement 5-36 integers 5-16 LITERALLY function 5-41 MATCH function 5-42 names in 5-10 NULL subsystem ID 5-12 PASS statement 5-36 precedence of operators in 5-26 reserved words in 5-9 SSID function 5-42 statements 5-30 strings 5-16 subsystem IDs 5-16 subsystem ID, NULL 5-12 TACL environment of 5-8 TOKENPRESENT function 5-43 tokens, references to qualified 5-12 unqualified 5-11 Filter parameters filter language and 5-29 passing and replacing 4-4, 17-21 Filter tables 6-1 defined 2-12 directives 6-3 errors
Log files alternate collector 12-4 configuring 12-3, 12-5 management 2-8 operation of 12-23 positioning the distributor 4-10 positioning, effect of clock reset on 20-31 primary collector 12-3 switching 12-28 LOGFILE keyword, EMSDIST 13-36 Logical connection AND filter tables 6-7 LOGPREFIX keyword, EMSACOLL 13-4 LOGSUBVOL keyword, EMSCCTRL 13-13 Logtime token 4-10 LOGUSERID keyword, EMSCCTRL 13-13 M Manager token 8-9 MATCH function, filter language 5-42 MAXFILE attribute 12-7 keyword, EMSCCTRL 13-13 Multipl
definition of 2-9 EMSTEXT and 2-14 PRINTING keyword, EMSDIST 13-35 Procedures, EMS declarations required for 15-7 definitions required for 15-7 summary of 15-2 Programs collector EMSACOLL process 13-2 EMSCCTRL control utility 13-9 EMSCINFO status utility 13-18 distributor EMSDINFO status utility 13-29 EMSDIST process 13-34 utility, overview of 2-15 PROTECTION attribute 12-9 PUP commands 12-15 subsystem ID and 8-7 terminology 14-1 tokens required for 8-6 Reserved words in filter language 5-9 Resetting syste
from an alternate collector 7-8 implementation methods 7-7 Specify 10-23 SPI commands, sending 19-2 SSID function, filter language 5-42 Standard definitions, loading 5-4 Standard EMS templates 9-34 Standard event procedure calls condition code settings EMS_OBJ_AVAIL_EVT_BLD_ 11-1 6 EMS_OBJ_UNAVAIL_EVT_BLD_ 11-11 EMS_OPER_ATTN_COMPED_EV T_BLD_ 11-30 EMS_OPER_ATTN_NEEDED_EVT _BLD_ 11-26 EMS_OTHER_STATE_CHANGE_E VT_BLD_ 11-21 EMS_TRANSIENT_FAULT_EVT_B LD_ 11-5 considerations EMS_OBJ_AVAIL_EVT_BLD_ 11-1 6 EMS_O
event messages, describing 10-20 event number definitions, ZEMS-TKNEVENTNUMBER 10-23 event numbers 9-12 and CDMT attributes 10-19 event subject DDL names 10-19 event subject definitions 10-24 event template object available 9-34 object other state change 9-35 object unavailable 9-35 operator attention completed 9-36 operator attention needed 9-36 transient fault 9-37 usage threshold 9-37 event tokens object available 9-25 object other state change 9-26 object unavailable 9-26 operator attention completed 9-
private tokens 10-20, 10-24, 10-36 private values, enumerate to standard tokens 10-20 proactive problem management functions 9-8 problems bypass and recovery 10-12 data for resolving 10-13 detection and isolation 10-12 diagnosing 10-12 identifying causes 9-6 rediscovery 9-7 tracing and control 10-13 procedure calls for generating events 11-1 introduction to 11-2 procedures cause, effect, and recovery 10-16 EMS_COMMON_TOKENS_EVT_B LD_ 11-44 EMS_OBJ_AVAIL_EVT_BLD_ 11-1 3 EMS_OBJ_UNAVAIL_EVT_BLD_ 11-7 EMS_OPER
tokens conditional and unconditional 10-16 internal 10-16 nature of 10-25 of other subsystems, private enumerations 10-24 of your subsystem, private enumerations 10-24 transient faults 9-8 transition faults, subsystem detection of 10-9 unconditional tokens 9-17 usage threshold programming example 11-41 ZEMS-TKN-CONTENT-USER, private event type definitions 10-23 ZEMS-TKN-EVENTNUMBER, event number definitions 10-23 Standard events usage threshold event condition code settings EMS_COMMON_TOKENS_EVT_B LD_ 11-47
Text display from event messages 2-12, 15-19 Text formats console-compatible and EMSTEXT 2-12, 15-19 display format and EMSTEXT 2-12, 15-19 DSM display format and EMSTEXT 2-12, 15-19 Text token 2-13 TEXTOUT keyword EMSCCTRL 13-16 EMSDIST 13-36 Text-formatting procedure 2-12, 15-19 The 12-20, 13-19 The MAKE TACL Macro File B-3 This 5-44 TIME keyword, EMSDIST 13-37 Time-positioning in log files effect of clock reset on 20-31 with ZEMS-TKN-GMTTIME 4-10 with ZEMS-TKN-LOGTIME 4-10 Token definitions, event-messag
OBJ-NOT-FOUND 22-5 SECUR-VIOL 22-6 SPI-ERROR 22-6 SSID-INV 22-6 SUB-NOT-FOUND 22-7 TKN-CODE-INV 22-7 TKN-DUP 22-7 TKN-LEN-INV 22-8 TKN-REQ 22-8 TKN-VAL-INVAL 22-8 VSN-INCOMP 22-9 ZEMS-CMD-CONTROL command collector 19-34 distributor 17-17 ZEMS-CMD-GETEVENT command, distributor 17-25 ZEMS-CMD-GETVERSION command collector 19-45 distributor 17-28 ZEMS-CMD-REPLACE command, distributor 17-29 ZEMS-CMD-STATUS command collector 19-53 distributor 17-41 ZEMS-CMD-STOP command, collector 19-60 ZEMS-DDLCOL-CDIST-STATUS 1
LOG-ACCESS 21-12, 22-24 MAX-COLLECTOR 21-11 MAX-DEST 21-13 MODE-CONFLICT 21-8 NO-BACKUP 22-27 NO-EVENT-SOURCE 21-16 NO-POOL 21-16 OPEN-LOG 22-15, 22-25 REQ-PARAM 21-10 REQ-TKN 21-8, 22-24 STARTUP-FAILED 21-22 STAT-ONLY 21-20 VERSION 21-6, 22-20 WRITE-FAILED 21-22 ZOPR-SYNC 22-18 ZSPI 21-15, 22-26 ZEMS-EVTACOL-ALLOCATE-ERR 20-38 ACOL-BACKUP-ABENDED 20-47 ACOL-BACKUP-DELETED 20-49 ACOL-CHECKOPEN-FAILED 20-40 ACOL-CHECKPOINT-ERR 20-50 ACOL-CREATEBACKUP-ERR 20-44 ACOL-EVENT-DISCARDS 20-28 ACOL-INTERNAL-ERR 20-3
BDS-STATS 19-14 BURST-STATUS 19-15 COL-CDIST-INFO 19-24 COL-CDIST-STATUS 19-54, 19-58 ZCOL-CDISTBKUPCPU field 19-54 ZCOL-CDISTPRICPU field 19-54 ZCOL-CDIST-DEF-TEXTOUT field 19-54 ZCOL-CDIST-MODE field 19-54 ZCOL-CDIST-TEXTOUT field 19-54 ZCOL-CDIST-USER field 19-54 ZCOL-DISTR-ERROR field 19-54 ZCOL-OPRLOG-ERROR field 19-54 ZCOL-STOPCOMPATDIST field 19-54 COL-CONTROL 19-17, 19-34, 19-36, 19-38 ZCOL-DISCACCESSID field 19-37 ZCOL-EOFREFRESH field 19-37 ZCOL-EVENTBLOCKING field 19-38 ZCOL-LOGSUBFILE field 19-3
ZCOL-ROTATEFILES field 19-54 ZCOL-SECONDARYEXTENT field 19-54 ZCOL-WRITETHRUCACHE field 19-54 DIST-STATUS 17-34 See also ZEMS-MAP-STATUSDIST DIST-TARGET 17-35 See also ZEMS-MAP-STATUSTARGET EXIOADDR 14-10, 20-6 PLF-STATS 19-15 STATUS-FILTER 19-25 STATUS-SOURCE 17-38 STATUS-TARGET 17-40 ZDIST-TARGET-EVENTS-PERBLOCK field 17-35 ZDIST-TARGET-NAME field 17-35 ZDIST-TARGET-STATE field 17-35 STATUS-TEXTOUT 17-39 ZEMS-TKNACOL-EVENTS-DISCARDS 20-29 ACTION-ID 14-9, 20-13, 20-25 ACTION-NEEDED 14-9, 20-13, 20-25 ADD-T
MESSENGERCPU 20-21 MSGR-EVENTS-DISCARDED 20-21 NEWLOGFILE 18-5, 18-48, 20-12 NEWPROCESS-CPU 18-5, 18-38, 20-45, 20-47 NEWPROCESS-ERROR 18-5, 20-45, 20-46 NEWPROCESS-PRIORITY 18-6, 18-38, 20-45, 20-47 NEW-LOGTIME 20-31 NODENUM 14-4 OLD-LOGTIME 20-31 OPMSG 14-10, 20-19 PASSVAL 17-26 PIN 14-4 PREG 20-36 PROC-DESC 14-4 PROGRAMFILE 18-6, 18-30, 18-35, 18-38 PURGEDLOGFILE 20-23 RECORD-ADDRESS 18-6, 21-4 RECOVERY-ENUM 18-6, 18-47 REPLACE-PARAM 17-18 REPLACE-TGT-COLL 17-18 RESET-FILTER 17-18 SENDERID 14-8, 15-15 SE
TGT-IDLE 17-40 TGT-RETRY 17-40 TGT-WRITE-PENDING 17-40 TXT-IDLE 17-40 TXT-PRINTING 17-40 TXT-WAIT-ERROR 17-40 TXT-WAIT-TIMEDOUT 17-40 VERSION-INCOMPATIBLE 21-3, 21-17 ZFILOPEN 18-14, 18-16, 18-18, 18-22, 21-9, 21-10, 21-12, 21-14, 22-13 ZFILPOSITION 18-14, 18-22, 21-12 ZFILREAD 18-14, 18-22, 21-10, 21-12 ZFILWRITE 18-18, 21-14 ZFILWRITEREAD 18-16, 21-9, 22-13 ZEMS-WRNEOF 21-4 TOO-EARLY 21-4 TOO-LATE 21-5 ZEM-MAP-STATUS-SOURCE 17-34 ZSPI-TKNCOMMAND 17-9, 19-27 CONTEXT 4-12, 17-25, 17-26, 21-1 ERROR 22-2, 22-
EMS Manual—426909-005 Index-24
