VIP Hicheel

Mainframe TCP/IP Management
for Zero Downtime, High Performance Operations
SOFTWARE DIVERSIFIED SERVICES (SDS)
VITAL SIGNS VISIONNET IP MONITOR (VIP) V4.6
Mastering Complexity:
Monitoring z/OS IP Networks
Easily, Graphically, Thoroughly
A White Paper
Response time monitoring;

z/OS z/OS OS/390 OS/390 z/OS
HTTP in VIP v4.6 & ‘tn’ in VIP v4.0
z/OS
LPAR LPAR LPAR LPAR LPAR Linux
LPAR
LPAR
VIP agent z/OS
VIP LPAR
z900 or S/390 server
z990
VIP
server
intranet
Linux
LPAR z/OS
LPAR
VIP agent
z8xx The
Internet NEW IN VIP V4.5:
fragmentation detection & location
VIP
server
System System
Operators Operators
April 2006
© Software Diversified Services 2006

TABLE OF CONTENTS
PREAMBLE & OVERVIEW .................................................................... 3
CHARACTERISTICS OF A GOOD MAINFRAME TCP/IP MONITOR (TABLE) .............. 6
VIP V4.6: TWENTY (20) CLEAR DIFFERENTIATING FEATURES ........................ 9
VIP V4.6: THE ARCHITECTURE CONTINUES TO BE THE KEY ........................... 13
DIRECT TCP/IP STACK ACCESS: A NOTEWORTHY BREAKTHROUGH ................... 15
RESPONSE TIME AND PACKET FRAGMENTATION MONITORING ........................... 20
DATA PRESENTATION: MAKING SENSE OF IT ALL ........................................ 26
AGENT/SERVER ARCHITECTURE ............................................................ 29
THE BOTTOM LINE ........................................................................... 30
SELECTED GLOSSARY ................................................................ 31
SOFTWARE DIVERSIFIED SERVICES (SDS) ............................................. 31
VIP’S RECENT TRACK RECORD OF EXCELLENCE
IN VIP 4.6 [MARCH 2006]:

¾ HTTP response/performance analysis for z/OS HTTP applications & servers
including those running on Unix System Services (USS).
¾ Traceroute, with configurable protocol (TCP, UDP, ICMP), to penetrate

firewalls and accurately determine application availability.
¾ Use of IBM’s Network Management API extended to include EE monitoring.
¾ New ‘iconic’ alerts and traffic profile, with fragmentation ‘count’ and pop-
up protocol percentages, on the “Network at a Glance” screen [page 8].
IN VIP 4.5 [JANUARY 2006]:

¾ Comprehensive IP fragmentation monitoring with automated identification
of where the fragmentation is occurring [i.e. source].
¾ Simplified VIP mainframe agent installation.
IN VIP 4.0 [FEBRUARY 2005]:

¾ Tn3270 Response Time Monitoring.
SDS VIP v4.6: mastering complexity 2/32 Software Diversified Services

Mainframe TCP/IP Management
for Zero Downtime, High Performance Operations
SOFTWARE DIVERSIFIED SERVICES (SDS)
VITAL SIGNS VISIONNET IP MONITOR (VIP) V4.6

Mastering Complexity:
Monitoring z/OS IP Networks Easily, Graphically, Thoroughly
TCP/IP has now firmly displaced SNA as the preferred and strategic means
for mainframe networking. That is beyond refute. SNA mission critical
applications, these days, are successfully sustained across TCP/IP
networks through a combination of ENTERPRISE EXTENDER (EE), TN3270(E)
WEB-TO-HOST and possibly even the IBM COMMUNICATIONS CONTROLLER FOR
LINUX (CCL). Thus to realize ‘zero downtime’ mainframe operations, with
crisp and consistent response times for interactive users, one has no
choice but to master TCP/IP management and response time monitoring
(RTM) – in particular for ‘tn’ and HTTP(S) traffic (along with incisive
capabilities to detect and rectify IP packet fragmentation).
Mainframe TCP/IP networking is invariably complex, often challenging, and

sometimes a bit confounding. This is to be expected given what can be
involved and what is at stake.
Mainframe TCP/IP networking can involve multiple stacks per LPAR, virtual
addresses, gigabit OSA interfaces, HIPERSOCKETS, DYNAMIC VIPA takeovers
across a SYSPLEX, disparate application protocols, many hosts, and lots of
connectionless interactions. There is also a need to be cognizant of
ROUTERS, (fragmentation inducing) IPSEC GATEWAYS, SWITCHES, FIREWALLS, and
possibly even LINUX LPARs – with performance, in particular ‘3270’ and
HTTP(S) response times, always a concern, and security a nagging worry.
To stay on top of all of this, to deliver ‘zero downtime’ operations, you

need a good mainframe network monitor that is probing, incisive,
thorough and nimble – that, moreover, works in true real-time. Otherwise
“you will be flying blind.” Having a comprehensive RTM capability, coupled
with IP fragmentation management, is an added bonus – like having radar.
It permits you to see potential problems way out and take evasive action
before they cause any disruptions.
A good mainframe network monitor also needs to be simple, intuitive and

easy-to-use. Otherwise it will hinder rather than help. In regards to this,
the incomparable Leonardo da Vinci said it best:
“SIMPLICITY IS THE ULTIMATE SOPHISTICATION”

S/390 Parallel Sysplex
cluster
VIPA VIPA VIPA VIPA

192.168.253.2 192.168.253.3 192.168.253.4 192.168.253.5
LPAR LPAR
Apps. Apps. Apps. Apps.
Sockets Sockets Sockets Sockets

TCP TCP TCP TCP
IP IP IP IP
VIPA VIPA
192.168.253.1 192.168.253.6
LPAR
Apps. Apps.
Coupling
Sockets Facility Sockets
TCP TCP
IP ESCON/FICON IP
I/O System
192.168.253.4 TODAY’S MAINFRAME TCP/IP

IP cached IP address NETWORKING CAN BE COMPLEX IN
network THAT IT CAN INVOLVE MULTIPLE
HOSTS, MANY LPARS, VIRTUAL IP
ADDRESSES AND EVEN FEATURES
IP clients IP clients SUCH AS DYNAMIC VIPA TAKEOVER IN
THE EVENT OF AN LPAR FAILURE.
Mainframe TCP/IP networking, though now stable, robust and capable of

sustaining mission-critical applications, is, nonetheless, very different, in
many basic ways, from SNA. SNA, per contemporary vernacular, was highly
controlling. The mainframe-resident SSCP had its tentacles into everything,
all the time, and tried to keep tabs on what everybody was up to.
Not so with IP networking. IP is ultra laid-back and eschews control

sessions. It permits connectionless interactions and does not worry about
data packets that never reach their destination. Moreover, the physical
inter-network used is likely to involve considerably more disparate link
types, networking ‘boxes’ and technologies [e.g. tunneling] than was ever
the case with SNA/APPN, thus introducing a whole new plethora of potential
networking headaches; for example undetected packet fragmentation that is
sapping resources and performance.
This is hence a very different networking paradigm to what mainframe

professionals were accustomed to. A good mainframe TCP/IP network
monitor thus needs to help mainframe professionals smoothly bridge this
divide and enable them to maintain optimum system/network performance
despite the paradigm shift. Such a monitor will provide all the pertinent
management data, detailed response time statistics for the mission-critical
interactive sessions [e.g. ‘tn’ and HTTP(S)] as well as the means to quickly
identify and rectify IP packet fragmentation in easy to follow graphical form
with icons, pop-ups and a ‘drill-down’ capability. Automated, ‘intelligent’
alarms, when certain thresholds are crossed, are also imperative.
A good mainframe TCP/IP network monitor should let system operators,
help desk personnel, and system programmers focus all of their attention

on monitoring and managing the network without having to contend with
obfuscating processes and hard to fathom data displays. They should
have total confidence in the proven power and capabilities of their monitor
and know that their monitor will automatically notify them of potential
problems (while at the same time activating necessary problem analysis
functions) – ideally well before these problems become ‘show-stoppers’ or
start impacting response times.
Continuous, intelligent response time monitoring, with multiple preset

threshold alerts, is invariably a very accurate measure of overall
system/network health and stability. Sudden, unexpected changes in
response time characteristics tend to be a leading-edge indicator that
something has changed within the overall system. Degradation in
response times, in mission-critical mainframe networks, can also result in
lost opportunity costs [e.g. inability to complete financial trades prior to
changes in price], decrease in user productivity, and a flurry of calls to the
help desk by disgruntled users. A comprehensive RTM scheme that
quickly detects changes in response times and automatically raises
appropriate alerts thus serves as an invaluable ‘early warning’ mechanism
of potential system, network or application problems.
With these basic parameters nailed down, one can go on to categorize the
essential characteristics of a good mainframe TCP/IP network monitor.
These characteristics are listed in the table on page 6. However, to make
these categorizations even more pragmatic and useful, they have been
further divided into “must-have” imperative features, and “icing on the
cake” highly-desirable attributes. The monitor that you choose should
include, without any caveats, all the features listed in the “must have”
column, and ideally most of those listed in the other column.
THE IP FRAGMENTATION
MONITORING INTRODUCED IN
VIP V4.5 IDENTIFIES
FRAGMENATION AND
FRAGMENATION ERRORS FOR
EACH TCP/IP STACK – WITH
THE PIE-CHARTS AND GRAPHS
PROVIDING ADDITIONAL (AND
HISTORIC) DATA ON
FRAGMENTATION PER
APPLICATION, PROTOCOL, PORT
OR CONNECTION ETC.

CHARACTERISTICS OF A GOOD MAINFRAME TCP/IP NETWORK MONITOR
IMPERATIVE HIGHLY-DESIRABLE
¾ ability to monitor multiple LPARs per ¾ direct retrieval of management data from the
mainframe and multiple mainframes from a TCP/IP stacks, via IBM supplied Network
single screen. Management APIs (NMI) when possible,
augmented, where necessary, with full SNMP
¾ accurate, “up to the second” at-a-glance
access and packet tracing.
status maps of the entire network, with
iconic alert summaries, traffic profiles and ¾ browser-based, highly-visual, point-and-click
packet fragmentation notification. monitoring – that is both intuitive and simple
(without a steep and rocky learning curve).
¾ ever vigilant, fast acting (but intelligent)
‘watch dog’ scheme to quickly generate ¾ support for Enterprise Extender (EE), ideally
alerts when certain thresholds are crossed. using IBM’s strategic NMI, so that all
connection details are always available.
¾ intelligent, real-time synthesis and
correlation of data from the stacks, NMI and ¾ fast auto-discovery of all local stacks,
traffic analysis to create a true and incisive applications and interfaces.
portrayal of network conditions.
¾ agent/server based architecture to minimize
¾ Exploit SNMP traps and report to a Monitor of mainframe overhead [e.g. CPU usage] while
Monitors vis-à-vis HP OpenView and CA affording maximum deployment flexibility.
Unicenter.
¾ integrated DNS look-up.
¾ incisive response time monitor (RTM) for
¾ minimal reliance on high-overhead data
mission-critical interactive traffic, in
collection schemes such as SNMP, to avoid
particular ‘tn’ and HTTP(S) sessions—with
high mainframe CPU usage.
the ‘tn’ monitor compliant with the RFC 2562
standard as supported by IBM’s tn3270(E) ¾ Multi-protocol ping and traceroute, to probe
server. employing the same protocol and hence the
same routing as the application, with the
¾ comprehensive IP fragmentation monitoring
potential to traverse firewalls, and, in the
with the necessary functions to help locate
case of TCP, to determine if a remote
the cause of any packet fragmentation.
application is listening on a port.
¾ immediate access to both current and
¾ access to summarized OSA performance data
historic FTP and telnet activity reports.
reports on physical channel, LPAR utilization,
¾ remote host monitoring to have visibility of and OSA usage.
external systems, such as routers, switches
¾ Externally deliverable (such as by email)
and firewalls.
graphical reports to show historic
¾ being nimble, light and low-overhead so that performance metrics such as interface or
it is responsive – and furthermore does not stack usage.
get in the way of production workloads.
¾ customizable chart types [i.e. data views] to
¾ comprehensive support for all OSA and OSA- suit individual preferences.
Express interfaces.
¾ flexibility to set multiple, meaningful RTM
¾ intelligent monitoring of tn3270(E) with SNA threshold alarms based on multiple criteria.
correlation; e.g. LU names, unused LUs etc.
¾ quick and easy installation of the necessary
¾ NetView interoperability. mainframe agents.
SIMPLE, INTUITIVE AND EASY-TO-USE.

SDS, a company that has been successfully delivering mainframe software
for 25 years, has gone to great lengths to ensure that its VIP, at release
v4.6 (as of March 2006), conforms to all of the above iterated
characteristics for a good, incisive and easy-to-use mainframe TCP/IP
network monitor. Focusing on simplicity to overcome much of the
inherent complexities of mainframe TCP/IP networking has been an
overriding design goal of VIP – from day one. By v4.6, VIP, with an
incremental stream of enhancements, such as the automated location of
the source of IP packet fragmentation and most recently, HTTP
performance monitoring, has fulfilled this goal to such as an extent that
one can claim, without the fear of rebuttal, that VIP v4.6 now lets you
master the complexities of mainframe TCP/IP networking with confidence
and élan!
VIP v4.6, as exemplified by the new “Network at a Glance” screen [page

8], thus sets out to define a bold new standard for fast, comprehensive,
browser-based, graphical TCP/IP monitoring that emphasizes simplicity,
clarity and flexibility. It eliminates blind spots [e.g. a server that is hung
or under stress] that are possible with other schemes, and v4.6 augments
both the state-of-the-art RTM facility for tn3270 introduced with v4.0 and
the IP fragmentation management introduced with v4.5, to now include
detailed HTTP(S) response/performance monitoring.
VIP uses an agent/server architecture, with VIP monitoring agents

available for OS/390 v2.9 all the way through to z/OS v1.7. Data
gathered by the agents are fed, in real-time, to one or more VIP servers
[with the agents making sure that only the data that has changed is sent
to the servers so as to minimize agent-server traffic]. Deploying multiple
servers guarantees resilience for ‘zero downtime’ operations. The VIP
servers, which are implemented in JAVA, can be deployed on PCs running
Windows, Linux/Unix servers [including Linux LPARs], or an ‘MVS’ LPAR
with Unix System Services (USS).
NEW IN VIP V4.6:

HTTP
PERFORMANCE
ANALYSIS TO
COMPLEMENT THE IP
FRAGMENTATION
MANAGEMENT
INTRODUCED WITH
V4.5 AND THE
TN3270(E) RTM

z/OS z/OS OS/390 OS/390 z/OS
z/OS
LPAR LPAR LPAR LPAR LPAR Linux
LPAR
LPAR
VIP agent z/OS
VIP LPAR
z900 or S/390 server
z990
VIP
server
intranet
Linux
LPAR z/OS
LPAR
VIP agent
z8xx The
Internet
VIP
server
System System
Operators Operators
THE LOW-OVERHEAD, FLEXIBLE AGENT/SERVER ARCHITECTURE OF

VIP V4.6, WITH ITS ABILITY
TO MONITOR MULTIPLE LPARS ON MULTIPLE MAINFRAMES FROM A SINGLE BROWSER-BASED
SCREEN, DELIVERS FAULT-TOLERANT CONFIGURATIONS
THROUGH THE USE OF REDUNDANT VIP SERVERS.
VIP’S TRADE-MARK “NETWORK AT A GLANCE” SCREEN, ENHANCED WITH V4.6 TO DISPLAY NEW
‘ICONIC’ ALERTS AND A GRAPHICAL TRAFFIC BAR THAT ALSO INCLUDES PACKET FRAGMENTATION
COUNT LINKED TO THE FRAMENTATION MONITOR (IN THE EVENT THAT FRAGMENTATION IS TAKING
PLACE WITHIN THE NETWORK) AS WELL AS POP-UP PROTOCOL USAGE IN TERMS OF PERCENTAGES.

VIP V4.6: TWENTY (20) CLEAR DIFFERENTIATING FEATURES
1. Direct retrieval of all necessary management data from the pertinent

TCP/IP stacks using a cross-memory interface and IBM’s strategic
NMI – obviating the need for repetitive, inefficient SNMP queries or
ungainly ‘screen scraping.’
2. Stack access for management data augmented by full SNMP support

to provide visibility of any SNMP enabled device such as remote
hosts, routers, and Linux virtual machines, so as to eliminate any
and all ‘blind spots’ within the network.
3. In marked contrast to competing schemes that rely on just one

technique [e.g. packet tracing, SNMP or NMI] to obtain all the
network management data they report and act upon, VIP v4.6,
instead, synthesizes and correlates relevant data from stack access,
NMI, SMF records and packet tracing to provide an unprecedented
very detailed and accurate ‘total picture’ of mainframe and network
status and performance.
4. Browser-based GUI (elegant, easy-to-master and simple-to-use) that

permits an entire network, consisting of multiple systems and
multiple LPARs, to be viewed and monitored from within a single
window.
5. Truly real-time alert handling, with customizable threshold settings,

to facilitate anticipatory management.
THE NEW,
INFORMATION-
PACKED, “ALERTS AT
A GLANCE” SCREEN
IN VIP V4.6 THAT
ENABLES OPERATORS
TO QUICKLY ZERO-IN
ON ON-GOING OR
POTENTIAL NETWORK
ISSUES.

6. Comprehensive and flexible, RFC 2562 standard-based response time
monitor (RTM) for tn3270 traffic using mainframe-resident tn3270(E)
servers, that is capable of monitoring an entire server, a specific
subnet or individual sessions – with the response times, furthermore,
split into their SNA system versus IP network transit time sub-
components for a thorough understanding of end-to-end
performance characteristics and potential bottlenecks. [page 20]
7. Innovative response and performance monitoring of HTTP(S)

applications and servers with VIP v4.6 able to report average time to
connect [i.e. time taken for TCP handshake(s)], time for ‘1st byte
response’ [i.e. arrival time
for the first byte of
requested data] and data
transfer rates (in bytes/sec).
[page 24]
8. Intelligent and automated IP

fragmentation monitoring
that in addition to providing
real-time notification of any
occurrences of IP
fragmentation also activates, automatically, the necessary traffic
analysis to quickly and decisively locate the source of the
fragmentation. [page 25]
9. Detailed visibility of OSA(-Express) operations, at a glance, for both

TCP/IP and SNA traffic, including operational status, actual data
transfer speeds, LPAR utilization and traffic activity – with the option
of ‘drill down’ analysis on each entry.
10. Fast, automatic, dynamic discovery of stacks, applications and

interfaces – on a continual basis, so as to transparently
accommodate LPAR or stack re-activations.
11. The ability to produce customizable dynamic Java based graphical

performance reports that can be scheduled to run on your z/OS
systems and then automatically delivered via email and/or FTP.
12. Powerful remote host monitoring capability that provides in-depth

visibility of remote hosts outside the mainframe, replete with
features such as ping response time recording, path determination
and length measurement, connection statistics and stress testing
options.
13. Ability to activate multiple Response Time Monitors (RTMs), on-

demand or via scheduled automated activation, to monitor multiple
servers, or various permutations of subnets and individual sessions
with the option of setting various meaningful threshold values for

generating alerts on any unexpected deviations in response time
characteristics within customizable sample periods.
14. Provides 9 incisive, at a glance, network monitoring screen interfaces

(all of which can be customized to display the data in different views)
for:
- NETWORK STATUS - ALERTS - APPLICATIONS
- FTP - TELNET/TN3270(E) - EE
- NETWORK ACTIVITY - OSA - REMOTE HOSTS
15. Includes 7 powerful and utilitarian (but easy to use) diagnostic tools
that address all pertinent TCP/IP network management scenarios:
- PING (ICMP & UDP) - IP PACKET TRACE - DNS LOOKUP
- TRACEROUTE - SNMP MIB QUERIES - CONNECTIONS

[TCP & UDP] EXPLORER
- MVS SYSTEM OPERATOR COMMAND CONSOLE
16. Fault-tolerant, ‘zero downtime’ configurations possible, at very low

costs, through the use of redundant VIP servers.
17. Extensive tracking of FTP session activity with real-time, live traces
as well as historical data.
18. Provision of multi-protocol ping and traceroute, to probe employing

the same protocol and hence the same routing as the application,
with the potential to traverse firewalls, and, in the case of TCP, to
determine if a remote application is listening on a port.
19. A full, successful installation is unlikely to take more than one hour.
20. Superior documentation and exceptional technical support from SDS.
The above 20 items, though powerfully persuasive on their own, are by no

means the only differentiating features possessed by VIP v4.6. VIP v4.6
includes many, many more, such as:
• activity at a glance, sorted by system, on a system/stack,
stack/application basis, with multiple, dual-field based ranking
options.
• ‘Telnet At A Glance’ linkage with the tn3270 RTM to provide easy

access to Telnet LU Groups and server data – thus enabling quick
retrieval of inactive LUs or further analysis of RTM thresholds to
determine the need for additional response time monitoring to spot
potential ‘trouble spots.’
• packet traces maintained in IPCS format for compatibility with IBM’s

packet trace utility, with optional conversion for use with SNIFFERs.
• alert forwarding to NETVIEW via a program-to-program interface (PPI).
• COMMUNICATIONS STORAGE MANAGER (CSM) statistics.
• EE connection data.
• Easy access to statistics from z/OS Communications Server about

Intrusion Detection Services (IDS) status for TCP/IP stacks.
• straightforward and simple installation of mainframe agents.
• very efficient, lean-and-mean data transfers between the VIP agents

and the servers – only new values are transferred, to minimize data
transfer volumes and maximize efficiency.
To exhaustively go through the complete list of VIP v4.6 differentiators is

not, however, a goal of this white paper. This white paper instead wishes
to focus on a few specific VIP v4.6 highlights. You should contact SDS for
other collateral that will list all of VIP v4.6’s capabilities.
THE REVISED, BIG-PICTURE-ALL-AT-ONCE, “APPLICATIONS AT A GLANCE” VIP V4.6 THAT PROVIDES

SCREEN IN
OPERATORS WITH A BIRD’S EYE VIEW OF ALL OF THE APPLICATIONS BEING MONITORED – WITH VISUAL, ‘ICONIC’
PROMPTS IF THERE ARE ANY OUTSTANDING ALERTS PERTAINING TO ANY OF THE APPLICATIONS.

VIP V4.6: THE ARCHITECTURE CONTINUES TO BE THE KEY
Mainframe professionals, more so than most, understand and appreciate

the power and long-term benefits of having products built around a sound
and solid architecture. They know about mainframe POPs and SNA.
Having been a mainframe shop for over two decades, SDS values the
manifold benefits of well-architected software solutions. Hence they go to
great lengths to ensure that VIP is built per the dictates of a well-reasoned
and carefully thought out architecture.
The core architectural requirements for VIP revolved around efficiency,

functionality, incisiveness, reliability, and extensibility – all of it tempered,
throughout, with simplicity. The resulting architecture, that has been
repeatedly validated and vindicated over the last few years with VIP v1,
v2, v3 and v4.x, consists of three primary methodologies:
1. multimodal data collection whereby the required management data is

obtained from multiple sources via different data extraction schemes,
with preference always given to the most efficient scheme available at
any given time – rather than relying exclusively on just one particular
scheme [e.g. SNMP] as is the wont of some other mainframe
monitors. If one particular collection scheme is not available (for
whatever reason), VIP will automatically resort to using the next most
efficient scheme for obtaining the relevant data.
In the context of multimodal data collection, VIP 4.6, whenever
possible, favors direct stack access and the use of IBM’s NMIs. VIP
v4.6 extended VIP’s use of NMI to also include EE monitoring. With
NMI VIP v4.6 can now provide more incisive information on EE activity
and status. However, thanks to its multimodality, VIP v4.6 can still
continue to provide EE monitoring via stack access when NMI is not
available.
If the required information, for example ‘tn’ response times or packet
fragmentation indication, cannot be derived from stack access or via
the NMIs then VIP v4.6 will turn to other schemes such as traffic
analysis [i.e. packet interception] to obtain the necessary data. As a
rule VIP v4.6 eschews high-overhead data collection schemes such as
SNMP and screen scraping, and uses SNMP only as a last resort.
2. reliance on a flexible, unrestricted VIP agent/VIP server configuration

which permits the use of multiple servers, and the ability for VIP
agents to simultaneously forward (new) data to multiple VIP servers
[as shown in the figure on page 8].
3. browser-based, highly graphical data presentation scheme.
Each of the above chosen methodologies has its own set of unique
advantages. For example, VIP being browser accessible means that
suitably authorized system operators can monitor and manage their
TCP/IP networks from anywhere in the world – whether it be another
building, a conference room, home, hotel, airport lounge, or a health club.
But that is not all.
These three methodologies together, provide VIP with significant synergy

relative to its core design goals. These can be summarized as follows:
MULTIMODAL
DATA COLLECTION AGENT/SERVER BROWSER-BASED
EFFICIENCY 9 9 9
SPEED 9 9
LOW MAINFRAME USAGE 9 9 9
FUNCTIONALITY 9 9 9
EXTENSIBILITY 9 9 9
RELIABILITY/REDUNDANCY 9 9
OVERALL SIMPLICITY 9 9 9
EASE-OF-USE 9
FAST INSTALLATION 9 9 9
VIP V4.6’S CONNECTIONS

EXPLORER SCREEN FOR
MONITORING SPECIFIC IP OR
SNA/’TN’ SESSIONS
IDENTIFIED BY IP ADDRESS
OR LOCAL/REMOTE PORT
NUMBER IN THE CASE OF IP
OR VTAM APPL. NAME/LU
NAME IN THE CASE OF
SNA/’TN’.

DIRECT TCP/IP STACK ACCESS: A NOTEWORTHY BREAKTHROUGH
The significance and implications of VIP’s direct TCP/IP stack access

scheme for management data harvesting are huge – and far reaching. It
was an inspired and breakthrough design decision that enables VIP to
outclass competitive offerings on multiple fronts.
If you stop and think about it, even for a second, it is easy to see that all
TCP/IP related data maintained by a MIB must come, in the first place,
from, or via, the TCP/IP stack. This is the basic premise of what this key
VIP feature is all about. If you can tap into the required data at its very
source, i.e. the stack, then there is really no rationale for using any other
scheme.
VIP’s direct stack access scheme allows it to retrieve all the same TCP/IP
monitoring data that SNMP obtains from the standard TCP/IP and IBM
Enterprise MIBs – albeit at a fraction of the processing overhead. This
translates directly to:
speed responsiveness low CPU utilization

more up-to-date accuracy
The last item mentioned above, i.e. ‘more up-to-date accuracy’, is a direct,
positive consequence of the low CPU utilization of this scheme. Given the
low CPU utilization [i.e. lower costs], VIP v4.6 can collect data more often
without impinging on the CPU resources available to handle the production
workload.
More frequent data collection eliminates the potential for blind spots by
ensuring that events and changes in status are detected faster, minimizing
the elapsed time before the pertinent changes are visible to the system
operators. This is in marked contrast to the case with mainframe monitors
that rely predominantly on SNMP.
Since SNMP querying gobbles up CPU cycles, the SNMP polling interval has
to be relatively long to make sure that SNMP processing does not severely
impact the production workloads. Much, however, can and will happen
during these long SNMP sampling intervals. Thus with a monitor that
relies mainly on SNMP, activity monitoring becomes akin to looking at the
stars in heaven. What you are seeing is an image of things that happened
a long time ago, as opposed to what is really happening out there now!
Thus with direct stack access you get genuinely real-time, minimally
obtrusive network monitoring that does not get in the way of the
production workloads that it is supposed to be monitoring. In reality,
direct stack access, à la VIP, is the best way to obtain accurate real-time
data about TCP/IP activity.

AVOIDING THE SNMP TRAP FOR STACKS
The SNMP approach for obtaining mainframe MIB data, the technique used
by the other competitive mainframe monitors, can be extremely inefficient
and cumbersome – with no redeeming merits. To use SNMP, one needs to
configure and activate the OSNMP daemon – for each stack that needs to
be monitored. There are processor overhead and administrative costs
involved with just setting up and maintaining these daemons.
Once configured and activated, the daemon for each stack has to be
repeatedly polled, via UDP packets, to obtain the necessary data from the
MIBs. In some cases, these queries to the OSNMP daemon can result in
large amounts of superfluous data, such as lengthy connection tables.
These repeated polls, and the data they generate, consume considerable
mainframe bandwidth and furthermore impinge on the processing of the
production workload. Genuine, real-time network monitoring is really not
possible with this approach.
Much of the pertinent data available via this high-overhead daemon

querying technique is available to VIP v4.6 via an efficient cross-memory
access scheme between the stack and the VIP agent. Rather than
receiving superfluous data, VIP can thus get exactly what it wants, from
the stack – when it needs it. VIP’s direct stack access scheme is thus a
win-win proposition. It provides VIP with much of the information it needs
at a fraction of the overhead associated with the SNMP approach. This is
why VIP v4, like the previous versions of VIP, is noted for its low CPU
usage, while competing products are known to require 5% or more.
The bottom line here is that one cannot escape the fact that the SNMP
approach is inferior to the direct, cross-memory stack access scheme used
by VIP v4 – whichever way you try to slice or dice it. One can sum it up in
one pithy phrase:
When it comes to mainframe TCP/IP monitoring,
SNMP is just passé.

USING SNMP FOR REMOTE HOSTS
Just because VIP v4.6 eschews SNMP for getting mainframe TCP/IP stack
data does not, however, mean that VIP v4.6 does not support SNMP. In
reality, VIP v4.6 includes uncompromised SNMP support.
The VIP v4.6 SNMP MIB inquiry capability, moreover, maps several
standard MIBs and supports the querying of any free-form MIB entry.
This SNMP support, augmented by multiprotocol ping and traceroute, and

connection monitoring, form the core of VIP v4’s powerful remote host
monitoring capability. Thus with VIP v4.6 you get the best of both worlds
– SNMP-based monitoring for remote hosts when you need it, and simple
ping, traceroute, and connection monitoring when you don’t.
The bottom line is that VIP v4.6 includes comprehensive, undiluted,

standards-compliant SNMP support. However, VIP does not use SNMP for
local stack monitoring, where it can much more efficiently get the data it
needs directly.
VIP V4.6’S “REMOTE HOST MONITORS AT A GLANCE” SCREEN WITH THREE ‘DRILL DOWN’
POP-UP SCREENS DISPLAYING SPECIFIC RESPONSE TIME AND PATH LENGTH OPTIONS.

THE FUTILITY OF RELYING PRIMARILY ON PACKET TRACING
TCP/IP monitoring products that rely primarily on full-time packet tracking
as opposed to SNMP may also be inefficient and result in high-overhead.
Furthermore, packet tracing alone can result in dangerous blind spots! It

only sees the packets, and cannot see what is happening within the stack.
This means it does not have access to IDS activity. It also cannot see the
backlog values maintained between TCP and an application. This is
significant because an application that is hung [i.e. not responding] or is
under undue stress may be indicated by a rise in the connection backlog.
When the maximum backlog threshold is exceeded, the application starts
quietly dropping new connection requests.
The ability to monitor connection backlog means that an alert can be

raised before the mainframe starts dropping connections. To not see
these backlog statistics is a huge blind spot. VIP v4.6 does not have this
blindness. Because VIP v4.6 monitors statistics at the stack, it “knows”
what the stack knows and can generate an alert before a mainframe starts
dropping connections.
Packet tracing can be a great diagnostic tool – used judiciously when the
required data [e.g. ‘tn’ response times] is not available from other
sources, in particular the stack. It is not an efficient or complete primary
means of network monitoring. Hence the emphasis with VIP on
multimodal data collection, with packet tracing being just one of the
multiple schemes used.
Packet tracing involves intercepting and then analyzing each and every
packet destined to, or originating from, a TCP/IP stack. It involves
copying and storing packet images so that they can be processed to
extract the relevant network monitoring data. Though, at face value, this
approach may appear to be a viable means of providing real-time network
monitoring, in reality, it is fraught with drawbacks.
For a start, just the act of intercepting and copying all packets slows down
all network traffic! Mainframe performance experts will vouch for this.
The delay introduced by packet tracing is such that in some cases timing
related TCP/IP problems can be “fixed” by activating packet tracing to slow
down the network traffic. So packet tracing rather than being truly real-
time, instead distorts real-time network processing.
This technique, with its reliance on data copying, may also incur significant
CPU, virtual storage and paging overhead. The bottom line here is that
just as with SNMP MIB querying, packet tracing is not a method suited for
fast, low-overhead mainframe TCP/IP monitoring.
Packet tracing, though not optimum for network monitoring, is, however, a
very useful diagnostic tool for problem isolation. Thus, VIP v4.6 does
indeed have a powerful IP packet trace facility that interfaces directly to
IBM’s packet trace utility. In addition, VIP v4.6 uses packet tracing for its
tn3270 RTM, HTTP performance and packet fragmentation detail

monitoring features since this is the only realistic way to obtain the
requisite data.
However, VIP v4.6 only intercepts and analyzes the packets associated
with the specific sessions being monitored. It is thus very much a goal-
specific packet tracing mechanism that is markedly different from that of
constantly tracing each and every packet in order to glean management
data (that is available from other sources, in particular the stack). This is
another example, as with the SNMP support, of VIP’s overarching
multimodal data collection philosophy. It ensures that customers always
get the best of all worlds; packet tracing for diagnostic purposes as well as
for the performance related features, and direct stack access for most of
the other monitoring activities.
WRAPPING UP DIRECT TCP/IP STACK ACCESS

It should be clear by now that the VIP v4.6’s multimodal data collection
methodology with its marked bias towards direct stack access whenever
possible, is, indubitably, the best approach for real-time, low-overhead
mainframe TCP/IP management. The multimodal approach does not have
the limitations associated with the schemes that rely predominantly on
SNMP-based MIB queries, full-time packet tracing, or screen scraping.
Thus VIP v4.6’s rationale for favoring direct stack access for the bulk of its
needs, rather than relying on SNMP or packet tracing, is obvious and
extremely logical. The stack, with a plethora of relevant data and
statistics, is the source of most of the data required for incisive, real-time
mainframe TCP/IP monitoring.
VIP V4.6’S “FTP

AT A GLANCE”
SCREEN THAT
PRESENTS A
CONSOLIDATED
VIEW OF ALL
ONGOING FTP
ACTIVITY.

RESPONSE TIME AND PACKET FRAGMENTATION MONITORING
ADD LONG-RANGE RADAR TO SEE BEYOND THE HORIZON
VIP v4.6 includes three response time and performance monitoring related
features to ensure that system operators have the best possible real-time
visibility of network activity. These three response time and performance
monitoring related features being:
1. incisive and flexible tn3270 response time monitoring (RTM) scheme

based on RFC 25621. [Refer to figure on page 21]
2. detailed (and innovative to boot) HTTP response times and

performance monitoring for z/OS HTTP applications and servers,
including those running on Unix Support Services (USS) – ideally
suited to meet the needs of today’s service level agreement (SLA)
compliance management. [Refer to screen shot on page 7]
3. comprehensive, intelligent IP packet fragmentation monitoring with

automated identification of where the fragmentation is taking place
[i.e. location of the source of the fragmentation]. [Refer to screen
shot on page 5]
TN3270 RTM: A LEADING INDICATOR OF NETWORK HEALTH

Intelligent monitoring of tn3270 response times with multiple threshold
settings, with any unexpected deviations automatically generating an
alarm, tends to be a critical, and very accurate, measure of overall
system/network health and stability. Seasoned network administrators
know that any sudden swings in response time characteristics tend to be a
leading-edge indicator that something has changed within the overall
system.
An increase in tn3270 response times would typically signal: failure of an

interface, rerouting within the IP network, packet fragmentation, growing
congestion at one or more nodes, an application failure being
compensated for by a Parallel Sysplex setup, or intermittent errors on a
network link. A sudden, unexpected decrease in tn3270 response times,
as mentioned earlier, could also be an indication that something has
changed within the system/network – thus providing the 3270 traffic with
more bandwidth (or system resources). An incisive RTM scheme is thus,
indubitably, a sound and unparalleled ‘early warning’ system vis-à-vis
system/network management.
1
“Definitions of Protocol and Managed Objects for TN3270E Response Time
Collection Using SMIv2 (TN3270E-RT-MIB)” submitted by IBM in April
1999.

The following diagram, taken directly from RFC 2562, shows how TN3270E
response time measurement is taken when responses have been
negotiated with the client.
------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D |
| ------------------------------------------> |
| reply(DR) E | |
| <----------------------------------------< |
| | +/-RSP F |
| >-------------------- - - - - - - - - - > |
| |
------------------------------------------------
A TN3270E server can save timestamp D when it receives a client

request, save timestamp E when the target SNA host replies, and save
timestamp F when the client responds to the definite response request
that flowed with the reply. It doesn't matter whether the target SNA
host requested a definite response on its reply: if it didn't, the
TN3270E server makes the request on its own, to enable it to produce
timestamp F. In this case the TN3270E server does not forward the
response to the target SNA host, as the dotted line in the figure
indicates.
The VIP v4.6 RFC 2562 compliant RTM scheme is powerful and flexible
with no artificial caveats. The v4.6 RTM is capable of monitoring an entire
server, a specific subnet or individual sessions. It is also possible to have
multiple RTMs, with each RTM invoked on-demand or via a pre-scheduled
automated activation. When multiple RTMs are being used, VIP permits
overlap in terms of what each is monitoring. Thus it is indeed possible to
have two RTMs monitoring subnets with overlapping connection ‘pools’, or
to have one monitoring a subnet while the other is monitoring the entire
server. The bottom line here is that VIP v4.6 comprehensively (and
easily) addresses all customer requirements when it comes to tn3270(E)
RTM with IBM’s tn3270(E) server within z/OS Communication Server.
The v4.6 RTM can be used to monitor response times to a specific remote
location, determine the validity of a user complaint of slow performance,
check the ‘health’ of a specific tn3270(E) server, or provide detailed,
historic data for resolving ‘service-level agreement’ (SLA) disputes.

THE RFC 2562 COMPLIANT TN3270 RTM IN VIP V4.6 GRAPHICALLY DEPICTING A SLIDING
WINDOW AVERAGE OF RESPONSE TIMES OVER A 2 HOUR PERIOD – WITH A ‘HOT-SPOT’
CAPABILITY ON EACH ‘BAR’ ON THE GRAPH THAT IMMEDIATELY EXPANDS THAT COLUMN TO
PROVIDE THE EXACT STATISTICS ASSOCIATED WITH IT.
The Need To Be Able To See

SNA system versus IP network transit time sub-components
VIP permits the tn3270 RTM data to be easily correlated with the ‘Telnet
At A Glance’ data to enable quick access to Telnet LU Groups and server
data. VIP v4.6 also permits response times to be split into their SNA
system versus IP network transit time sub-components.
VIP v4.6's ability to show both the SNA system and IP network transit
times, rather than just the IP component or Round Trip Time (RTT),
enables system operators to get a complete view of the RTM composition.
Thus, if there are response time issues they can quickly determine
whether these are occurring within the IP network or inside the
mainframe.
Five Response Time Buckets

The VIP v4.6 RTM enables network administrators to define five response
time “buckets” for “Total Response Time” and “IP Network Response Time”
[see screen shot on page 23] – for each monitor that is being used. RFC
2562, to accurately mimic the ‘legacy’ SNA 3x74 RTM feature, requires the
implementation of these 5 buckets. Having these 5 buckets, as opposed

to just reporting average response times, provides a more comprehensive
response time profile. This is ideally suited to meet the demands of SLA
compliance. Whereas just looking at average time will mask response
time fluctuations, the buckets show trends and enable one to determine
the level of response time consistency – given that it is response time
consistency that impacts productivity and user satisfaction.
The RTM thresholds and boundaries, as previously discussed, serve as

extremely accurate ‘early warning’ alert criteria. With VIP v4.6 it is also
possible to set these thresholds on a ‘cumulative’ basis in terms of
generating an automated alarm. So it is possible to specify that an alarm
should be raised if less than 80% of transactions fall into bucket 1, or
more than 15% of transactions fall into bucket 5, or the overall average
response time threshold time exceeds the predefined threshold. [Refer to
the RTM Configuration screen shown below to see how easy this is to
setup.] And remember it is possible to have multiple RTMs – monitoring
overlapping ‘entities’, if need be, with each monitor working having its own
specific set of threshold values.
VIP V4.6 TN3270 RTM CONFIGURATION SCREEN SHOWING HOW THE RESPONSE TIME THRESHOLD
BUCKET BOUNDARIES ARE SPECIFIED.

HTTP PERFORMANCE ANALYSIS: GOING BEYOND SNA
z/OS, thanks to its unparalleled scalability and reliability, is increasingly
becoming a preferred host for a new genre of HTTP applications –
involving, in particular, high-volume corporate portals and database
access. To accommodate these applications, VIP v4.6 includes
response/performance analysis for use with any z/OS HTTP application or
server, including those running on USS.
Whereas TN3270 traffic follows a very simple request / reply format with a
single screen of data or less being sent and received over a persistent TCP
connection, HTTP follows a more complex format. With HTTP, a single
mouse click can generate many TCP connections of varying duration as
various parts of the screen are refreshed. And, unlike with TN3270, when
all the data has been moved and the updates made, the connections do
not persist. This means that the TCP handshake time can be an
appreciable component of a user’s overall response time experience.
Finally, HTTP can download large files, for instance PDFs, which are best
characterized via an FTP-like transfer rate mechanism.
VIP V4.6 HTTP PERFORMANCE ANALYSIS CONFIGURATION SCREEN THAT SHOWS THE 3
TYPES OF ALERT THRESHOLDS THAT CAN BE SET – ALONG WITH THE ‘RIDER’ THAT CAN
SPECIFY THE TRANSACTION VOLUME CRITERIA FOR THE ALERTS.

To account for this, an HTTP performance monitor measures three things:
the average time to connect [i.e. time taken for TCP handshake(s)], the
time for ‘1st byte response’ [i.e. arrival time for the first byte of requested
data regardless of total amount of data to be transferred], and data
transfer rate.
As shown in the screen shot on page 7, VIP’s new HTTP monitor provides
just this sort of information and therefore a complete characterization of
HTTP performance.
IP FRAGMENTATION MONITORING AND DETECTION OF SOURCE

Undetected IP fragmentation vis-à-vis network well-being is akin to
undetected high blood pressure (i.e. hypertension) when it comes to
humans. It is a silent killer – if it remains undetected and untreated.
Hence the importance of the intelligent and automated IP fragmentation
monitoring that is available in VIP v4.6. [Screen shot on page 5.]
IP packet fragmentation [the equivalent of SNA RU segmentation] is a

mechanism to deal with the diversity of link types and networking devices
that one can encounter in generalized IP networking – especially with the
Internet.
IP permits routers or hosts to automatically split [i.e. fragment] IP

datagrams to accommodate the various MTU values associated with the
links and devices forming the end-to-end path that has to be traversed by
a datagram. In principle, IP fragmentation is a valuable and powerful
capability in that it permits dynamic, transparent networking without the
need for manual intervention and configuration. In practice, however, IP
fragmentation is not desirable.
Fragmentation increases the volume of packets that have to traverse the

network. The need to split up and then reassemble packets also increases
processing and storage resource utilization on routers and hosts.
Incoming datagrams must be buffered at a fragmenting router before they
are split and sent to the smaller MTU outbound interface. It is therefore
possible to overrun these buffers, forcing the datagrams to be dropped
and causing the sending host to retransmit. In addition to the time delay
to recognize the packet loss, the sending host will go into slowdown due to
TCP flow control and congestion avoidance algorithms.
The overhead in fragmenting, and thus the delay, is increased where

encryption is involved. IPSEC gateways are especially vulnerable. For
instance, if an IPSEC gateway is on Ethernet (V2) the MTU is 1500. If one
sends a 1500 byte datagram in, IPSEC has to perform encryption and
possibly add external headers. This results in a datagram greater than
1500 bytes and therefore forces fragmentation. And because of the extra
time involved for encryption, the input buffers on such a device are
especially susceptible to being overrun.

Contrary to a common belief, the possibility of IP fragmentation cannot be
totally eliminated through the use of the TCP maximum segment size
(MSS) option in TCP or IP’s Path MTU Discovery (PMTUD) ‘protocol’. MSS
is only between the TCP endpoints. It says nothing about what’s in the
middle.
PMTUD has several potential shortfalls. It is dependent on ICMP, which

may be blocked by firewalls or an incorrect access list. In addition some
routers don’t return the appropriate ICMP message ("black hole routers").
Not all devices and IP stack implementations support PMTUD. There is the
“stretch ack bug.” The Do Not Fragment bit may not get propagated
through some tunnels. These are just some of the instances where
PMTUD does not work to avoid fragmentation - hence the need for
continual vigilance. VIP v4.6 provides this constant monitoring and
displays fragmentation occurrence on the “Network at a Glance” screen
[page 8].
VIP v4.6, however, does not stop at IP fragmentation monitoring. Instead it

goes further. VIP v4.6 will automatically activate the necessary traffic
analysis so that system operators can quickly and decisively locate the
source of the fragmentation and take the appropriate action to rectify the
situation. Fragmentation induced performance degradation problems that in
the past might have either gone totally undetected, or would have taken
days if not weeks to identify and resolve, are now a thing of the past thanks
to VIP v4.6’s incisive fragmentation detection capabilities. With VIP v4.6
fragmentation will no longer be the silent killer of network performance.
DATA PRESENTATION: MAKING SENSE OF IT ALL
Albert Einstein, who knew a thing or two about what true knowledge is all
about, was fond of observing that:
“INFORMATION IS NOT KNOWLEDGE”
Raw network management data, presented haphazardly, will not help you
get a handle on what is really happening on a mainframe network. The
network management information, whether obtained from a stack, SNMP,
a ping, or an IP packet trace, has to be presented to the operator in ways
which make immediate sense – at a glance.
Contemporary mainframe networking, fueled by gigabit interfaces and the

increasingly more powerful zSeries processors, continues to get faster and
busier. Dramatic changes within the network can occur in split seconds.
System operators must have all the information they need – at once, on
one screen, and in a manner that allows them to make quick decisions.
Operators, help desk staff, and systems programmers do not have the
time to wade through multiple, disparate screens searching for the
information they need. Ideally they have to have all the pertinent

information consolidated, summarized and highlighted, in a single
meaningful view – with, of course, the option of being able to quickly drill
down into progressively more detailed views at the click of a button.
In order to be useful, a mainframe TCP/IP monitor, at a minimum, must

offer the following data presentation capabilities:
¾ centralized view of the whole network – encompassing multiple
LPARs per system in a multi-system configuration.
¾ at a glance summaries of all pertinent entities, including the
network, alerts, applications, FTP, telnet/tn3270(E), Enterprise
Extender, OSA(-Express) adapters, and remote hosts – with
attention-focusing color coded icons and semaphores for alerts.
¾ fast, point-and-click navigation – with consistency across all
screens.
¾ detailed views on-demand.
¾ graphical data selection tools, such as drop down ‘month at a time’
calendars, to expedite option specification.
¾ equal access to both real-time and historic data, particularly for FTP
and telnet/tn3270(E) traffic.
¾ multiple customizable views to accommodate individual or corporate
preferences.
¾ crisp and consistent responsiveness to keep pace with operator
demands.
YOUR Z/OS MACHINE CAN SEND YOU DAILY CHARTS BY E-MAIL, ILLUSTRATING HTTP
CONNECTION RATES, IP FRAGMENTATION ERRORS, DATA-TRANSFER RATES OVER TIME,
AT EACH AND EVERY TCP/IP STACK.

Browser-based, highly graphical data presentation, as discussed earlier, is
another stand-out feature of the VIP v4 architecture. Suffice, at this
juncture, just to say that VIP v4 offers all of the data presentation
capabilities mentioned above – plus a lot more.
VIP v4, thus, does not present operators with just a torrent of raw data, or
a very narrow, specific view of a network subcomponent [e.g. a single
stack or a single application]. Instead VIP v4 gives you the total, big
picture, at a glance, with the necessary views and tools to drill down to
progressively more detailed views – as needed. Yet another instance of
VIP v4 giving users the best of all worlds.
BUILT-IN ADVANTAGES OF A BROWSER-BASED APPROACH

The Web browser is destined to become the universal user interface. IBM,
for one, is an avid advocate of this, and has been since 1997. IBM’s
strategic WebSphere Host On-Demand and Host Publisher offerings for
mainframe application access, both of which are browser-based,
demonstrates IBM’s belief that all future application and data access
should be via a standard Web browser – rather than through proprietary
GUIs.
A browser-based GUI, as implemented by VIP v4, has many, automatic,

built-in advantages. Key among these being:
¾ operator familiarity.
¾ mobility – i.e. authorized access from anywhere across an intranet,

extranet, or the Web.
¾ guaranteed platform independence across Windows, Linux and Unix.
¾ Standards based security – SSL/TLS.
¾ interface and navigational consistency.
¾ seamless support for Java.
¾ ability to easily maintain multiple, separate browser instances per

workstation.
¾ straightforward internationalization.
¾ standardized upgrade policies and procedures.
¾ proven stability.
The bottom line here is that VIP v4 with its browser-based GUI sets out to
define a new and compelling standard for mainframe TCP/IP monitoring.
The best way to appreciate the value of this interface is to look at an on-
line demo, or better still to actually test drive a VIP v4 installation.

AGENT/SERVER ARCHITECTURE
The agent/server architecture used by VIP v4 results in:
¾ very low mainframe CPU utilization.
¾ seamless accommodation of multi-LPAR, multi-mainframe networks.
¾ the option to easily realize redundant, fault-tolerant configurations

for ‘zero downtime’ operations.
¾ the ability to quickly and easily add LPARs or mainframes to an

existing network.
¾ low cost deployments given that VIP servers can be implemented on

PCs running Windows or Linux.
¾ the option of being able to affordably, and non-disruptively, upgrade

the platform on which a VIP server is deployed, without in anyway
impacting mainframe operations.
¾ the offloading of network monitoring related data processing, data

analysis and data presentation functions so that these functions do
not get in the way of mainframe production workload processing.
The VIP monitoring agents are written in optimized ASSEMBLER for

maximum speed and efficiency. VIP agents are currently available for
z/OS v1.4 all the way through to z/OS v1.7. It is these agents that access
the mainframe TCP/IP stacks for management data, or interface with
IBM’s packet trace utility for IP packet traces.
New [i.e. modified] data gathered by the agents are fed, in real-time, to
one or more VIP servers. The use of multiple servers ensures resilience
for ‘zero downtime’ operations. If one server fails, users simply need to
redirect their browsers to one of the other servers. In addition, data is
kept at the agent. This means that even without any servers, no data is
lost.
The VIP servers, which are implemented in JAVA, can be deployed on PCs
running Windows, Linux/Unix servers [including Linux LPARs], or an ‘MVS’
LPAR with Unix System Services (USS). This flexible system even allows
for mixing server platforms when multiple servers are used. Thus
customers have a choice between running on the mainframe under USS or
Linux with all the inherent reliability or offloading network management
functions - thus freeing up CPU cycles for more production work. Or, you
can do both.

VIP V4: THE BOTTOM LINE
VIP v4 sets out to simplify mainframe TCP/IP monitoring. It has been

thoughtfully architected to be fast, comprehensive, low-overhead, reliable
and easy-to-use. It uses a flexible, agent/server configuration that
supports redundancy as well as low-cost server platforms.
It, in marked contrast to other offerings, has no blind spots vis-à-vis

mainframe TCP/IP networks, while the new TN3270 RTM, HTTP
performance, and fragmentation monitoring capabilities (with its
automatically triggered detail analysis) are akin to getting a long-range
radar system for overall system/network health and stability.
Unlike most other mainframe monitors VIP does not rely on SNMP,
full-time packet tracing or screen scraping, which are all known to be
inefficient and cumbersome, for its primary data collection needs. VIP v4,
instead, uses a variety of collection methods including directly accessing
the relevant z/OS TCP/IP stacks, via a cross-memory interface, to obtain
most of the network management data it requires. As a result VIP v4
provides true real-time network monitoring, at a fraction of the mainframe
CPU utilization used by other offerings.
VIP v4 offers incisive support for FTP, telnet/tn3270(E), Enterprise

Extender (EE), OSA(-Express), all IP applications, HTTP, fragmentation
monitoring, and remote hosts [e.g. routers]. VIP maintains detailed
historic logs and data files that can be accessed to see past activity.
Though opting not to use SNMP for its vital stack monitoring functions, VIP
v4, nonetheless, includes uncompromised support for SNMP queries on
remote devices. VIP has a full compliment of easy to use diagnostic tools
such as live IP packet tracing, multiprotocol ping and traceroute, DNS
lookup, MIB query, connection explorer, and a standard MVS system
operator command console.
A highly-graphical, browser-based operator interface, with multiple at a

glance views, is a trademark of VIP v4. This carefully designed ‘point-and-
click’ interface, with color coded icons and built-in data selection tools, is
intuitive, compelling, easy-to-learn – and easy-to-use. It is also
customizable. This interface never gets in the way of what an operator is
trying to achieve.
VIP v4 is, indubitably, the way to master the growing complexity of

mainframe networking and monitor tn3270 response times. With VIP v4
you can indeed have a ‘zero downtime’ mainframe TCP/IP network with
high-performance to boot.
[[[ \\\

SELECTED GLOSSARY
browser Web browser such as Internet Explorer (IE)
Enterprise end-to-end, mainframe-to-client, SNA transport across

Extender an IP network using HPR and UDP.
HPR the final iteration of SNA and APPN, essentially

representing APPN+
HiperSockets TCP/IP-based, inter-LPAR communications scheme
MIB management information base, a database of network

management objects for a given entity
RTM Response time monitor for tn3270 and HTTP
SNMP set of TCP/IP-centric network management protocols
stack software implementation of the TCP/IP protocol within a

system (or LPAR)
telnet TCP/IP-based terminal protocol for application access
tn3270(E) 3270-specific variant of telnet that works on a client-

server basis
VIPA virtual IP address, akin to an alias, assigned to a

mainframe IP resource [e.g. stack, OSA interface, TCP/IP
application], to facilitate fault-tolerance and resource
movement by masking the actual IP addresses of
resources from external entities
VIPA takeover automated recovery of TCP/IP resources in a sysplex by

the transfer of virtual addresses
Web-to-host browser-invoked host access schemes
SOFTWARE DIVERSIFIED SERVICES
Software Diversified Services (SDS),

[www.sdsusa.com] based in Minneapolis, MN,
has been providing premium mainframe solutions to the IBM world since
1981. It currently has in excess of 1,000 mainframe customers
worldwide.
SDS’ mainframe product repertoire now includes over twenty MVS, VM

and VSE products, with VIP v4 being one of these. SDS also markets PC
software related to mainframe operations. The products marketed by SDS
focus on network management, performance monitoring, report
distribution, data compression, terminal emulation, and client-server
applications.
SDS is noted for having the highest quality software, documentation, and
technical support in this industry sector. SDS technical support has been
rated #1 by the prestigious IBEX Bulletin.

Software Diversified Services
6010 Earle Brown Drive
Brooklyn Center, MN 55430
Phone: 763-571-9000
Fax: 763-572-1721
www.sdsusa.com

VIP Hicheel

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VIP Hicheel

Uploaded by

Copyright:

Available Formats

Mainframe TCP/IP Management

for Zero Downtime, High Performance Operations

SOFTWARE DIVERSIFIED SERVICES (SDS)

VITAL SIGNS VISIONNET IP MONITOR (VIP) V4.6

Response time monitoring;

© Software Diversified Services 2006

PREAMBLE & OVERVIEW .................................................................... 3

CHARACTERISTICS OF A GOOD MAINFRAME TCP/IP MONITOR (TABLE) .............. 6

VIP V4.6: TWENTY (20) CLEAR DIFFERENTIATING FEATURES ........................ 9

VIP V4.6: THE ARCHITECTURE CONTINUES TO BE THE KEY ........................... 13

DIRECT TCP/IP STACK ACCESS: A NOTEWORTHY BREAKTHROUGH ................... 15

RESPONSE TIME AND PACKET FRAGMENTATION MONITORING ........................... 20

DATA PRESENTATION: MAKING SENSE OF IT ALL ........................................ 26

AGENT/SERVER ARCHITECTURE ............................................................ 29

THE BOTTOM LINE ........................................................................... 30

SELECTED GLOSSARY ................................................................ 31

SOFTWARE DIVERSIFIED SERVICES (SDS) ............................................. 31

VIP’S RECENT TRACK RECORD OF EXCELLENCE

IN VIP 4.6 [MARCH 2006]:

¾ Traceroute, with configurable protocol (TCP, UDP, ICMP), to penetrate

¾ Use of IBM’s Network Management API extended to include EE monitoring.

IN VIP 4.5 [JANUARY 2006]:

¾ Simplified VIP mainframe agent installation.

IN VIP 4.0 [FEBRUARY 2005]:

SDS VIP v4.6: mastering complexity 2/32 Software Diversified Services

SOFTWARE DIVERSIFIED SERVICES (SDS)

VITAL SIGNS VISIONNET IP MONITOR (VIP) V4.6

Mainframe TCP/IP networking is invariably complex, often challenging, and

To stay on top of all of this, to deliver ‘zero downtime’ operations, you

A good mainframe network monitor also needs to be simple, intuitive and

SDS VIP v4.6: mastering complexity 3/32 Software Diversified Services

VIPA VIPA VIPA VIPA

Sockets Sockets Sockets Sockets

192.168.253.4 TODAY’S MAINFRAME TCP/IP

Mainframe TCP/IP networking, though now stable, robust and capable of

Not so with IP networking. IP is ultra laid-back and eschews control

This is hence a very different networking paradigm to what mainframe

SDS VIP v4.6: mastering complexity 4/32 Software Diversified Services

Continuous, intelligent response time monitoring, with multiple preset

SDS VIP v4.6: mastering complexity 5/32 Software Diversified Services

SDS VIP v4.6: mastering complexity 6/32 Software Diversified Services

VIP v4.6, as exemplified by the new “Network at a Glance” screen [page

VIP uses an agent/server architecture, with VIP monitoring agents

NEW IN VIP V4.6:

SDS VIP v4.6: mastering complexity 7/32 Software Diversified Services

THE LOW-OVERHEAD, FLEXIBLE AGENT/SERVER ARCHITECTURE OF

SDS VIP v4.6: mastering complexity 8/32 Software Diversified Services

1. Direct retrieval of all necessary management data from the pertinent

2. Stack access for management data augmented by full SNMP support

3. In marked contrast to competing schemes that rely on just one

4. Browser-based GUI (elegant, easy-to-master and simple-to-use) that

5. Truly real-time alert handling, with customizable threshold settings,

SDS VIP v4.6: mastering complexity 9/32 Software Diversified Services

7. Innovative response and performance monitoring of HTTP(S)

8. Intelligent and automated IP

9. Detailed visibility of OSA(-Express) operations, at a glance, for both

10. Fast, automatic, dynamic discovery of stacks, applications and

11. The ability to produce customizable dynamic Java based graphical

12. Powerful remote host monitoring capability that provides in-depth

13. Ability to activate multiple Response Time Monitors (RTMs), on-

SDS VIP v4.6: mastering complexity 10/32 Software Diversified Services

14. Provides 9 incisive, at a glance, network monitoring screen interfaces

speed responsiveness low CPU utilization