VIP hicheel

8/8/2019 VIP hicheel

1/32

MMaaiinnffrraammee TTCCPP//IIPP MMaannaaggeemmeenntt

ffoorrZZeerroo DDoowwnnttiimmee,, HHiigghh PPeerrffoorrmmaannccee OOppeerraattiioonnss

SOFTWARE DIVERSIFIED SERVICES (SDS)

VVIITTAALLSSIIGGNNSSVVIISSIIOONNNNEETTIIPP MMOONNIITTOORR((VVIIPP))VV44..66

Mastering Complexity:

Monitoring z/OS IP Networks

Easily, Graphically, Thoroughly

AA WWhhiittee PPaappeerr

April2006 Software Diversified Services 2006

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPARz/OS

LPAR

z/OS

LPAR

VIP agent

z/OS

LPAR

VIP agent

z/OS

LPAR

OS/390

LPAR

OS/390

LPAR

LinuxLPAR

OS/390LPAR

OS/390LPAR

z/OS

LPAR

z/OS

LPAR LinuxLPAR

z/OS

LPAR

z/OS

LPAR

VIPserver

intranet

System

Operators

System

Operators

z8xx

z990 z900 or S/390

VIP agent

VIPserver

The

Internet

VIPserver

VIPserver

Response time monitoring;

HTTP in VIP v4.6 & tn in VIP v4.0

NEW IN VIP V4.5:

fragmentation detection & location


2/32

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

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

VIPS 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 IBMs 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.


3/32


MMaaiinnffrraammee TTCCPP//IIPP MMaannaaggeemmeenntt

ffoorrZZeerroo DDoowwnnttiimmee,, HHiigghh PPeerrffoorrmmaannccee OOppeerraattiioonnss

SOFTWARE DIVERSIFIED SERVICES (SDS)

VVIITTAALLSSIIGGNNSSVVIISSIIOONNNNEETTIIPPMMOONNIITTOORR((VVIIPP))VV44..66

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 ofENTERPRISE EXTENDER (EE), TN3270(E)

WEB-TO-HOST and possibly even theIBM COMMUNICATIONS CONTROLLER FOR

LINUX (CCL). Thus to realize zero downtimemainframe operations, withcrisp and consistentresponse times for interactive users, one has no

choice but to master TCP/IP management and response time monitoring

(RTM) in particular fortnand 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 OSAinterfaces, 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 downtimeoperations, 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


4/32


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 aboutdata 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 performancedespite 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

IP clients

IP

network

S/390 Parallel Sysplexcluster

CouplingFacility

ESCON/FICONI/O System

VIPA

192.168.253.2

IP

TCP

Sockets

Apps.

IP

TCP

Sockets

Apps.

IP

TCP

Sockets

Apps.

IP

TCP

Sockets

Apps.

IP

TCP

Sockets

Apps.

VIPA

192.168.253.3

VIPA

192.168.253.4

VIPA

192.168.253.5

VIPA192.168.253.1

VIPA192.168.253.6

IP

TCP

Sockets

Apps.

192.168.253.4cached IP address

IP clients

LPARLPAR

LPAR

TODAYS MAINFRAME TCP/IP

NETWORKING CAN BE COMPLEX IN

THAT IT CAN INVOLVE MULTIPLE

HOSTS, MANY LPARS, VIRTUAL IP

ADDRESSES AND EVEN FEATURESSUCH AS DYNAMIC VIPA TAKEOVER IN

THE EVENT OF AN LPAR FAILURE.


5/32


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 presetthreshold 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-haveimperative features, and icing on the

cakehighly-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 FRAGMENTATIONMONITORING INTRODUCED IN

VIP V4.5 IDENTIFIESFRAGMENATION AND

FRAGMENATION ERRORS FOREACH TCP/IP STACK WITHTHE PIE-CHARTS AND GRAPHSPROVIDING ADDITIONAL (ANDHISTORIC) DATA ONFRAGMENTATION PER

APPLICATION, PROTOCOL, PORTOR CONNECTION ETC.


6/32


CHARACTERISTICS OF A GOOD MAINFRAME TCP/IP NETWORK MONITOR

IMPERATIVE HIGHLY-DESIRABLE

ability to monitor multiple LPARs per

mainframe and multiple mainframes from a

single screen. accurate, up to the secondat-a-glance

status maps of the entire network, with

iconic alert summaries, traffic profiles and

packet fragmentation notification.

ever vigilant, fast acting (but intelligent)

watch dog scheme to quickly generate

alerts when certain thresholds are crossed.

intelligent, real-time synthesis and

correlation of data from the stacks, NMI and

traffic analysis to create a true and incisive

portrayal of network conditions.

Exploit SNMP traps and report to a Monitor of

Monitors vis--vis HP OpenView and CA

Unicenter.

incisive response time monitor (RTM) for

mission-critical interactive traffic, in

particular tn and HTTP(S) sessionswith

the tn monitor compliant with the RFC 2562

standard as supported by IBMs tn3270(E)

server.

comprehensive IP fragmentation monitoringwith the necessary functions to help locate

the cause of any packet fragmentation.

immediate access to both current and

historic FTP and telnet activity reports.

remote host monitoring to have visibility of

external systems, such as routers, switches

and firewalls.

being nimble, light and low-overhead so that

it is responsive and furthermore does not

get in the way of production workloads.

comprehensive support for all OSA and OSA-

Express interfaces.

intelligent monitoring of tn3270(E) with SNA

correlation; e.g. LU names, unused LUs etc.

NetView interoperability.

direct retrieval of management data from the

TCP/IP stacks, via IBM supplied Network

Management APIs (NMI) when possible,augmented, where necessary, with full SNMP

access and packet tracing.

browser-based, highly-visual, point-and-click

monitoring that is both intuitive and simple

(without a steep and rocky learning curve).

support for Enterprise Extender (EE), ideally

using IBMs strategic NMI, so that all

connection details are always available.

fast auto-discovery of all local stacks,

applications and interfaces.

agent/server based architecture to minimize

mainframe overhead [e.g. CPU usage] while

affording maximum deployment flexibility.

integrated DNS look-up.

minimal reliance on high-overhead data

collection schemes such as SNMP, to avoid

high mainframe CPU usage.

Multi-protocol ping and traceroute, to probe

employing the same protocol and hence the

same routing as the application, with thepotential to traverse firewalls, and, in the

case of TCP, to determine if a remote

application is listening on a port.

access to summarized OSA performance data

reports on physical channel, LPAR utilization,

and OSA usage.

Externally deliverable (such as by email)

graphical reports to show historic

performance metrics such as interface or

stack usage.

customizable chart types [i.e. data views] to

suit individual preferences.

flexibility to set multiple, meaningful RTM

threshold alarms based on multiple criteria.

quick and easy installation of the necessary

mainframe agents.

SIMPLE, INTUITIVE AND EASY-TO-USE.


7/32


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 ofthe 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 augmentsboth 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 downtimeoperations. The VIP

servers, which are implemented in JAVA, can be deployed on PCs runningWindows, Linux/Unix servers [including Linux LPARs], or an MVS LPAR

with Unix System Services (USS).

NEW IN VIP V4.6:

HTTPPERFORMANCE

ANALYSIS TO

COMPLEMENT THE IPFRAGMENTATION

MANAGEMENT

INTRODUCED WITH

V4.5 AND THETN3270(E) RTM


8/32


THE LOW-OVERHEAD, FLEXIBLE AGENT/SERVER ARCHITECTURE OF VIP V4.6, WITH ITS ABILITYTO MONITOR MULTIPLE LPARS ON MULTIPLE MAINFRAMES FROM A SINGLE BROWSER-BASED

SCREEN, DELIVERS FAULT-TOLERANT CONFIGURATIONSTHROUGH THE USE OF REDUNDANT VIP SERVERS.

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPARz/OS

LPAR

z/OS

LPAR

VIP agent

z/OS

LPAR

VIP agent

z/OS

LPAR

OS/390

LPAR

OS/390

LPAR

LinuxLPAR

OS/390

LPAR

OS/390

LPARz/OS

LPAR

z/OS

LPAR LinuxLPAR

z/OS

LPAR

z/OS

LPAR

VIPserver

intranet

System

Operators

System

Operators

z8xx

z990 z900 or S/390

VIP agent

VIPserver

The

Internet

VIPserver

VIPserver

VIPS TRADE-MARKNETWORK AT A GLANCESCREEN, ENHANCED WITH V4.6 TO DISPLAY NEW

ICONICALERTS 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.


9/32


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 IBMs 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 networkstatus 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 ATA GLANCESCREENIN VIP V4.6 THATENABLES OPERATORS

TO QUICKLY ZERO-INON ON-GOING ORPOTENTIAL NETWORK

ISSUES.


10/32


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 monitoringthat 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

ofdrill downanalysis 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 withfeatures 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


11/32


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[TCP & UDP]

- SNMP MIB QUERIES - CONNECTIONS EXPLORER

- MVS SYSTEM OPERATOR COMMAND CONSOLE

16.Fault-tolerant, zero downtimeconfigurations 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 IBMs

packet trace utility, with optional conversion for use with SNIFFERs.


12/32


13/32


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-reasonedand 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 atany 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 IBMs NMIs. VIP

v4.6 extended VIPs 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 VIPagents 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 authorizedsystem operators can monitor and manage their

TCP/IP networks from anywhere in the world whether it be another


14/32


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:

MULTIMODALDATA COLLECTION AGENT/SERVER BROWSER-BASED

EFFICIENCY

SPEED

LOW MAINFRAME USAGE

FUNCTIONALITY

EXTENSIBILITY

RELIABILITY/REDUNDANCY

OVERALL SIMPLICITY

EASE-OF-USE

FAST INSTALLATION

VIP V4.6S CONNECTIONSEXPLORER SCREEN FOR

MONITORING SPECIFIC IP ORSNA/TNSESSIONSIDENTIFIED BY IP ADDRESSOR LOCAL/REMOTE PORTNUMBER IN THE CASE OF IPOR VTAM APPL. NAME/LUNAME IN THE CASE OF

SNA/TN.


15/32


DIRECT TCP/IP STACK ACCESS: A NOTEWORTHY BREAKTHROUGH

The significance and implications of VIPs 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 allTCP/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.

VIPs 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.


16/32


AVOIDING THE SNMP TRAP FORSTACKS

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. VIPs 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.


17/32


USING SNMP FORREMOTE 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, andconnection monitoring, form the core of VIP v4s 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 dont.

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.6SREMOTE HOST MONITORS AT A GLANCESCREEN WITH THREEDRILL DOWNPOP-UP SCREENS DISPLAYING SPECIFIC RESPONSE TIME AND PATH LENGTH OPTIONS.


18/32


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, thisapproach 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

IBMs packet trace utility. In addition, VIP v4.6 uses packet tracing for its

tn3270 RTM, HTTP performance and packet fragmentation detail


19/32


monitoring features since this is the only realistic way to obtain the

requisite data.

However, VIP v4.6 onlyintercepts 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 VIPs overarchingmultimodal 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.6s 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 havethe limitations associated with the schemes that rely predominantly on

SNMP-based MIB queries, full-time packet tracing, or screen scraping.

Thus VIP v4.6s 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.6SFTPAT A GLANCESCREEN THAT

PRESENTS A

CONSOLIDATED

VIEW OF ALL

ONGOING FTP

ACTIVITY.


20/32


RESPONSE TIME AND PACKET FRAGMENTATION MONITORINGADD 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 todays 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 overallsystem.

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--vissystem/network management.

1 Definitions of Protocol and Managed Objects for TN3270E Response TimeCollection Using SMIv2 (TN3270E-RT-MIB)submitted by IBM in April1999.


21/32


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 |

| || |

| |

| request D |

| ------------------------------------------> |

| reply(DR) E | |

| -------------------- - - - - - - - - - > |

| |

------------------------------------------------

A TN3270E server can save timestamp D when it receives a client

request, save timestamp E when the target SNA host replies, and savetimestamp F when the client responds to the definite response requestthat flowed with the reply. It doesn't matter whether the target SNAhost requested a definite response on its reply: if it didn't, theTN3270E server makes the request on its own, to enable it to producetimestamp F. In this case the TN3270E server does not forward theresponse to the target SNA host, as the dotted line in the figureindicates.

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 havemultiple 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 IBMs 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.


22/32


The Need To Be Able To SeeSNA 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 themainframe.

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

THE RFC 2562 COMPLIANT TN3270 RTM IN VIP V4.6 GRAPHICALLY DEPICTING A SLIDINGWINDOW AVERAGE OF RESPONSE TIMES OVER A 2 HOUR PERIOD WITH AHOT-SPOT

CAPABILITY ON EACHBARON THE GRAPH THAT IMMEDIATELY EXPANDS THAT COLUMN TOPROVIDE THE EXACT STATISTICS ASSOCIATED WITH IT.


23/32


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 alsopossible 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 THRESHOLDBUCKET BOUNDARIES ARE SPECIFIED.


24/32


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 users 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 3TYPES OF ALERT THRESHOLDS THAT CAN BE SET ALONG WITH THERIDERTHAT CAN

SPECIFY THE TRANSACTION VOLUME CRITERIA FOR THE ALERTS.


25/32


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, VIPs 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 devicesthat 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 whereencryption 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.


26/32


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 IPs Path MTU Discovery (PMTUD) protocol. MSS

is only between the TCP endpoints. It says nothing about whats 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 dont 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 thesource 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.6s 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 theincreasingly 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


27/32


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 HTTPCONNECTION RATES, IP FRAGMENTATION ERRORS, DATA-TRANSFER RATES OVER TIME,

AT EACH AND EVERY TCP/IP STACK.


28/32


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. IBMs

strategic WebSphere Host On-Demand and Host Publisher offerings for

mainframe application access, both of which are browser-based,

demonstrates IBMs 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.


29/32


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 configurationsfor 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

IBMs packet trace utility for IP packet traces.

New [i.e. modified] data gathered by the agents are fed, in real-time, toone or more VIP servers. The use of multiple servers ensures resilience

for zero downtimeoperations. 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.


30/32


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--vismainframe 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 v4provides 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.


31/32


SELECTED GLOSSARY

browser Web browser such as Internet Explorer (IE)

EnterpriseExtender

end-to-end, mainframe-to-client, SNA transport acrossan 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 networkmanagement 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 asystem (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 amainframe IP resource [e.g. stack, OSA interface, TCP/IPapplication], to facilitate fault-tolerance and resourcemovement by masking the actual IP addresses ofresources from external entities

VIPA takeover automated recovery of TCP/IP resources in a sysplex bythe 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.


32/32

Software Diversified Services

6010 Earle Brown DriveBrooklyn Center, MN 55430

Phone: 763-571-9000

Fax: 763-572-1721

www.sdsusa.com

Date post:	10-Apr-2018
Category:	Documents
Upload:	battulga-purevdorj
View:	218 times
Download:	0 times

VIP hicheel

Documents