NetView for z/OS V6.1 - Introducing the Canzlog Introduction - IBM

NetView for z/OS V6.1 - Introducing the Canzlog
Introduction
Tivoli NetView for z/OS V6.1 is generally available as of late May, 2011. Many customers are already
excited about learning more about the new version.
NetView V6.1 includes, among many other things, the introduction of an important new feature, the
Consolidated Audit, NetView, and z/OS Log - Canzlog. The purposes of this paper are to describe the
many benefits of Canzlog, and to provide some details about getting started with it and using it. Before
diving in, please note that this paper is intended to supplement other sources of information on Canzlog,
such as the product documentation, online help, and other sources. There are links to additional
information at the end of this paper.
Overview
This section summarizes Canzlog and its benefits. Subsequent sections go into further details.
NetView's Canzlog capability simultaneously gives you access to all the system's message traffic AND,
thru robust filtering, to "private" subsets of the messages. Canzlog gives the user the power to view and
scan quickly while also having complete details of any given message.
The active Canzlog is a data-space set up by a NetView Subsystem Interface (z/OS SSI) "INITRTN". It
begins recording messages early in z/OS initialization, and can hold around 9 million messages, after
which it wraps. Aging messages in the active log are automatically archived. Users can browse the
Canzlog seamlessly, not needing to distinguish between active and archived data.
The capture of system messages for automation and Canzlog has been streamlined for better performance
and simpler definition. Automation specifications in CNMSTYLE are simpler, independent, and dynamic
(subject to RESTYLE), resulting in easier installation and improved time-to-value. Parameters for the start
of NetView's "SSI procedure" are greatly reduced and are independent of those in CNMSTYLE. Most
automation definitions, for example message automation and revision tables, remain as they were, and
migration was carefully considered for the others.
Canzlog enables enhanced logging and browsing of NetView and z/OS (including JES and sub-system)
messages, including a wide variety of message attributes. Among these attributes are designations for
command echoes, delete operator messages (DOMs), audit messages, trace messages and NetView
messages. Canzlog is designed to aid audit and debug activities.
Filters may be organized using logical combinations of these attributes (for example, the job name starts
with ABC and the text contains TOM or XYZ). Several filters are shipped with NetView. Customers can
make more, and can save, display, and manage powerful sets of filters.
Browsing is done via 3270. The Browse screen is shown just below. Graphics are not yet supported, but
presentation attributes such as color and reverse video are preserved. A given browse session starts with a
new or pre-defined filter and shows the most recent messages matching the filter. The ALL and FIND
commands can apply more filtering to narrow the focus. Each message can be expanded to show all its

attributes. In Canzlog, the full, un-truncated text is available to the operator and multi-line messages are
kept together.
For some customers, full exploitation of Canzlog will require additional people to be able to log in to
NetView. For this reason, a default logon profile is supported in NetView V6.1, enabling you to allow new
operators and define their authorization with a minimum of definition.
A REXX-pipe application programming interface (API) provides program access to Canzlog data. Full
filtering capability, just as for a browse session, is available, after which exact replica messages can be
obtained in a NetView pipe.
Archive files may be imported for use with a local browser. We anticipate this will be of great assistance to
IBM Service, but it's likely that customers will come up with usages for this as well, for example importing
or restoring archived message data.
Note that the existing network log and BROWSE NETLOGx commands remain fully supported in V6.1.
Canzlog provides much more capability, but both will exist for some period of time. At some point,
you will decide that Canzlog meets all your needs; then issue "STOP TASK=DSILOG" for improved
performance.
The following sections go into additional details about the points made above.
Installation and Automation
The active Canzlog data-space is established during z/OS initialization. This requires a NetView INITRTN
called DSI4LSIT, which is defined to z/OS as follows:
2

SUBSYS SUBNAME(XXXX) INITRTN(DSI4LSIT)
Note that this is an important change to NetView's SSI definitions in member IEFSSNxx. Such entries
have long been required, but there was no INITRTN parameter. The INITRTN is now required for
NetView V6.1 SSI entries; omission of this value is very serious.
An optional INITPARM on this statement controls Canzlog action for "foreign" messages, forwarded by
z/OS across the sysplex for various reasons. By default, these foreign messages are not entered into the
Canzlog data. You can code "LOGFORN" as an INITPARM to enable logging of foreign messages. This
option is independent of the "DoForeignFrom" parameter of the Message Revision Table. Example
SUBSYS statement with the LOGFORN option:
SUBSYS SUBNAME(XXXX) INITRTN(DSI4LSIT) INITPARM(LOGFORN)
Note that you can further control logging of both foreign and local messages from the MRT.
If you define multiple NetViews on a given z/OS, each requires its own unique SUBNAME. This
requirement existed previously, but is stronger in V6.1 to avoid confusion about which NetView is
archiving the Canzlog.
NetView's SSIs no longer require a started procedure. NetView's "SSI proc" continues to exist, and is still
shipped as sample CNMPSSI (before copy: CNMSJ010). However, this procedure no longer controls
whether messages flow to NetView's home address space (in particular, to task CNMCSSIR). This
procedure is still required for Message Revision, Command Revision, and the Program-to-Program-
Interface (PPI), as in past releases. This procedure is still paired with a "home NetView", and the first 4
characters of the procedure name must match that NetView's SSI name (see SUBNAME above).
In addition to the IEFSSNxx member(s), you should review your NetView SSI started procedure
referenced just above. In V6.1, sample CNMPSSI (CNMSJ010) now includes the following lines in the
JCL:
// MBUF='RETIRED', ** (Retired) message buffers
// CBUF='RETIRED', ** (Retired) command buffers
// DSIG='RETIRED', ** (Retired) command designator
//* See MVSPARM.CMD.DESIGNATOR in CNMSTYLE for command designator info
// MSGIFAC='RETIRED', ** (Retired) message interface setting
// PPIOPT='PPI', ** PPI OPTIONS SWITCH
...
// PFXREG='RETIRED', ** Prefix Registration option.
All of the above retired parameters are tolerated to ease migration, but are not processed. The first two
actually expose a potential performance bottleneck that existed before V6.1, and is now removed. The
command designator (DSIG) now needs only to be defined on the "home NetView" side, in CNMSTYLE,
rather than in two places. The prefix registration is now done automatically without specification. Perhaps
best of all, MSGIFAC, previously defined both here and in CNMSTYLE, is retired. This parameter has
caused concerns in the past for NetView and Systems Automation for z/OS (z/SA) customers.
The following parameters are added to CNMSTYLE in NetView V6.1:
MVSPARM.Msg.Automation = Yes
MVSPARM.Msg.Automation.MaxAge = 0
MVSPARM.Msg.Automation.Oldtag = *NONE*
MVSPARM.Cmd.Designator = %
MVSPARM.Cmd.Scope = 1
3

The above parameters specify:
- whether messages from MVS will be imported for automation (Msg.Automation)
- disposition of MVS messages that were marked "automate" the specified number of seconds prior to
NetView or the subsystem router task (CNMCSSIR) becoming active (Msg.Automation.Maxage)
- whether NetView will overlay the last (eighth) character of the autotoken field with the character
specified by Msg.Automation.Oldtag when MVS messages are queued for later automation due to NetView
or the subsystem router task (CNMCSSIR) being inactive. Note that NetView inserts the value only in the
copy of the message made for message automation.
- how commands from a z/OS system console can be directed to NetView (Cmd.Designator)
- The SCOPE of the command designator is either a numeral one (1) or an asterisk (*). The 1 means local
system only and the * means the designator is for the sysplex. The default is 1.
In addition there are a number of parameters added to CNMSTYLE that begin with "ARCHIVE.". Some
of them are as follows:
ARCHIVE.HLQ = high_level_qualifier
ARCHIVE.WRITE = Yes
ARCHIVE.BROWSE.DATASPACES = nn
ARCHIVE.HLQ provides a high level qualifier for data sets that do or will contain Canzlog archive data.
Defining a high level qualifier enables an instance of NetView to at least browse archived data. The HLQ
may be from 1 and 26 characters and must conform to MVS data-set naming conventions. More comments
are provided in the sample CNMSTYLE, but it is intended that each NetView provide an HLQ to enable
reading, or reading and writing, the Canzlog archive.
ARCHIVE.WRITE simply indicates whether this NetView is writing archive files. Note the shipped
default value of Yes, which indicates that the first NetView to become active on this z/OS image will write
the archive files. It is important that one such NetView does this. Otherwise messages in the active
Canzlog can be lost when "wrapped out" (or z/OS comes down), and usability can suffer while browsing
older messages. Subsequent NetViews will detect that archiving is active, and will assume an "archiving
back-up" position if their own style has ARCHIVE.WRITE = Yes.
Note that the instance of NetView doing archiving be shut down normally (not canceled or by CLOSE
ABEND) prior to a planned IPL.
ARCHIVE.BROWSE.DATASPACES specifies the number of data spaces that NetView will allocate and
use for browsing archived Canzlog data. The value is a numeric from 1 to 10, and defaults to 1. Use a
higher number if you anticipate simultaneous usage of large numbers of archived message files. This
would normally involve multiple users, but keep in mind that a single user doing searches or using severe
filters across long time periods can potentially access many such files. This statement, unlike others in the
"ARCHIVE" family cannot be changed by the RESTYLE command.
There are a number of other ARCHIVE statements that define, for the archiving NetView, how to write
these data-sets. These parameters are fully described in the sample CNMSTYLE and relate to how datasets
are managed at your installation.
NetView provides the ability to set SMS characteristics of the data files. Setting data class, storage class,
and/or management class can assist you in supervising the large number of data files (8 megabytes
each). NetView also stores index files, which you will need to identify and never delete or alter. The
CNMSTYLE member, the Administration Reference, and the trouble shooting guide, all describe
4

these files' naming conventions. After the (single) master index, each file's name will include a time stamp.
Be sure to note that the time stamp (year, month, day, hour, minute, and second) described for the naming
convention is in Standard Time (no allowance for time zone or daylight savings).
When not controlled by SMS storage class, management class, or data class, other parameters of file
allocation can be specified in CNMSTYLE. These include separate specification of volume serial for data
and index files, the unit name, block size, and space allocation. More information is provided in the section
“Files Used in Canzlog Archiving” later in this paper.
Note that MVSPARM and ARCHIVE parameters can be refreshed in V6.1 without restarting NetView, via
the RESTYLE command.
The following CNMSTYLE statements are retired for V6.1:
MVSPARM.MSGIFAC, SSIname and SSI.DSIG.
If MVSPARM.MSGIFAC is specified in another product's style members, you can override that with the
value *NONE*. Specification of any other value will induce a warning message.
Automation definitions not mentioned above, such as MRT and auto-table, and related commands to
activate or change those tables, remain as they were in previous releases. A few more message attributes
are available to automation (message revision tables, automation tables and related command procedures).
Examples are WTOKEY and CHKEY. These are all detailed in a subsequent section in this paper called
"Edit Orders".
A few notes follow that may help test installation or help debug. The first message in the active Canzlog
may be "CNM617I NetView subsystem XXXX initialized successfully", not long before "IEE252I
MEMBER IEFSSNxx FOUND IN SYS1.PARMLIB". Examine that area in the Canzlog or system log for
errors, for example "DSI4LSIT not found", which would indicate an installation problem. Module
DSI4LSIT should be found in LPA.
NetView's home address space initialization should include the message "DWO854I Canzlog is active.".
Otherwise look through NetView initialization messages for errors, and consult NetView message
help where needed.
IBM's z/SA product is a heavy user of NetView automation facilities. z/SA has some doc changes for
"when running with NetView V6...", for example removing MSGIFAC refs. SA has one code change we're
aware of for running on NetView V6.1, APAR OA35900.
A final note about installation: For V6.1, NetView's SSIs support the SETSSI DEACT command. This
should never be necessary, but would allow, in an emergency, the ability to re-start back-level NetView
procedures without IPL.
Logging, Attributes and Defining Filters
Logging messages to Canzlog is done in two places. One is NetView's SSI exit, set up by the
aforementioned INITRTN, DSI4LSIT. The other is NetView's home address space. Each "home"
NetView in an LPAR separately logs its own messages in the active Canzlog.
With a few exceptions, messages logged in the SSI are tagged "MVS", and messages logged by "home
NetView" are tagged "NV". Exceptions, from either source, are Delete Operator Messages (DOMs), which
5

are logged somewhat like messages but are considerably different, as well as audit messages and trace
messages. More on these exception cases below.
Both sources log "command echoes", a special message indicating command text, as designated either in
the z/OS WQE or the NetView IFR. These are tagged "CmdEcho" and generally also tagged MVS, NV or
Audit. Audit messages are command echos that have not yet had a chance to be altered, for example by
NetView Command Revision. This definition may expand over time. Trace messages are internally
generated command echoes or other messages specifically designated as debugging type messages. In
NetView V6.1 all timer commands are echoed as trace messages regardless of source. This means that AT,
EVERY, AFTER, CHRON, and PURGE commands are recorded even when issued from REXX/CLIST.
Other message tags include Broadcast, Deleted, and DOM-expected. In addition to tags, messages in
Canzlog have "flags". Some examples of flags are: AMRF does not retain, issuer was authorized,
NetView authorized receiver message, exposed to message revision, etc. For a complete list of tags and
flags, enter HELP DISPMSG in NetView or reference DISPMSG in the NetView Command Reference.
One difference between tags and flags is that tags may be filtered on. More on filters in a moment.
In addition to tags and flags, Canzlog associates many other attributes with messages. Among these are:
date and time (including milliseconds)
message text
address space ID
address space (job) type
SAF/ACEE group ID
SAF/ACEE user ID
automation time (note 1)
automation token
z/OS CHKEY
z/OS descriptor and routing codes
z/OS destination console name
NetView domain name
DOM match time (note 2)
DOM type and token
JES job number/ID
job name
for DOMs, the number of messages matched by NetView
NetView HDRMTYPE
NetView task/operator name
reply ID at the start of a WTOR
SMSGID z/OS
system ID
TCB address (note 3)
user-defined fields
WTO key.
Notes:
(1) the Automation Time in the list above is the time in milliseconds between message creation and the
completion of the message's exposure to automation. A value of "none" is shown if the particular message
had no opportunity to be automated, but a positive value indicates only the opportunity, not that an autotable
hit occurred.
(2) The DOM time is the time in tenths of a second for a DOM to arrive after the matching message.
However, the time and the match are recorded only for action messages that are held within NetView.
(3) The TCB address is useful for distinguishing different issuers within the same ASID and can be used
for DOM matching.
6

While browsing the Canzlog, any given message may be expanded to see all these attributes that apply. In
addition, filters may be organized around virtually any combination of these attributes and applied to a
Browse session. The new CANZLOG command provides a way to name useful combinations of filters for
use later or by others.
Filters can be applied to the BROWSE command, the ALL command, and finally to the FIND command,
resulting in up to three levels of nested filters. All this provides a powerful specification to see only those
messages you want to see at a given time.
Several filters are shipped with NetView, including the following:
NETLOG similar to NETLOGx
MVSMSGS MVS (z/OS) messages
NVMVS MVS & local NetView messages
NVMSGS local NetView messages
ACTMSGS action messages and DOMs
DOMS DOMs
Customers can create more, and can display, edit, save, and delete filters. Filters can be displayed by the
LIST CZFILTER command. The CANZLOG command provides a panel-based interface to manage filters
or to simply front-end a Browse session, as shown just below. Filters can be saved on a task level or
common level (all NetView operators).
For an operator to be able to save task (operator) level filters, a data-set is required in DSIOPEN for his
use, of the form opdsPrefix.opid, where the first part of the concatenated name is defined in CNMSTYLE
for OpDSprefix, and the last part is the operator ID. The filters are saved in a member of this data-set
called OVCZFLTR. Operators without this dataset will still be able to create and save filters, but the filters
will not be restored across logons. The NetView supplied logon initial clist, LOGPROF1, has a new
7

statement 'CANZLOG INIT' which reads the operator's private filters during logon. If you use a different
initial clist, be sure to copy this command.
For an operator to be able to save common filters, he must be authorized for the COMMON keyword
within the CANZLOG command. The filters are saved in a member called DFCZFLTR in the top-most
data-set of the DSIOPEN DD.
See the help for command CANZLOG for more details.
Browsing
NetView's BROWSE command is extended in V6.1 to support Canzlog. This section will describe the new
capabilities associated with browsing the Canzlog, but we also reference a demo on this subject. A link to
the demo may be found at the end of this paper along with other references.
Browsing is done via a 3270 interface. Presentation attributes such as color and reverse video that are
associated with given messages are preserved. A given browse session starts with a new or pre-defined
filter and shows the most recent matched messages. The parameter right after BROWSE (or its synonym,
BR) may be LOG, CANZLOG or any valid filter name (see previous section for more on filters). If this
parameter is not one of these values, it is checked according to pre-NetView-V6.1 rules, for example
NETLOGA or a member name.
Many operators will begin by simply typing "BR LOG" (or use the default PF5). The LOG keyword
associates a default filter with the Browse session. This filter is the one listed next to the CANZLOG label
in the output from the LIST OVERRIDE command, which can, of course, be changed by the DEFAULTS
or OVERRIDE command. The default shipped with NetView for this is the NVMVS (MVS & local
NetView messages) filter referenced above.
The CANZLOG keyword specifies that no given filter is to be used. If no TAG keyword is given with
CANZLOG, the following is defaulted: TAG=(NVMSG,MVSMSG,DOM). For more on tags, see the
"Logging and Attributes" section above.
A common use for the Canzlog will be to peruse a "private log". Begin with "BROWSE xyz", where xyz
represents a name you choose for any combination of filters. For example, you can use the CANZLOG
command to give the name "OMVS" to a specification of JOBNAME=OMVS and, perhaps, a suitable
date/time range. Then the command "BR OMVS" takes you to the joblog for the instance of OMVS.
Regardless of the "first parameter" described above, any Canzlog BROWSE command can specify
additional filtering by adding keyword=value pairs. Some examples:
JOBNAME=JOB1 (job log for JOB1)
JOBNAME=JOB1 MSGID=ABC1 (messages from JOB1 that begin with "ABC1")
CONSOLE=JEFF TEXT=XYZ (messages destined for console JEFF containing
"xyz" in any line in any upper/lower/mixed case)
EXACTEXT=XyZ (messages that contain a match for this exact mixed-case string)
ROUTECOD=(1,2) DESCCODE=(6,7) (messages with MVS routing code 1 or 2,
and descriptor code 6 or 7)
ROUTECOD=1 ROUTECOD=2 (messages with MVS routing code 1 and 2)
ROUTECOD=1 ROUTECOD¬=2 [not sign] (messages with MVS routing code 1 and NOT code 2)
TAG=(AUDIT,TRACE) (replace the above default tags with "AUDIT or TRACE")
TAG=ALL (see everything that can be browsed)
8

These examples illustrate the way filters can be built with ANDs combined with ORs and NOTs. The
complete list of keywords in this family, and how they may be combined, form a Browse Filtering
Specification (BFS). The BFS may be used in several different commands, including BROWSE,
ALL, FIND, OVERRIDE and DEFAULTS. The Helps for all these commands provide a complete
description of the BFS. Regarding TEXT and EXACTEXT, quotes are only required if the text contains
blanks, commas, equal-signs, or other quotes. If the string contains single-quotes, use double-quote
delimiters, and vice versa.
The CANZLOG command, in addition to its ability to manage filters, may be used to simply front-end the
BROWSE command, i.e. by forming a filter from a set of BFS elements as described above, then simply
hitting Enter. The filter need not be saved. This is an alternative to typing a BROWSE command with a
BFS, and may provide better usability, depending on the complexity of the filter.
Once in the Browse panel, messages are listed that match the specified filter or BFS. In the usual case
where there are many messages that match, the most recent page of messages is shown, with the oldest
message in that page at the top. The format of each line is determined by another DEFAULTS or
OVERRIDE setting called CZFORMAT, which is a combination of date, time and source (MVS job name
or user ID, or NetView operator ID). These attributes will precede the text in the first line of each message.
In Canzlog, multi-line messages are kept together. Each line of each message respects presentation
attributes such as color, and takes up one line on the panel.
The top of the panel indicates the date and a time range of the displayed message lines. The range is shown
in yellow when all the displayed messages have the same date. Pink indicates that the bottom message has
a later date than the top message.
The top line also indicates the filters used, to the extent that it fits (more on the WHAT sub-command in a
moment).
Users of NetView's WINDOW command will recognize that the Canzlog Browse panel is built on
WINDOW. As such, some sub-commands operate just as they do in WINDOW, for example RIGHT and
LEFT. Other sub-commands are described as follows:
FIND/REVFIND - The first time you use this subcommand in a browse session, you must specify a BFS
and, optionally, "PREV" (or just "P"), which can either precede or follow the BFS. Like all commands
using BFS, this is a "message oriented" search; it will not differentiate lines within an MLWTO (but see
SHOWTEXT, below). Subsequently, you can use FIND or REVFIND without any argument, for example
via default keys F5 and F17 respectively, to repeat the previous search in a downward (FIND) or upward
(REVFIND) direction.
Note that the BFS supports a plain text option (example: FIND canceled ). Such plain text is interpreted
like the TEXT operand unless it contains no lower case characters, in which case, it is interpreted like the
EXACTEXT operand. ("F canceled" is "FIND TEXT=canceled" and "F CANCELED" is "FIND
EXACTEXT=CANCLED"). Use of the TEXT keyword results in a slower search, since all the data must
be copied and case folded prior to comparison. Using EXACTEXT is much faster and (when appropriate)
use of the MSGID keyword is even faster.
[Enter] or DISPMSG - A plain Enter key is the same as invoking DISPMSG. Either method allows you to
place the cursor on a particular message and see a detailed panel describing that message's attributes, as
described previously. HELP DISPMSG provides a guide to the information.
SHOWTEXT - Shows all the text for a message. SHOWTEXT is particularly useful if the message is long
or contains many lines. It provides a WINDOW in which searching and scrolling may be done in a single-
message context. Wide single line messages are flowed to fit the panel. Note that the Browse panel can
show you that a given string exists in a message, but you might not see it easily until you invoke
SHOWTEXT (PF2 by default).
9

LOCATE - Like what exists today for "NETLOG Browse", places you at a given date/time. If you specify
a time without a date, then LOCATE assumes the date is the same as the selected message (usually first
message on screen).
TOP/BOTTOM - Standard functions: moves the display to show the earliest (TOP) or latest (BOTTOM)
message that matches the filters in effect. If a FROM or TO value was part of the fitlering for the browse
session, then TOP and BOTTOM commands respect the limits set. Note another DEFAULTS command,
DEFAULTS CZTOPDAT, sets a default for the FROM value, automatically limiting browse sessions not
specifying a particular value.
UP/DOWN/BACK/FWD - Standard functions (defaults are F7 and F8). Note that when you supply a
number, the only messages that "count" are those that match the filter. With a restrictive filter, for
example, BACK 999999 could go a LONG way.
WHENCE - Provides the date and time (including milliseconds) and issuer information for the selected
message. For MVS messages the jobname is supplied as the issuer information, unless there is none. If
there is no jobname, the isser's user name from the ACEE is supplied. By default, F9 is set to WHENCE;
select a message by cursor and press F9 to see this extra information in the immediate message area.
WHAT - Provides full current filtering information. Response is shown in the immediate message area
unless the filter is too long, in which case the response is shown on the NCCF screen. This is the same as
the information in the yellow box at top, except that it is not truncated.
ALL - limits the display and the scope of subsequent subcommands like FIND and UP to those message
matching the original browse filter AND the BFS specified on the ALL subcommand. See FIND just above
for "BFS" notes. ALL without parameters reverts to using just the original browse filtering.
DISPMSG is its own panel, as shown just below.
10

DISPMSG describes a given message's attributes. It also has its own sub-commands, as follows:
SHOWTEXT - Shows all the text for the message, same as in Browse. See above for more information.
UP/DOWN/BACK/FWD - Shows the DISPMSG panel for the previous, or next, message matching the
current filters (defaults remain F7 and F8).
LINKMSG - displays the deleted message associated with the DOM currently being displayed. LINKMSG
has no effect unless a DOM is currently displayed that has exactly one associated message
(MsgsMatch: 1). After LINKMSG invocation (F5 by default), all navigation sub-commands, such as
BACK, FWD, or END, return you to the DISPMSG for the DOM.
A note about searching: As mentioned earlier, the process of finding matching records, whether for a
BROWSE, ALL, FIND, or scrolling command, could possibly take a long time, depending on how
restrictive the given filter combination is and how many archive files must be read from DASD. There is a
keyword, CZBRWAIT, for the DEFAULTS command which controls how long an operator is to wait for
such an operation to be satisfied. The shipped default is 10 seconds. If the time elapses before a complete
screen can be shown, a partial screen is shown and the operator is given the opportunity to continue the
operation. In the case of FIND (or REVFIND), the same panel of messages is shown, but the display at top
right is changed to indicate how far the search has proceeded.
DEFAULTS and OVERRIDE Operands
DEFAULTS CZBRWAIT - number of seconds to wait for Browse responses (initial default: 10)
DEFAULTS CZTOPDAT - default TOP/FROM date for Browse (i.e. when not specified). This value is
also discovered by NetView initialization and the TOP command (which will not make it earlier). You
might make it later to avoid duplicate error messages, for example, if some aged archive files have been
removed.
DEFAULTS/OVERRIDE INTCMD - whether to log NetView internal commands (initial default: No).
These records are marked as trace messages and you must specify the trace tag to see them. Some internal
commands such as AT/AFTER/CHRON/EVERY and PURGE are logged anyway.
DEFAULTS/OVERRIDE CANZLOG - default filters for Browse (initial default: MVS and local NetView
messages).
DEFAULTS/OVERRIDE CZFORMAT - elements of a prefix for each message on the Browse panel:
DATE/TIME/SOURCE (initial default: TIME). SOURCE is the MVS job name (if blank, user ID) or
NetView operator ID.
For more details on any of these, reference the NetView Command Reference or on-line command help.
EDIT Orders
11

AUTHUSER/AUTHGRP (new, input only, MRT and Edit) - ACEE (SAF/RACF) user ID (ACEEUSRI)
and group ID (ACEEGRPN)
CHKEY (input in MRT and Edit [new] / conversion in Edit) - as defined by system macro IEECHAIN, the
step-name of a task or the job-name of a job. When used as a conversion order (PIPE EDIT), the order
converts a two-byte binary ASID into the CHKEY value.
CZID (new, input only, Edit only) - Canzlog ID of message, DOM or command. Useful in the REXX API
but can change over time.
SETGMT - existing order to set/reset time. Now has an additional meaning: if subsequently logged,
becomes a new message in the Canzlog. Otherwise, a message already in the Canzlog is not changed
or logged again, for example, by automation.
UCHARS/UFLAGS (input/output, new in MRT and changed in Edit) - char(16) and bit(16) user fields. In
Edit, very similar to IFRAUSRC and IFRAUSRB.
WTOKEY (new, input/output in MRT, input only in Edit) - key field associated with the WTO system
macro (WQEKEY in system macro IHAWQE).
Note that EDIT orders may be used in automation tables as well as in PIPE commands. See the
Automation Guide for descriptions of the ACQUIRE and EDIT operands. For more details on the orders
themselves, see the NetView Customization: Pipes manual, or the on-line command help for EDIT.
Default Logon Profile
Canzlog may mean additional operators using NetView who were not previous NetView users. For this
reason, a default logon profile is supported in NetView V6.1. As background, NetView provides the
following methods of defining user-IDs and their related logon profiles:
NETVPW - operators and passwords defined in NetView member DSIOPF
SAFCHECK and SAFPW - operators and passwords defined in a SAF product like RACF, with profiles
defined in NetView
SAFDEF - operators, passwords and profiles defined in a SAF product like RACF.
You now define one of these in CNMSTYLE for SECOPTS.OPERSEC. They are not new, but before
V6.1, NETVPW, SAFCHECK and SAFPW installations required the profiles allowed for a given operator
to be defined in an entry for that operator in DSIOPF. Now, a default logon profile my be established in
CNMSTYLE (DEFAULTS.LogProf) or the DEFAULTS command. If that is done, an operator defined in
SAF without a DSIOPF entry, or an operator defined in DSIOPF without a profile, will be associated with
the default profile. This was primarily done so that SAFCHECK and SAFPW customers would not have to
add "Canzlog operators" to DSIOPF, although it can certainly benefit other cases.
REXX API and Printing
NetView supports a REXX API for program access to the messages recorded in Canzlog. The filtering
described previously as "BFS" is supported. The API consists of two parts: a CNMECZFS command to
12

establish filtering, and a CZR pipe stage to obtain messages.
CNMECZFS takes as input a BFS, as described above, and establishes a filtering environment for a
subsequent PIPE that includes the new CZR stage.
The CZR stage takes as input the following: a Canzlog ID (CZID as seen on a DISPMSG display) or a
date/time in STCK format, a maximum count of messages, and a direction. CZR then returns messages to
the pipe, optionally also returning indications of how many messages were returned, whether it ran to the
end in the given direction, and how to continue if needed from where it ended.
For more information on CNMECZFS and CZR, reference the on-line command helps and review REXX
samples CNMSFMSG and CNMSTMSG.
Messages are returned in the same form as many other pipe stages that return messages today. These
messages can then be examined by other stages for the kinds of attributes described in the "Logging and
Attributes" section.
There are many potential applications for programmable access to the Canzlog. One example could be
printing.
Files used in Canzlog Archiving
When preparing for Canzlog archiving, remember that NetView must be authorized to write to the HLQ
you specify and that NetView must be able to catalog the files that it writes.
Canzlog's archiving function stores two types of files: data files and index files. Both use the High Level
Qualifier described above. Index files are small and sparse; never delete or edit index files. Data files are 8
megabytes each and will contain about 40 thousand lines of text, depending on size and type of message.
At some point you will want to delete the data files or move them to a backing store. Data files that are
deleted, but later restored are immediately available to the browse function in NetView. See below for
"Moving or Restoring Canzlog Data".
NetView assists you in managing the data files in two ways: (a) by setting SMS characteristics and (b) by
embedding a date-time stamp in the data file name. Three SMS characteristics for data files are defined in
CNMSTYLE. These are data class name, management class name, and storage class name. NetView does
not set expiration dates for the archive files, but your specification for management class can imply an
expiration date. When not controlled by SMS policy, the volume serial(s) for the data files can be set by
style statements and "restyled" as necessary. When you delete Canzlog data files (never delete index files!)
for space limitation, it is anticipated that you will delete them in order, oldest first. If it is necessary to
leave some data files that are older than others being deleted, treat the older, "disconnected" files like you
would for deleted files that have been restored. See the following section for dealing with restored Canzlog
data.
When NetView is archiving, it reserves approximately 50 megabytes of data in the active log, leaving it
unwritten. This is because some updates can occur well after the message is first written, for example the
DOM match interval. When a CLOSE NORMAL, CLOSE STOP, or CLOSE IMMED command is
entered, this backlog is immediately written and close processing can be slightly delayed while the data is
written. Experience shows that these final write operations take under one second. Because of the need for
the final writes, please do a controlled shutdown of NetView prior to a planned IPL. In case of a write
failure, NetView produces message DWO090A (during shutdown, this is a descriptor code 2
message). If this occurs, try to diagnose and correct the problem, then restart NetView and allow it to
complete normally before an IPL.
13

Moving or Restoring Canzlog Data
When older data files are restored to the HLQ for where they were deleted they are immediately available
for browsing. However, the DEFAULTS CZTOPDAT will generally have been updated to show only
currently available data, so the default FROM value for browsing will be inappropriate for the older data.
You can specify appropriate FROM and TO values either directly on your BROWSE command or by using
the CANZLOG command's panel. If continued use of the older data is anticipated, the CANZLOG panel
gives you the opportunity to save the proper filter for the older data under a name you choose. See the
online help for the CANZLOG command.
A similar situation occurs when you copy Canzlog data from one system to another. You might do this
when it's easier to analyze data off of a production system or when transferring data to IBM service. The
difference here is that index files must also be copied and the receiving HLQ will not be suitable for
continued archiving by the NetView system where you do the analysis. On that NetView, you would
temporarily suspend archiving and change the HLQ. Unless your system is extremely busy, you can
suspend archiving for many hours without losing any data. The Troubleshooting Guide has detailed
information on copying Canzlog data.
Troubleshooting
The Installation and Automation section has some basic verification steps and related debugging info.
There's also some Canzlog information in the NetView Troubleshooting Guide.
Some problems require knowing what was logged in the data-space. The active log is a data-space named
CNMCANZ0 by DSI4LSIT. Other "ADS" data-spaces are named CNMCANZ1, CNMCANZ2, etc. The
number of these is determined by ARCHIVE.BROWSE.DATASPACES, described earlier under
“Installation and Automation”. ADS plots (defined just below) were all read in from the archive to service
a request. They remain there until they "age out" and that space is needed.
A few concepts and definitions that may be useful: A Canzlog segment is 128 bytes. A Canzlog block is a
message line or DOM (max 255 segments). A Canzlog plot is 8 megabytes - within a given data-space,
they are normally numbered 0-254, with the last plot consisting of control information. Segments within a
plot are numbered from 0 to 65535 ('FFFF'x). A plot equates to a single archive file.
There is a DUMPDS tool to view raw data in the data-spaces. Syntax is "DUMPDS czid numrecs" or
"DUMPDS adsnum>segnum numrecs". The raw data formats are internal, but cut/paste may help IBM
Service in cases where they don't ask for whole files. Output of the DUMPDS PLOTMAP, REVISE
DEBUG SCANSSI, and CANZLOG QRY commands may help Service too.
References and Conclusion
To view a detailed demo of the NetView Canzlog function, go to the Tivoli NetView for z/OS section in
the IBM Tivoli Media Gallery
(http://www.ibm.com/developerworks/wikis/display/tivolimediagallery/Home)
14

Publications for NetView for z/OS will be updated for NetView 6.1 at this address—
http://www-01.ibm.com/software/tivoli/products/netview-zos/
To, to ask any follow-on questions or obtain any other NetView for z/OS information at any level of detail
(or expertise), there's a very active forum at: http://groups.yahoo.com/group/NetView . Please join
the group! It's easy to do from that page.
In conclusion, the NetView team hopes you'll see a lot of value in Canzlog and other features of NetView
V6.1. Thank you for your attention!
About the Authors
This paper was written by Jeff Weiner and Tom Howe, software developers on the IBM Tivoli NetView for
z/OS product.
15